At 4:04 AM +0300 5/31/08, Eddy Nigg (StartCom Ltd.) wrote: >Paul Hoffman: >>OK, but an actual reference would be helpful. > >Yes, and it's obviously pretty bad from me not being able to back it >up. I tried to locate it and even went through mails I sent in 2006 >where I could have possibly mentioned it, but no dice. If I remember >correctly I saw it initially at heise.de or theregister.com. And I >haven't bookmarked it either :-(
There is a possibility that it doesn't exist. Such a result would be widely-referenced in the crypto community. >>RFC 3766 is still used for making many important security decisions. > >Do you believe it to be still accurate? Yes. As I said earlier, no one has questioned the numbers in it, and as far as I know, no one has questioned the numbers used by NIST to achieve similar results. >I understand that it was written at a time before 2004 with >references to Itanium 500, Celeron 400 and Dual Pentium II-350 which >looks like childsplay to today's 64 bit quad processors with speeds >of 3GH per core and 12MB direct cache. I guess those aren't even the >strongest chips out there, but certainly in the same price league >when comparing. Correct. That's why we factored both Moore's law and periodic advances in number field sieving into the equations for determining how much effort *in the future* would be needed to break various keys. >What we are looking at is the to derive the private key from the >public key which would be enough to compromise the CA key and with >it the whole pile of roots in NSS (as you love to say). That is not what I said at all. I said that if Mallory derives the private from a single CA, he gets the same power as all CAs, namely to mint certificates for whomever he wants. That has nothing to do with "the whole pile of roots": just the opposite. >>The numbers and math in it are essentially the same as those used by >>NIST in the guidance that Nelson posted yesterday. To date, no one >>has asked us to update it, or even to make any significant >>corrections. > >As the author, how do you estimate the situation? Do you feel it's >still accurate or have developments and capabilities improved beyond >expectations (and despite Moore's law)? There have been no unexpected improvements in hardware or in cryptography in this area since we wrote the paper (unless you can find the article you mentioned...). That's not to say there won't be any: lots of smart folks are still pounding away on NFS. At 4:40 AM +0300 5/31/08, Eddy Nigg (StartCom Ltd.) wrote: >Eddy Nigg (StartCom Ltd.): > >>>If you know something we don't, it would be really >>>useful to the whole Internet community to hear more. >>> >>> >> >>I will look for it somewhat more...it can't have disappeared like that... > >The only thing I found so far (and which isn't the one I was >referring to) is >http://www.ercim.org/publication/Ercim_News/enw42/girard.html which >must have been known to you at the time of writing the RFC. Of course. It's actually mostly irrelevant to this thread because the work was for ECC, not RSA. All the work exposed is that ECC calculations a decade ago are about as hard as we thought they would be. To the best of my knowledge, there have been no significant improvements against ECC since then: Pollard's rho is still likely to be the best an attacker can do. This leads to the answer to Nelson's question the other day about ECC strength: it's still safe to simply multiply the symmetric strength you want by 2 to get the ECC key size you need. >It's nevertheless interesting, considering that they used some >10,000 PCs and today's botnets comprise usually of many, many more >compromised computers (some sources say up to a million). Sure, if you ignore the sieving requirements. Probably very few botnets exist where each of the machines has >128 gigabytes of RAM; further, those botnets might not be controlled by someone who has a machine with a few terabytes of RAM that is needed for the final calculation. >Also in that article there is the reference to "crack a public-key >system like RSA of at least 600 bits". ...which has not been done yet, at least in public. The largest is still 528 bits, I believe. --Paul Hoffman _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
