December 2003 - cypherpunks-legacy

An open letter to Commtouch
by Raph Levien 17 Dec '03

17 Dec '03

Hi Commtouch people, I am intrigued and hopeful about your secure e-mail product, Pronto Secure. However, I am puzzled about its support for POTP encryption. The other encryption protocols (PGP, PEM, MOSS, and S/MIME) have all been reviewed carefully by outside experts, and there is general consensus that these protocols embody state-of-the-art cryptographic technology, and that there are no known major security flaws. POTP stands out on your list because such a review has not been carried out. In fact, grave doubts have been raised regarding its security, and (to my taste, anyway) not satisfactorily answered. I do not wish to raise those points here, nor do I wish to claim here that POTP is insecure. However, I believe the reputation of your product is drawn into question by association. Should POTP be definitively demonstrated to be weak, then it would not be the case that using your product according to the instructions would provide "security." Further, I would consider it slightly misleading to describe it as "mission-critical." I feel the situation is analogous to that of a hypothetical networking company claiming that their product delivers high bandwidth by offering the choice of ATM, Myrinet, 100Mbps Ethernet, or string and tin cans. That said, I applaud your multiprotocol approach in general. In fact, I feel it is the future of Internet security tools. I hope your product gains widespread acceptance, and helps to further the cause of deployment of strong crypto. Raph Levien

1 0

No Subject
by Marc J. Wohler 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Anyone know of the staus of the Phil Zimmermann Grand Jury investagation? Is there a Statuate of Limitations or what? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMO2XK2eikzgqLB7pAQE6wgQAg7bs/b9qkayCQSUz8Ql8vcVNF74cSAl+ TRs/HQWA8g99x5j0Boircf7kpO8LR8orFkHdsSApYWCOCTDTHpiQNmcLYcSbTiFn td3cJsponuKLa0qTjRpo3e+yIo8ebDC1tCrJaFXTZD8hHGLchr+rz8CLJR8R7pLS LxYr3TFMM3s= =x1Al -----END PGP SIGNATURE----- ***Preserve, Protect and Defend the private use of Strong Crypto*** * * * PGP for the masses * * * Finger mjwohler(a)netcom.com for Marc Wohler's public key fingerprint= F1 70 23 13 91 B5 10 63 0F CF 33 AD BE E6 7B B6

1 0

Re: FreeBSD user <fb@sponsor.octet.com>
by Steve14571＠aol.com 17 Dec '03

17 Dec '03

In a message dated 96-01-04 18:44:46 EST, you write: > Am I the only one who has received three unreadable >messages from this address on cypherpunks? No, I have them too... What is going on? Pvt Stephen Herbert United States Marine Corps

1 0

Re: New Mitnick Book
by John Young 17 Dec '03

17 Dec '03

Responding to msg by bdavis(a)thepoint.net (Brian Davis) on Fri, 5 Jan 3:4 PM Here's Littman on what the Feds knew about Markoff at Raleigh (Orsak and Murphy are with Sprint Cellular; Kent Walker was US Attorney in San Francisco): Monday afternoon, Special Agent LeVord Burns sits by the coffee pot and vending machine at the Sprint switch and debates the legal issues with Shimomura. "Tsutomu wanted us to kick his door down," recalls Orsak, who along with Murphy, listened in. "Burns was talking about what warrants had been issued, what the FBI was going to do." Burns impresses Orsak. A well-built, bespectacled black man in a suit and tie, Burns looks like the kind of FBI agent that doesn't miss details. As Burns recounts Mitnick's background, Orsak is surprised by what the agent says about Mitnick. "Burns said there were a lot of guys that as far as national security went were a lot more dangerous than Mitnick -- that a lot of professional hackers are a lot more dangerous." To Orsak, cyberspace's Most Wanted Hacker doesn't sound all that threatening. "One of the more interesting things, I thought, was the FBI goes, 'As far as hackers go,' Mitnick was 'benign.' They didn't have evidence he was in it for the money." A little later, John Markoff and Shimomura's girlfriend, Julia Menapace, who just flew in, arrive at the switch. Orsak and Murphy invite Shimomura's team, Burns, and two other FBI agents from Quantico, Virginia, out to Ragazzi's, a casual Italian restaurant nearby. Orsak spreads out a Raleigh street plan on the checkered tablecloth and pinpoints Mitnick's location. "LeVord was telling us what his involvement was for the FBI," recalls Murphy. "It was light banter. LeVord assumed like we all did, that Markoff was just another guy out of California. Just another egghead. One of Tsutomu's." Markoff gets everyone's ear when he mentions Mitnick inspired the hit movie WarGames. "Markoff was filling us in on Mitnick's typical behavior, the different people Mitnick had run-ins with," recalls Murphy. "A guy in England, a guy in Princeton, one at Digital." Then, Markoff runs through some of Mitnick's aliases. One of the phony names rings a bell with Murphy. After dinner, the whole crew heads back to the switch, and just as Murphy suspected, he finds a memo describing a recent attempt by someone using the alias to social engineer a new bunch of MINs. Meanwhile, the FBI is bumping up against a technical problem. The agents had planned to install the FBI's own bulky scanning equipment in a rental van, but they can't find one. Murphy suggests using his co-worker Fred's minivan. Burns gives the idea the green light, and Orsak helps the agents set up and calibrate their equipment in Fred's van. Around midnight, Fred chauffeurs the two agents to circle the cell site to calibrate their scanning equipment. Fred and the FBI agents get to talking. "He [Fred] let the cat out of the bag," confides Murphy. "We didn't tell him not to say anything. We weren't trying to hide it, but we were also not trying to convey it. He told them Markoff wrote a book on this guy." The boys from Quantico aren't happy. "They freaked," recalls Murphy. "They thought Markoff would tip the guy [Mitnick] so he could write another book." One of the Quantico agents phones the Sprint switch to confirm Markoff's identity. "Me, Markoff, Tsutomu, and Julia were at the switch," remembers Murphy. "One of the Quantico guys was on the phone. He wanted to talk to Tsutomu." Murphy passes the phone to Shimomura. "He [Shimomura] wasn't about to lie," says Murphy of the tense moment. "He [Shimomura] was trying to evade a little bit. He said that Kent Walker knew about Markoff being there, which of course Walker did." Murphy, Markoff, and Menapace listen to Shimomura. "Kent knows about it," insists Shimomura to the agent from Quantico. "He's cleared through Kent." But Kent Walker later denied ever giving Shimomura such approval or knowing John Markoff was in Raleigh. Shimomura later disputed Murphy's account and said he "never told anyone from law enforcement that anyone had authorized Markoff's presence in Raleigh." (pp. 357-58)

1 0

More Noise Sphere Noise (simple source code)
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

Ok, no language holy wars. This was quickie to test out the Noise Sphere plotting. It's in Pascal, but it's understandable. { Simple demo of a Noise Sphere in Turbo Pascal } { (If only I had a really awful RNG to test it with...) } program NoiseSphere; uses Graph, Crt; const BGIPath = ''; { where those silly Borland *.BGI drivers are } var GraphMode, GraphDriver: Integer; type Polar = record r, theta, phi: Real; end; Cartesian = record x,y,z: Real; end; procedure PolarToCartesian(var P: Polar; var C: Cartesian); begin C.x := P.r * Sin(P.phi) * Cos(P.theta); C.y := P.r * Sin(P.phi) * Sin(P.theta); C.z := P.r * Cos(P.phi); end; procedure Plot(var C: Cartesian); begin with C do begin PutPixel(100+(Round(100*y)), 200-(Round(120*z)), Yellow); PutPixel(320+(Round(100*x)), 200-(Round(120*y)), Red); PutPixel(540+(Round(100*x)), 200-(Round(120*z)), Blue); end; Delay(1); end; function ByteToReal(b: Byte): Real; begin ByteToReal := b / 256; end; function InitScreen: Integer; begin GraphMode := VGAHi; GraphDriver := EGA; InitGraph(GraphDriver,GraphMode,BGIPath); InitScreen := GraphResult; end; var n: LongInt; X: Array [ 0..2 ] of Real; P: Polar; C: Cartesian; begin InitScreen; Randomize; for n := 0 to 2 do X[n] := {$ifdef USEDEV} {$else} ByteToReal(Random(256)); {$endif} n := 0; repeat with P do begin r := Sqrt(X[(n+2) mod 3]); theta := pi * X[(n+1) mod 3]; phi := 2 * pi * X[n]; end; PolarToCartesian(P,C); Plot(C); X[n] := {$ifdef USEDEV} {$else} ByteToReal(Random(256)); {$endif} n := (n + 1) mod 3; until KeyPressed; ReadKey; RestoreCrtMode; end.

1 0

Mixmaster In a Box
by Adam Shostack 17 Dec '03

17 Dec '03

Towords the goal of making Mixmasters in a box, I've written an installer script for mixmaster. If you're running on one of the supported platforms (alpha, bsdi, hpux, linux, sunos, solaris), the script will walk you through everything from the make to setting up cron jobs & /etc/aliases. If you've been putting off setting up a remailer because its a pain, give this a shot. Lance will probably be including it in the next release of mixmaster, but you can get it now by sending me a message with the Subject: get mix-installer. Comments, bugs, bug fixes are welcome. Thanks to Rich $alz for a extensive comments & suggestions for portability. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume

1 0

Re: More Noise Sphere Noise (simple source code)
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

On Fri, 05 Jan 96 07:24:03, I wrote: >Ok, no language holy wars. This was quickie to test out >the Noise Sphere plotting. It's in Pascal, but it's >understandable. >{ Simple demo of a Noise Sphere in Turbo Pascal } >{ (If only I had a really awful RNG to test it with...) } Odd... That came through on the mail/news gateway but the preceeding article that explains what that was about didn't.... did anyone receive it? In case no, it's based on Clifford A. Pickover's paper "Random Number Generators: Pretty Good Ones are Easy to Find" which doesn't deal with useful RNGs for crypto sense, but the paper does explain ways to visually represent RNGs so that seemingly good RNGs show their awful correlations, etc. My previous post that should have showed up mentioned that these methods might be useful for checking out crypto functions (hashes, pRNGs, ciphers). The full reference is The Visual Computer (1995) 11:369-377, Springer Verlag, 1995.

1 0

Ruby Block Cipher Mark 5
by Michael Paul Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The Ruby Block Cipher, Mark 4, had some problems with slow avalanche with a worst-case input, as well as some really amateurish reference code bugs that I apologize for. The good news is that these things have (I hope) all been corrected in the Ruby Block Cipher, Mark 5. The biggest change to the algorithm is that the "family key" is no longer simply added (modulo 2) to the input blocks, but is used in add and multiply steps to eliminate the old worst case avalanche patterns. The Ruby Block Cipher is not a general block cipher in that it cannot be used in Electronic Codebook (ECB) mode. It is a cryptographic hash function with a block size of only 64 bits. Of course, 64 bits is too short for a cryptographic hash function intended for digital signature use, but it is just fine for a quick block cipher. This may be a good reference for those folks who want a quick & easy encryption algorithm that need not withstand nuclear attack but can provide something better than common weak encryption methods in use in the software industry. The small amount of code, fast operation, and lack of the need for a lengthy key setup time are definite advantages where computing resources are at a premium. On the other hand, fast key setup time substantially reduces the cost of a brute force attack on the key, so use of the full 64 bits of the key is essential. Your comments and suggestions on this rather strange little cipher are welcome and encouraged. I'm particularly interested in any ideas as to how many rounds (the STRENGTH constant in the source code) are appropriate for well-balanced security. Information on the Ruby Block Cipher is available as ftp://ftp.csn.net/mpj/public/ruby_m5.ps.gz or ftp://ftp.csn.net/mpj/public/ruby_m5.rtf.gz and, if you are in the USA or Canada, a reference implementation and a sample file encryption program with free source code is in ftp://ftp.csn.net/mpj/I_will_not_export/crypto_???????/mpj/ruby_m5.zip where the ??????? is revealed in ftp://ftp.csn.net/mpj/README ruby_m5.zip is also available on the Colorado Catacombs BBS at 303-772-1062. I urge caution in using such a new cipher in actual applications, but if you feel the need to, you might consider asking me if any known weaknesses have been reported before you do. Note: this is not a product for sale (it is free and probably worth at least as much as you pay for it). It is also not a prepublication (it is THE publication in electronic form with no paper publication anticpated in the near future). ___________________________________________________________ | | |\ /| | | Michael Paul Johnson Colorado Catacombs BBS 303-772-1062 | | \/ |o| | PO Box 1151, Longmont CO 80502-1151 USA Jesus is alive! | | | | / _ | mpj(a)csn.net aka mpj(a)netcom.com m.p.johnson(a)ieee.org | | |||/ /_\ | ftp://ftp.csn.net/mpj/README.MPJ CIS: 71331,2332 | | |||\ ( | http://www.csn.net/~mpj -. --- ----- .... | | ||| \ \_/ | PGPprint=F2 5E A1 C1 A6 CF EF 71 12 1F 91 92 6A ED AE A9 | |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.7.1 iQCVAgUBMO1VgvX0zg8FAL9FAQECzQP/fD9dLLeixfZAtKXM2tDXrGgrashiqEsn jU9ohnNsou9MMU+PUmNj8RJCRHSXy4HMskV5BhnILUYaSI5ztJjZYvhBcIbBcR8J ecGl5++iaj4vRAb1vs32Y6LVsQm7hsMvy0byaszOWUKDpn+ZJrFCwMiKgD50ecXW y+XlpkdOhiA= =FQec -----END PGP SIGNATURE----- Please include my address on followups, since I don't read all mail on this wonderful (but high volume) list. Thanks! mpj(a)netcom.com

1 0

Re: 2047 bit keys in PGP
by futplex＠pseudonym.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Jiri Baum writes: > This is not really the case. The way PGP is set up, the operations > that take a long time are those that involve the secret key - signing > and decrypting. Encrypting and checking signatures are much quicker. > > In other words, the person that chooses the key is the one that'll > be most delayed. > > (I think it's something to do with the relative sizes of the exponents.) Right. We can (generally) make a "small" choice of the public exponent e, with a corresponding "large" choice of the private exponent d, rather than having them both "medium-sized". A "small" choice of d, however, would be easy to guess, which is a Bad Thing (tm). Futplex <futplex(a)pseudonym.com> *** Welcome to Cypherpunks -- Now Go Home *** -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMO2jkinaAKQPVHDZAQF7BAf/XrZ+abVfAw2Vle/8yomUZkC1Ol35g2yf gx6QKEkPDwEhw2B1qUJPA0veJmU4wGoXO5dOjsDkUtPtCU4StBVu2Axo2Hf1cknz raBWi/htN7xxKdeZ9+xiYduN3QQxwAhot8yTuaXqwswgjDwWjS4JJvfMG49lEqEN PGVHbYHKYlIumjzgLE5TbQ58EkNWmOw/BqojniTDyf98+5tZz0t2gx+ezLMG1S9C b12uCrw+EMmS7JDM+197xP+7JenXJUL41REVUAOVlcKh4TBLVFkRtzWa8Bt6vbPk A7XiFKE9PdjzaOOUo1M2lI8ocz5nq7PysghSt8UzBGDDvUmIWd+0RQ== =h4Li -----END PGP SIGNATURE-----

1 0

http://www.rsa.com/rsalabs/cryptobytes/
by Rich Salz 17 Dec '03

17 Dec '03

FYI. ---------- Begin Forwarded Message ---------- From: <Jueneman(a)gte.com> Message-ID: <30ED605E-00000001(a)wotan.gte.com> Date: Fri, 05 Jan 1996 12:31:08 EST Subject: Recent cryptographic findings To: ietf-pkix(a)tandem.com For those who may not have seen it, the most recent issue of CryptoBytes (Vol1, No. 3) put out by RSA Laboratories has a wealth of information in it. I have not had the time to fully digest the importance of all of the articles, but in the first one Adi Shamir has proposed an "unbalanced RSA" variant of RSA which "makes it possible to increase the modulus size from 500 bits to 5,000 bits without any speed penalty." Another article discusses means of deliberately constructing collisions (due to Hans Dobbertin of the German Information Security Agency) when using MD4, and concludes that "where MD4 is in use, it should be replaced." So far, at least, it appears that MD5, RIPEMD, and SHA-1 would resist this kind of attack, but a certain amount of nervousness might be in order. (Hugo Krawczyk of IBM Research and I considered some of these possibilities in conjunction with work we did on the SEPP protocol, which uses a salted hash function as a means of confirming the knowledge of a secret to a third party without having to use encryption. We were concerned that collisions might be possible, and also that it might be possible to partially reverse a hash function and glean at least information about the message that was being hashed, (the credit card number) in the case of a very short message. We ended up proposing a combination 140-bit hash function which includes both MD5 and SHA-1, assuming that it would be much more difficult to break both algorithms than just one. I will post the analysis to this list in a subsequent message.) Finally, Burt Kalisky provides a compendium of some of the possible attacks against RSA, and discusses simple and practical countermeasures. It seems to me that the most important of the various attacks involve the encryption and decryption of small messages. Since small messages are frequently generated for key exchange and for signature purposes, it is important that we consider these issues carefully. In particular, the use of pseudo-random padding for both encryption (a la the Bellare-Rogaway Optimal Asymmetric Encryption Padding) seems very beneficial, and padding is also important in the signature block. This group certainly ought to examine these issues very carefully, and we should probably give serious consideration to adopting OAEP for message encryption and key exchange. I believe we should also give serious consideration to a increased length message digest function such as SHA-1, and perhaps incorporate the use of multiple message digest algorithms for particularly important signatures , e.g., CA certificates. The back issues of CryptoBytes are available at http://www.rsa.com/rsalabs/cryptobytes/. Bob ---------------------------- Robert R. Jueneman GTE Laboratories 1-617-466-2820 Office "The opinions expressed are my own, and may or may not reflect the official position of GTE, if any." ----------- End Forwarded Message -----------

2 1