[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Secure voice software issues


As soon as I get the famous Intergraph Overtime Boot off my neck, I
plan to start writing some crypto-phone software for the Mac. Pursuant
to that, there are some issues and questions that I'd like to raise
here for your perusal.

There have been several calls here in the past for Sound-Blaster based
cryptophones, but none have yet appeared, so I'm going ahead with
this. Comments and questions, even flames, are welcome. Just don't ask
me to include support for Skipjack/Capstone hardware, or I'll sic
David Sternlight on you. (note: no smiley)

1. Why the Mac? Well, because I have one :) Also because all Macs for the
last three years or so have integrated sound I/O, and OS support for
same. This support includes choice of sampling rate, compression
(none, ~2:1, ~6:1), and even a choice of input device (the built-in
mike, or some more-exotic external device, like the Mac version of the
PAS-16 soundcard.)

2. Some fundamental principles:
	a) encryption routines will be provided as drop-in "plugins",
	much like Photoshop or BBEdit. Easy to customize, easy to
	roll-your-own. Easy for non-US residents to use. Easy to
	separate details of encryption from messy details of Mac
	Sound Manager and Toolbox.

	b) reuse. The initial version will leverage as much existing
	code (cf. Outerbridge's fast 68k DES, parts of PGP, and so on.)
	The eventual product will be released in complete source form
	to encourage adaptation to other platforms. (note that if I use
	AppMaker for my basic design, as I am wont to do, that I won't
	be able to distribute their source code.)

	c) STU-III metaphor. Basic mechanism: caller dials callee. The
	phones establish a connection and negotiate speed and security-
	for example, the crypto ignition key you put into a STU-III
	may be able to handle TOP SECRET or below, but your callee may
	only be able to handle SECRET.

	I expect the s/w version to also negotiate sampling fidelity
	(5.5, 11, or 22 kHz) based on DCE connect speed and compression
	based on DCE connect speed and CPU power. (neat idea: each side
	can compress and encrypt one of the standard system beeps to
	determine a relative "power index" for negotiation)

4. The initial version will probably support single and triple DES and
IDEA for encryption, with key exchange a la vat- none! Later versions
may include DH key exchange and other encryption algorithms.
Eventually (probably not until I get a PowerPC-based machine) I'd like
to be able to use PGP keyrings as phonebooks.

5. In a few months I'll need some beta testers. In the meantime I need
helpful suggestions for names, features, and designed-in expansion

- -Paul

- -- 
Paul Robichaux, KD4JZG     | "Crypto-anarchy means never having to say
[email protected]          |  you're sorry." - Tim May ([email protected])
Intergraph Federal Systems | Be a cryptography user- ask me how.

Version: 2.3a