understandable cypher software
Folks-- A paragraph of philosophy and then some technical PGP questions. I should be able to verify with my own eyes how cypher technology works. Otherwise I'm trusting my security to somebody's black box. I should be able to write my own and test that it interacts with someone else's the way it's supposed to. I should be able to monitor the communications between my copy of a cypher product and some other, and verify that they're doing the things people say they are. Besides, I'd like to carry the crypto basics in my head "just in case." To these ends, I'd like cypher software that is as easy to read and understand and trust as possible. I'd like to start with a distilled PGP. Does this list cover the heart chambers of PGP? (Not to devalue the rest): RSA IDEA The signature algorithm (MD5?) 128 bits? Is that based on RSA? A cryptostrong pseudorandom # generator? Is this based on RSA? Something that takes keystroke delays (real, but not so good, random numbers) and makes real good random numbers? Is this based on RSA? A data compression algorithm (some variation of LZW?) A binary<-->ascii translator RSA seems to depend on doing modulo-multiply on big integers. What are the relative speeds of the different modmults in PGP (modulo processor speed)... the simplest C version the fastest C version the fastest assembler version on the processor where it matters least the fastest assembler version on the processor where it matters most? Given the time to do modmult, couldn't all the rest (including modexp) be done in an interpreter that had big ints and modmult as a primitive? What's the formula for RSA again? out = in * something ^ somethingelse mod yetanother?? I know it can't be, because the key is only one number. What is/are the basic primitive(s) for IDEA? -fnerd "Computer software must not only work, it must also appear to work." --Carl Hewitt fnerd@smds.com (FutureNerd Steve Witham)
RSA seems to depend on doing modulo-multiply on big integers. What are the relative speeds of the different modmults in PGP (modulo processor speed)... Also consider reliability. As of 2.0, modmult on the SPARC (using the MERRITT code) fails on some keys, while either the PEASANT or UPTON routines function correctly but are slower. (I haven't had time to test them in parallel and find where they diverge, but there is a large keyring "out there" that breaks the MERRITT code in several
places...) (on the main thread, yes, understanding "the whole thing" is a good idea, and perhaps modifying the code to make this easier is a useful development goal...) _Mark_
...put it on your crypto feature ring. Has a sort of futuristic ring to it.
Hmm, perhaps we should eventually build real Captain Midnight Decoder Rings, which would fit around your finger. When the face of the ring was inserted into a DIN-plug serial port, it would power up, and talk a serial protocol to do the crypto operations needed to sign and decrypt messages, a la Phil Karn's design. There are smart-card microcontrollers with most or all of the right features -- we'd just have to figure out how to pot one into a ring with a truncated DIN-plug. John
participants (3)
-
fnerd@smds.com
-
gnu
-
Mark W. Eichin