Re: Private Key Generation from Passwords/phrases
Joseph Ashwood wrote: I'm going to try to make this one a bit less aggregious in tone. I'm also Thank you. - Original Message - From: Matthias Bruestle Joseph Ashwood wrote: - Original Message - From: Matthias Bruestle You also ended up removing a large portion of my point. My primary point was that 2^76 2^112. You made several assumptions in coming to your conclusion that are at least suspect. You observe that currently 3DES:ECC-224 speed is about 4000:1, and assume that it will stay this way. However, if you look at the history of ECC, the speed of ECC doesn't scale linearly against 3DES, in fact a single thread of 3DES might've actually been faster 1 year ago (during the GHz war, before multi-core), whereas ECC is still improving as the ability of the CPU to perform complex routing and branch prediction improves. So next year the ratio could be 100:1, I doubt it will be that dramatic but it is possible. As a result this assumption will have to be reexamined every time a CPU revision is released, a slight timing change can actually make a big difference to the 3DES:ECC speed ratio. Also you need to consider the attack speed of the attacker, versus the production speed of the user. I know there are likely some shifts. Hence I wrote The relation stays (mostly) the same. But in my opinion these shifts are minimal compared to all the other uncertainties, e.g.: - How long does the protected secret/signature be ok? - How well is your adversary funded? - How much entropy has the passphrase really? - How much is the general speed increase in the next 20 years? - ... If you calculate your bits without safety margin, then next year AMD could add a 3DES unit to an CPU, the speed ratio is 4:1 and you're busted. (Because of the hardware friendly design of DES I would say a faster 3DES is easier to get than a faster ECC.) You assume that the fastest way to computer point exponents is through counting up to the exponent. While I admit I'm not familiar with point exponentiation algorithms, I strongly suspect this one to be incorrect, I see no immediate reason that (k*k*k*k) must be decomposed to (((k*k)*k)*k) instead of ((k*k)*(k*k)), at exp=4 there is no difference but at exp=16million there is an enormous difference. You might be able to make this assumption true for your system by somehow proving that the only way to compute k^x requires b^x steps (for some b. My assumption is that the passphrase is properly processed, i.e. nicely hashed. So an attacker has to go through this process if he wants to exploit the reduced entropy of the passphrase and (at least) I see no way how to exploit this reduced entropy then to help algorithms like Pollard's rho/lambda to speed up the computation. The attacker may use any point multiplication method he wants to use. (Jacobian, modified Jacobian, NAF, windowing, ...) I see no reason it the arguments presented that the attacker would still have to perform 2^76 (ECC)work in 2^112 (3DES)time, instead of 2^76 (ECC)work in substantially less than 2^112 (3DES)time. An attacker would have to perform 2^100 (ECC)work, because the ratio accounts in my calculation only for 2^12 steps. The other 2^24 is a thrown away 24bit random. That is not to say that I don't think you will have 2^76 (ECC)work required to break it, taking longer than 2^76 (ECC)work, but that I disagree with your result. If you set your target at 2^80 (ECC)work, then I believe you can achieve it this way. I also think that if you were to perform result[i] = hash(result[i-1], passphrase) (result[0] = 0x000...000) it is a safe assumption that there is no faster way than counting to i, which would vastly improve your chances of security (see Secure Applications of Low-Entropy Keys by Hall, Kelsey, Schneier and Wagner for reference). I also think that most users would be unwilling to wait the full day you spec'd, it is hard enough to get users to wait 5 seconds. The parameters can be changed as needed. A day can be ok for one purpose, e.g. for key recovery, while it is not ok for a different purpose, e.g. recreation of the private key for each decryption. In the later case the passphrase has to contain more entropy. Regarding passphrase entropy: Getting entropy into a rememberable passphrase is a related, but completely different problem. Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free WiFi man-in-the-middle scam seen in the wild.
Hi, Perry E. Metzger wrote: For years, I've complained about banks, such as Chase, which let people type in the password to their bank account into a page that has been downloaded via http: instead of https:. The banks always say oh, that's no problem, because the password is posted via https:, and I say but that's only if the page comes from *you*, and it might come from a bad guy. A German bank had the same problem. After some discussions without positive results I wrote an article about SSL problems for a large German IT magazine and described their situation. A short time after they changed the login page to https. Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Private Key Generation from Passwords/phrases
Joseph Ashwood wrote: - Original Message - From: Matthias Bruestle [EMAIL PROTECTED] What do you think about this? I think you need some serious help in learning the difference between 2^112 and 112, and that you really don't seem to have much grasp of the entire concept. Please omit all 2^ besides in the 2^24. This should make you feel better. [most offensive parts deleted] time units are inconsistent. Basically just stop fiddling around trying to convince yourself you need less than you do, and locate 112 bits of apparent entropy, anything else and you're into the world of trying to prove equivalence between entropy and work which work in physics but doesn't work in computation because next year the work level will be different and you'll have to redo all your figures. What we are interested in is time (e.g. secure until 20XX), not entropy. After all we are all in a physical world, also the computers. But for entropy we can buy time. Because physical world changes things have to be redone, e.g. DES - 3DES - AES - ... . So 30 years ago a bit of entropy bought you much time, now not so much anymore. But despite that with the system described in my email the figures don't have to be redone every year. Because the computers (in the physical world) get faster each year the time to bruteforce 3DES and 224bit-ECC gets lower. The relation stays (mostly) the same. The only thing which really changes is the time a user has to wait for recreating his key, which gets lower and lower. He certainly has no problem with that. Maybe you should take James Donald as an inspiring example for you. He raised a valid point, the offline attack using the generally available public key. Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Private Key Generation from Passwords/phrases
Hi, I am thinking about this since last night. On the web I haven't found much and I want to go in a different direction as I have found. Say I want to have 112bit security, i.e. as secure as 3DES. For this I would choose (as everybody writes) 224bit ECC (or Tipsy Curve Cryptosystem/TCC as I prefer, because the European Citizen Card is also called ECC officially). With the Passwords I would have to provide so much entropy, that a bruteforce attack needs as much time as 3DES to get the same security. (Higher value of ECC key ignored.) When I look at benchmarks ratio of the number of 3DES operations and of point multiplications is about 4000:1, so I have gained here about 2^12 bits. (Processing of Password with a hash function is so fast that it can be ignored unless the procession is artificially extended.) I am aware that a DES unit is cheaper than an ECC unit and that for DES there are special implementations for key search possible, so the gain might be even more. Lets assume the key is only very seldom regenerated. Then we could add a short fragment of real entropy to the passwords and throw it away after our first key generation. If a point multiplication takes around 4ms then we can brute force on one day 2^24 keys. So if the user is willing to wait for one day for his key recreation than he can add 3 random bytes to his passwords and throw them away. If we add this together, than we have already 2^36 bits of security from our goal of 2^112 bits. The remaining necessary entropy is then 2^76 bits which would have then to be provided by the passwords/phrase. That means the necessary length is reduced by about one third. What do you think about this? Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: secure CRNGs and FIPS (Re: How important is FIPS 140-2 Level 1 cert?)
Adam Back wrote: About the criticisms of Common Critera evaluation in general, I think why people complain it is a documentation exercise is because pretty much all it does ensure that it does what it says it does. So basically you have to enumerates threats, state what threats the system is designed to protect against, and which are out of scope. Then the rest of the documentation is just saying that in increasing detail, that you have not made mistakes in the design and specification and to some extent implementation. CC has very good points. One of the best points is IMO the ST/PP concept which encourages to think what to protect against what. And I do think that most of the CC documents are helpful. But some, esp. these which occupy the most paper, are IMO not worth their effort. These are the low- and high-level design. They are meant to be the link between specification and implementation, but I am sure that there are simpler ways to show the link. And my experience is that these two documents do not change the product in any way. Matthias -- Matthias Bruestle, Managing Director Phone +49 (0) 91 19 55 14 91, Fax +49 (0) 91 19 55 14 97 MaskTech GmbH, Nordostpark 16, 90411 Nuernberg, Germany - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How important is FIPS 140-2 Level 1 cert?
restrictions on current implementations. As a result a FIPS 140- certified key generator will be worse than a well-designed non-FIPS-140 one because the FIPS requirements prevent you from doing several things that would improve the functioning like injecting extra entropy into the generator besides the DES3 key. That's interesting. I would have expected to revise things like that for FIPS140-*2*. In addition since no two eval labs can agree on exactly what is and isnt OK here its pretty much a crap-shoot as to what you can get through. Ive heard stories from different vendors of Lab B disallowing something that had already been certified by Lab A in a previous pass through the FIPS process. I had a talk with a FIPS-140 lab. I have been told, that undocumented wording has to be used that only the labs know. The FIPS-140 is to me a obscure process. And btw. the lab told me, that they don't want to have called it a certification (despite getting a certificate), but a validation. Mahlzeit, Matthias -- Matthias Bruestle, Managing Director - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
