Re: Can you keep a secret? This encrypted drive can...
At 17:58 -0500 2006/11/08, Leichter, Jerry wrote: No, SHA-1 is holding on (by a thread) because of differences in the details of the algorithm - details it shares with SHA-256. I don't think anyone will seriously argue that if SHA-1 is shown to be as vulnerable as we now know ND5 to be, then SHA-256 can still be taken to be safe for more than a fairly short time. Hmm, I disagree with this. Firstly, I don't think SHA-1 *is* holding on... while we don't have an example collision yet, there is no real doubt that one can be found in about 2^64 operations, which is less than the required 2^80. And SHA-2 does have a significantly different design in one area; the data expansion part is much stronger than SHA-1's, and almost certainly defeats the Wang-style attacks. Our paper on eprint gives some justification for why SHA-2 would appear to be resistant to these kinds of attacks. Greg. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Wed, 8 Nov 2006, Travis H. wrote: On Wed, Nov 08, 2006 at 05:58:41PM -0500, Leichter, Jerry wrote: Sorry, that doesn't make any sense. If your HWRNG leaks 64 bits, you might as well assume it leaks 256. When it comes to leaks of this sort, the only interesting numbers are 0 and all. I can cite numerous examples of such happening in real life. [...] Not having to rely on perfectly unpredictable numbers coming from your RNG is a valid design principle. Looks like you are doing a common mistake of using ``entropy source'' (or, probably, even``source of entropy input'') as output of your generator (see NIST SP 800-90 for details). With such attitude, the next step is to use identity mapping as a block cipher :-) -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Why the exponent 3 error happened:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sonntag, 17. September 2006 06:01
For another example of just how badly this kind of thing can
be done, look at this code excerpt from Firefox version
1.5.0.7, which is the fixed version. There are two PKCS-1
parsing functions, one which returns the hash and its prefix,
the other of which is given the hash and asked whether it
matches the RSA-signed value. This is from the latter one:
/*
* check the padding that was used
*/
if (buffer[0] != 0 || buffer[1] != 1)
goto loser;
for (i = 2; i modulus_len - hash_len - 1; i++) {
if (buffer[i] == 0)
break;
if (buffer[i] != 0xff)
goto loser;
}
/*
* make sure we get the same results
*/
if (PORT_Memcmp(buffer + modulus_len - hash_len, hash,
hash_len) != 0)
goto loser;
PORT_Free(buffer);
return SECSuccess;
Here, buffer holds the result of the RSA exponentiation, of
size modulus_len, and we are passed hash of size hash_len to compare.
I don't think this code is used, fortunately. It will accept
anything of the form 0, 1, 0, garbage, hash. Just goes to
show how easy it is to get this kind of parsing wrong.
Unfortunately, this code _is_ used! It took me quite a while to understand
under what circumstances, but here is the result. The problem is fixed as of
version 1.5.0.8 (out now). Interestingly, the mozilla people fixed it by
themselves in the 2.0 version (and any public beta I could find), but for the
1.5 version it took my bug report...
So here is how the code is used and some hints (I am reluctant to give out the
details right now, given that there are still many vulnerable systems out
there. However, I am sure you can easily work out the details):
Whenever a SSL or TLS server send a ServerKeyExchange message, the key
contained in there is signed with a fresh nonce. This signature is checked
using RSA_CheckSign().
Faking a signature for a key with a small exponent like 3 is easy. This can be
used to break the SSL/TLS authentication.
Better upgrade asap...
Regards,
Ulrich
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Flaw in RFID-enabled passports (part 2?)
re: http://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports Budapest Declaration on Machine Readable Travel Documents (MRTDs) http://www.fidis.net/home/single-news/article/budapest-declaration-on-machine-readable-travel-documents-mrtds-2/?tx_ttnews%5BbackPid%5D=4cHash=fe8718735f from above: By failing to implement an appropriate security architecture, European governments have effectively forced citizens to adopt new international Machine Readable Travel Documents which dramatically decrease their security and privacy and increases risk of identity theft. Simply put, the current implementation of the European passport utilises technologies and standards that are poorly conceived for its purpose. In this declaration, researchers on Identity and Identity Management (supported by a unanimous move in the September 2006 Budapest meeting of the FIDIS “Future of Identity in the Information Society” Network of Excellence) summarise findings from an analysis of MRTDs and recommend corrective measures which need to be adopted by stakeholders in governments and industry to ameliorate outstanding issues. ... snip ... and RFID Passport Security 'Poorly Conceived' http://it.slashdot.org/it/06/11/09/1757202.shtml the above also references Feds Leapfrog RFID Privacy Study http://www.wired.com/news/technology/1,72019-0.html from above: The story seems simple enough. An outside privacy and security advisory committee to the Department of Homeland Security penned a tough report concluding the government should not use chips that can be read remotely in identification documents. But the report remains stuck in draft mode, even as new identification cards with the chips are being announced. ... snip ... The Use of RFID for Human Identification; A DRAFT REPORT from DHS Emerging Applications and Technology Subcommittee http://www.dhs.gov/xlibrary/assets/privacy/privacy_advcom_rpt_rfid_draft.pdf - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
