From: Lucky Green <shamrock@cy...>  20020227 10:34:33

Rabbi wrote: > On Tue, 26 Feb 2002, Keith Ray wrote: > > > Currently, the Mixmaster v2 protocol uses a hybrid TripleDES and RSA > > cryptosystem. The RSA keys are a fixed size of 1024bits. Using Bernstein's > > Homework assignment: What does Mixmaster do when it encounters messages > and keys of larger than 1024 bits? Can current Mixmaster implementations > use 4096 bit keys? > > (If so, we want to stick with RSA to preserve backwards compatability. If > not, we should reexamine the choice in pubic key algorithm.) > > How does this attack (or does it) affect DH keys? I would like to propose that we all take a step back and respond, rather than react. The Bernstein paper offers some very compelling sounding theories. While they have me and most everybody in the industry concerned, at this point several open questions that Bernstein himself raised in his paper remain. Having said this, Bernstein's discoveries certainly don't look good. Nor are they hugely surprising. All public key cryptography is wishful thinking. The scientific community does not know if breaking RSA is as hard of a problem as factoring. Nor has anybody submitted a proof that factoring is NP complete. Not to mention that there is no proof that P != NP. We merely hope that the above assumptions hold true. For all we know, some mathematician may come up with a proof tomorrow that will make all public key cryptography, not just a particular implementation of PKC, trivially breakable. Until mathematics proves otherwise, which Bernstein is not even suggesting, securing an implemention using PKC remains an engineering problem. PKC favors, and continues to favor even in light of Bernstein's paper, the defender over the attacker. The work factor for breaking RSA grows well beyond linearly to the size of the key. Moore's law is allowing us to increase key size faster than the cryptanalyst can increase his cryptanalytical hardware. Bernstein may have shaved off a constant. Reducing the cryptanalytical workfactor by a constant cannot alter the premises on which PKC depends. Bernstein contents, without submitting proof, presumbably due to space constraints, that his proposed attack will apply to discrete logbased public key algorithms, such as DH, as it does to RSA. Therefore, nothing would be gained, other than increased load on the servers, in moving to DH. Increasing the size of RSA keys to 4096 bits would appear prudent at this time. The performance impact of the larger keys given typical Mixmaster usage patterns even on a slow machine will be negligible. If you got an old 386 you might want to consider to upgrade. I just threw out a several P133's, but I am sure that I can find a you faster boxes free of charge should you currently be stuck running Mixmaster on the likes on an 8088 under genuine ATT UNIX. > > secure against such agencies. I therefore propose we expedite the > > development of the Mixmaster Protocol v3. > > Agreed. Sure, but I would caution against reinventing the wheel. As much as I was impressed by the numerous privacyenhancing implementations that I saw at the recent excellent CodeCon (for which Rabbi was one of the organizers), many of the implementors appeared to have worked in isolation from the stateoftheart of the scientific knowledge in the fields of cryptography and secure distributed computations. Though, to their credit, most had read Applied Cryptography and at least included crypto in their protocols. > > I also propose we update the Mixmaster v3 protocol as follows: > > 1. Use AES256 [FIPS 197] as the symmetric cipher. > > Agreed. Given the blazing speed of AES there is no practical reason not use AES256 on a server, though I would like to point out that there really is no cryptological reason to choose AES256 over AES128 unless you are concerned about the system being attacked by a practical quantum computer. Nor is it worth arguing over. AES256 is suitable to task. > > 2. Use SHA512 [Draft FIPS 1802] as the secure hash. > > I seem to recall there being kvetching about the speed of SHA512. Does > anyone have benchmarks on this? Complaints? Alternatives if necessary? SHA512 is the hash function of choice for AES256. While it is true that the hash isn't excactly a text book example of efficiency, it is plenty fast for use by Mixmaster. > It's nice to say that Mixmaster can run on a 486 with no problems. Would > this cause problems for that? No. Besides, I have old friends that pride themselves in only using computer hardware that they found in dumpsters or on the street. They all have ceased years ago to even bother to pick up 486 or lowend Pentiums in the alley ways. > > 3. Use 4098bit RSA, DH, or ElGamal as the default asymmetric cipher with > > 2048bit as the minimum key size. > > See my previous question about RSA 4096 bit compatability. If you are really worried about the security of RSA, make it 4096 bits and have it be done with. I generated several 4096 bit RSA keys in the background while typing this email message on my outdated laptop that I was about to donate to charity. > > We need to move ahead and make Mixmaster v3 a reality. We need to > > update and finalize the spec, create a roadmap for the development, > > and gather volunteers to do the coding. Security features should be > > the top priority as time is no longer on our side. Moore's law waits > > for no one. This is a touchy issue, but in my decades of experience running software development projects, I have found that there has to be an official keeper of the roadmap for the project to succeed in a reasonable time frame implementing a reasonable percentage of the requirements. YMMV. > Other issues I would like to see solved in v3 are the batching and forward > secrecy additions. Sure. > We should have an interremailer protocol that does a DH key negotiation > between the two remailers and transfers batches of messages of fixed > incremental sizes at fixed time intervals. We should work out this > protocol and include it in the spec as well. Using SSL/TLS as a base for > this should be fairly trivial. The batching issue is orthogonal to the forward secrecy issue. I don't think that Rabbi meant to imply otherwise, but I still would like to caution against mentally linking the two. As for the forward secrecy, Rabbi is correct in that this is a solved problem as offered by the default distribution of OpenSSL. Lucky 