New NTRUEncrypt Parameters

2003-06-27 Thread Whyte, William
(I've also posted this message to sci.crypt) Hi list, NTRU Cryptosystems has posted several new documents, which are avaible through http://www.ntru.com/cryptolab/params.htm. As background: recent results on NTRUEncrypt have shown that decryption failures on validly encrypted messages leak

RE: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages

2003-07-08 Thread Whyte, William
One difference is that with the identity-based crypto, once a sender has acquired the software and the CA's public key, he doesn't have to contact the CA to get anyone's certificate. He can encrypt to anyone without having to contact the CA, just based on the email address. Your proposed

RE: replay integrity

2003-07-09 Thread Whyte, William
I wouldn't say that this is a good reason to take these features out of SSL. But assuming they are needed is a cautious assumption, and assuming that SSL meets the needs for replay integrity makes even less sense when we are dealing with a serious top-to-bottom security model. [ ... ]

RE: SSL

2003-07-10 Thread Whyte, William
[ Jill ] Instead, I have a different question: Where can I learn about SSL? [ Ian ] PS: next step is Ferguson Schneier's recent book which has been described as how to re-invent SSL. This reminds me: the best tutorial on the security aspects of SSL 3.0 that I know of is the Counterpane

RE: How thorough are the hash breaks, anyway?

2004-08-31 Thread Whyte, William
My understanding is that once you've used trial division to get rid of all the extremely short divisors, a random number of length n is about as hard to factor as an RSA modulus of the same length. I don't think there are a lot of easy-to-factor moduli around. William -Original

RE: How thorough are the hash breaks, anyway?

2004-08-31 Thread Whyte, William
To be more precise: Your odds of getting a modulus that you can divide by something are very high. Your odds of getting a modulus that you can factor efficiently are very low. William -Original Message- From: Matt Crawford [mailto:[EMAIL PROTECTED] Sent: Monday, August 30, 2004 11:47

RE: Are new passports [an] identity-theft risk?

2004-10-23 Thread Whyte, William
R.A. Hettinga wrote: http://worldnetdaily.com/news/printer-friendly.asp?ARTICLE_ID=41030 An engineer and RFID expert with Intel claims there is little danger of unauthorized people reading the new passports. Roy Want told the newssite: It is actually quite hard to read RFID at a

RE: SHA-1 results available

2005-03-03 Thread Whyte, William
http://theory.csail.mit.edu/~yiqun/shanote.pdf No real details, just collisions for 80 round SHA-0 (which I just confirmed) and 58 round SHA-1 (which I haven't bothered with), plus the now famous work factor estimate of 2^69 for full SHA-1. As usual, Technical details will be

RE: I'll show you mine if you show me, er, mine

2005-03-05 Thread Whyte, William
I haven't read the original paper, and I have a great deal of respect for Markus Jakobsson. However, techniques that establish that the parties share a weak secret without leaking that secret have been around for years -- Bellovin and Merritt's DH-EKE, David Jablon's SPEKE. And they don't require

RE: ECC patents?

2005-09-15 Thread Whyte, William
http://www1.ietf.org/proceedings_new/04nov/slides/saag-2/sld9.htm: What is Really Covered o The use of elliptic curves defined over GF(p) where p is a prime number greater than 2^255 when the product satisfies the Field of Use conditions o Both compressed and

RE: ECC patents?

2005-09-15 Thread Whyte, William
They paid $25MM. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James A. Donald Sent: Thursday, September 15, 2005 12:54 PM To: cryptography@metzdowd.com Subject: RE: ECC patents? -- Whyte, William: It hints that only some

RE: ECC patents?

2005-09-15 Thread Whyte, William
] On Behalf Of James A. Donald Sent: Thursday, September 15, 2005 12:54 PM To: cryptography@metzdowd.com Subject: RE: ECC patents? -- Whyte, William: It hints that only some particular curves have been licensed. It could be that NSA has decided not to buy a license for the other

RE: ECC patents?

2005-09-17 Thread Whyte, William
To: cryptography@metzdowd.com Subject: RE: ECC patents? -- Whyte, William [EMAIL PROTECTED] $25MM figure: http://lists.jammed.com/ISN/2003/10/0097.html I stand corrected. However as was pointed out previously: : : Further, the license would be limited to only : : prime

RE: [EMAIL PROTECTED]: Skype security evaluation]

2005-10-31 Thread Whyte, William
A similar approach enabled Bleichenbacher's SSL attack on RSA with PKCS#1 padding. This sounds very dangerous to me. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk Sent: Friday, October 28, 2005 5:07 AM To: [EMAIL PROTECTED];

RE: On Digital Cash-like Payment Systems

2005-11-14 Thread Whyte, William
Don't ever encrypt the same message twice that way, or you're likely to fall to a common modulus attack, I believe. Looks like it (common modulus attack involves same n, different (e,d) pairs). However, you're likely to be picking a random symmetric key as the message, and Schneier

RE: crypto for the average programmer

2005-12-12 Thread Whyte, William
In Peter Gutmann's godzilla cryptography tutorial, he has some really good (though terse) advice on subtle gotchas in using DH/RSA/Elgamal. I learned a few no-nos, such as not sending the same message to 3 seperate users in RSA (if using 3 as an encryption exponent). My question is, what

RE: crypto for the average programmer

2005-12-12 Thread Whyte, William
NIST, in its series of FIPS standards and Special Publications, has defined federal standards for digital signatures and modes of operation for symmetric ciphers, and is moving towards standardizing key exchange mechanisms based on public key algorithms. Those standards are also free, though

RE: crypto for the average programmer

2005-12-14 Thread Whyte, William
On 12/14/05, Peter Gutmann [EMAIL PROTECTED] wrote: I don't know if there's any site tracking this, but (as the tutorial says) you can either go with PKCS #1 (the de facto standard, easy to implement and widely used) ... Actually, I'm embarassed to admit this but I've seen PKCS

RE: quantum chip built

2006-01-17 Thread Whyte, William
From what I understand simple quantum computers can easily brute-force attack RSA keys or other types of PK keys. Is ECC at risk too? And are we at risk in 10, 20 or 30 years from now? Quantum computers break RSA, cryptosystems based on discrete log over finite fields, and cryptosystems

RE: conservative choice: encrypt then MAC (Re: general defensive crypto coding principles)

2006-02-09 Thread Whyte, William
Don't forget Bleichenbacher's error channel attack on SSL implementations, which focussed on the mac then encrypt design of SSL... web servers gave different error for malformed padding vs plaintext MAC failure. The lesson I drew from that is the conservative choice is encrypt then MAC.

RE: Status of attacks on AES?

2006-06-06 Thread Whyte, William
Isn't what you are referring to called secure number of rounds? In other words the number of rounds after which no known attack exists that can break the cipher faster than brute-forcing the key? It looks like I have no choice but to invent a new term, PRF rounds - the number of rounds

RE: Status of attacks on AES?

2006-06-07 Thread Whyte, William
Good, bad, right, wrong, correct, incorrect, meaningful, meaningless... Who knows? Don't ask us. We are simply trying to contribute something new that we strongly believe in Right. But can you explain *why* you strongly believe in it? William

RE: NIST hash function design competition

2006-07-21 Thread Whyte, William
Useful references are http://cr.yp.to/antiforgery/cachetiming-20050414.pdf -- the Bernstein paper www.wisdom.weizmann.ac.il/~tromer/papers/cache.pdf - related work by Eran Tromer. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Travis H.

RE: Locating private keys in RAM?

2006-09-07 Thread Whyte, William
Adi Shamir and Nicko Van Someren, Playing Hide and Seek with Stored Keys: http://citeseer.ist.psu.edu/vansomeren98playing.html Shamir, not Rivest. Easy mistake... William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Douglas F. Calvert Sent:

RE: Why the exponent 3 error happened:

2006-09-15 Thread Whyte, William
If so, I fear we are learning the wrong lesson, which while valid in other contexts is not pertinent here. TLS must be flexible enough to accommodate new algorithms, this means that the data structures being exchanged are malleable, and that implementations must validate strict

RE: Why the exponent 3 error happened:

2006-09-17 Thread Whyte, William
This is incorrect. The simple form of the attack is exactly as described above - implementations ignore extraneous data after the hash. This extraneous data is _not_ part of the ASN.1 data. James A. Donald wrote: But it is only extraneous because ASN.1 *says* it is

RE: A note on vendor reaction speed to the e=3 problem

2006-09-17 Thread Whyte, William
RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. This amounts to *not* using ASN.1 - treating the ASN.1 data as mere arbitrary padding bits, devoid of information content. Again, not quite right. You have to do a memcmp() and make

RE: A note on vendor reaction speed to the e=3 problem

2006-09-18 Thread Whyte, William
Anyway, the attack applies even if you throw away the ASN.1 data. If you ignore the ASN.1 data you expect the hash to be in a fixed byte position, so the attack does not apply. It's correct that the attack doesn't apply if you expect the hash to be in a fixed byte position. I would say

RE: RSA conference

2006-09-19 Thread Whyte, William
I've been notified that we had a paper accepted for the cryptographers' track. If you're concerned about that track, you could try contacting Masayuki Abe, the PC Chair, directly. If you're interested in other tracks I'm not sure what to suggest. William -Original Message- From: [EMAIL

RE: OpenSSL PKCS #7 supports AES SHA-2 ?

2006-10-12 Thread Whyte, William
PKCS#7 has been superseded by the IETF's Cryptographic Message Syntax, CMS. You should check within the S/MIME working group for updates. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Alten Sent: Saturday, October 07, 2006 12:29 AM