Adam Back writes:
John Deters <jad@dsddhc.com> writes:
At 01:15 PM 10/10/97 +0100, Adam Back you wrote:
Persistence authentication suggestion:
The problems with this solution are twofold:
1. Eric may have to redesign the unit to have persistent read-write storage. And maybe a *lot* of storage, if you use it a lot. Maybe a lot of expen$ive $torage at that. His phone is already priced way out of the consumer market, let's not add to that.
Hey, it's only a factor of two too expensive... Moore's law is your friend...
If it cost a lot extra, that could be a problem, yes. I am unclear on how much extra this would cost. Apart from an EEPROM, it's a protocol and software update right?
The units currently have 2K bytes of EEPROM and 256K bytes of FLASH. A little under half the flash is currently available, though it will probably be taken advantage of during remote upgrades (coming soon to a crypto phone near you...) There's plenty of room for long term storage of a reasonable set of public keys. Private or symmetric keys present a problem, since then you've got a long term secret to store somewhere. To forestall a bunch of questions about remote upgrades: (1) there is a jumper on the write line to the FLASH. If you're totally paranoid, leave it in the "Read Only" position. (2) upgrades will be digitally signed. (3) It'll be a "pull" upgrade. I.e., you have to request the upgrade. They're not just pushed down your throat.
On the cost front, I am interested as to thoughts on how easy it would be for Eric to put one of his phones on a PCI card, or PCMCIA card. Presumably you could make some major cost savings in this way, in that you could potentially use the computers modem, memory, processor.
I can pretty much be done all in software on a laptop. I've explained the details several times. Perhaps if folks we're paying me lots of money for the info, they would listen closer ;-) The primary thing you lose is the simple integration with the telephone. A small (cheap) hardware hack can work around this. Yes, I know you'd prefer not to have any non-standard hardware, but on the other hand, if the system is a pain in the ass to use, nobody is going to use it.
I think Eric's phone uses a 14.4k modem chip (or lower?) so it's not the bit rate as such, but more the lack of higher quality audio compression codecs which are possible in hardware. (Right?)
The unit currently runs at 14.4k. A 4800 b/s fallback mode is currently under development.
Also the fact that with PGPfone you're using PC speakers, and room microphone probably makes it seem worse than it could be.
Fixable with software and MIPS (you've got those). Take a look at those nice USR and Polycom full duplex speaker phones. There's nothing magic in them. Notice the neat little song they play when you power them up. It's a training tone used to compute the impulse response of the room.
Course adding the whole lot to a GSM phone would be even neater, but then that'd get expensive again. Wonder how much functionality could be borrowed from components already present for the normal GSM phone hardware, and how much saving you could get from that.
Pretty much everything you need is already there. It's a question of integration. Eric