RE: OpenSSL PKCS #7 supports AES SHA-2 ?
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 To: cryptography@metzdowd.com Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OpenSSL PKCS #7 supports AES SHA-2 ? After reading PKCS #1 v2 more closely and SHA-2 is not even in the specs, therefore OpenSSL PKCS #7 functions won't support SHA-2. This spec was last updated in 1998. PKCS Editor, is there a new update in progress by RSA Labs to incorporate SHA-2 and AES? Does OpenSSL implement PKCS #1 v2 or just v1.5? If the latter then not even SHA-1 is supported. PKCS editor, is there any timeline as to when PKCS #7 will then be updated with references to official OIDs, etc., for specifying SHA-2 and AES? Dr. Ron Rivest, are you going to publish new message-digest IETF RFCs for SHA-1 and SHA-2? (So that they can be referenced by an updated PKCS #7.) Mr. Russ Housley, can you weigh in with what happening in the IETF WG security area? I know that Mr. Eric Rescorla is working on a new TLS v1.2 draft. Will this be done/ratified soon? I assume OpenSSL will incorporate this soon thereafter? This mess with the MD5 and SHA-1 hashes is really starting to becoming a problem. It's certainly impacting new development projects/products I'm involved with using SSL and PKI certificates. My customers are concerned about using MD5 and SHA-1, and they don't want to keep paying for implementations repeatedly as the standards catch up to reality. Updating these various heavily used standards quickly is quite important. Sincerely (and thanks in advance for all of your replies), - Alex At 09:05 AM 10/6/2006 -0700, Alex Alten wrote: Does anyone know if the OpenSSL PKCS #7 functions support AES and SHA-2? (I assuming OpenSSL 0.9.7 or later.) Thanks, - Alex - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: RSA conference
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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Erik Zenner Sent: Tuesday, September 19, 2006 2:57 AM To: cryptography@metzdowd.com Subject: RSA conference Hi all! Has anyone heard any new about the RSA conference US 2007? The notification of authors should have been in August, now we are in the second half of September without having heard anything from the organizers. At the same time, their mail server keeps rejecting all mails that are sent to the RSA conference addresses [EMAIL PROTECTED] and [EMAIL PROTECTED] Since these are the only contact options offered, the conference organizers basically can not be reached. For a minor conference, I would consider this to be a very bad sign, but since this is RSA conference, I assume that things go as planned. Has anyone heard about problems or delays in organizing the conference? Thanks Erik -- Dr. Erik Zenner Phone: +45 39 17 96 06Cryptico A/S Chief Cryptographer Mobile: +45 60 77 95 41Fruebjergvej 3 [EMAIL PROTECTED] www.cryptico.com DK 2100 Copenhagen This e-mail may contain confidential information which is intended for the addressee(s) only and which may not be reproduced or disclosed to any other person. If you receive this e-mail by mistake, please contact Cryptico immediately and destroy the e-mail. Thank you. As e-mail can be changed electronically, Cryptico assumes no responsibility for the message or any attachments. Nor will Cryptico be responsible for any intrusion upon this e-mail or its attachments. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: A note on vendor reaction speed to the e=3 problem
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 that it's incorrect that there was no chance of it being screwed up in the absence of ASN.1. But I'm happy to agree to disagree at this point. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Why the exponent 3 error happened:
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 extraneous. No. It's not the ASN.1 that says it's extraneous, it's the PKCS#1 standard. The problem is that the PKCS#1 standard didn't require that the implementation check for the correct number of ff bytes that precede the BER-encoded hash. The attack would still be possible if the hash wasn't preceded by the BER-encoded header. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: A note on vendor reaction speed to the e=3 problem
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 sure you've got the right arbitrary padding bits. Anyway, the attack applies even if you throw away the ASN.1 data. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Why the exponent 3 error happened:
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 adherence to a specifically defined form for the agreed algorithm, but the ability to express other forms cannot be designed out. There is no need, ever, for the RSA signature to encrypt anything other than a hash, nor will their ever be such a need. In this case the use of ASN.1 serves absolutely no purpose whatsoever, other than to create complexity, bugs, and opportunities for attack. It is sheer pointless stupidity, complexity for the sake of complexity, an indication that the standards process is broken. I think this is a bit unfair. PKCS#1 signatures were originally designed to include a hash identifier to address a specific concern, arising from the fact that RSA signers can freely choose the hash algorithm to use. Say that Alice uses SHA-1 to generate her signature on m, and SHA-1(m) = h. Then the concern is that Bob can find a broken hash function BASH such that BASH(m') = h. If he can do that and format a message that claims to be signed with RSA and BASH, then he can present Alice's signature as a valid signature on m'. There are a number of different protections against this. For example, Alice's cert could identify her key as only to be used with SHA-1 (this is effectively what happens with DSA public keys). However, the convention has been to mark an RSA key in an X.509 cert as rsaEncryption and not specify in the AlgorithmIdentifier that it's only to be used with a certain hash function (or signature scheme). So PKCS#1 incorporated the hash identifier, which prevents a signature generated with one hash algorithm from being used with a different hash algorithm. (Since then, Burt Kaliski's done some research on the use of hash firewalls of this type: see http://www.rsasecurity.com/rsalabs/node.asp?id=2020. His conclusion is that by and large they aren't necessary, but that isn't relevant to the discussion here). At the time, ASN.1 was in widespread use, so it was an obvious decision (rather than pointless stupidity) to use it to encode the hash function identifier. In practice, the ASN.1 doesn't introduce complexity because most implementations (certainly ones I've worked on) simply treated it as a memcmp rather than wheeling out the heavy ASN.1 machinery. The real problem isn't ASN.1; the problem is that an encoding method was used for the rest of the signature that didn't specify the length of the signature block and it didn't occur to anyone to check it. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Locating private keys in RAM?
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: Tuesday, September 05, 2006 2:14 AM To: cryptography@metzdowd.com Subject: Locating private keys in RAM? Hello, I remember seeing a paper about identifying private keys in RAM. I thought it was by Rivest but I can not locate it for the life of me. Does anyone remember reading something like this? The basic operation was to identify areas in RAM that had certain characteristics such as random bits and identifiable key headers... Any help would be greatly appreciated... -- --dfc [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: NIST hash function design competition
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. Sent: Friday, July 21, 2006 9:09 AM To: Florian Weimer Cc: Hal Finney; [EMAIL PROTECTED]; cryptography@metzdowd.com Subject: Re: NIST hash function design competition On 7/20/06, Florian Weimer [EMAIL PROTECTED] wrote: Is this about Colin Percival's work? The paper was by Dan Berstein; Percival's comments are specific to hyperthreading, but I think djb's research showed that it's applicable to non-HT architectures as well. -- Follow where reason leads -- Zeno || Unix guru for rent or hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Status of attacks on AES?
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 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Status of attacks on AES?
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 after which each function that defines the value of each bit of the block/state/output is a pseudo-random function (PRF) of all the bits of the block/state/key/input, in other words a function indistinguishable from random by any existing general purpose randomness tests. Of course dedicate randomness tests exploiting the cipher structure and utilising a significant amount of computational resources could be effective in distinguishing a larger number of rounds from random, but that's in the area of the secure number of rounds research. Can you briefly explain how you determine the PRF rounds value? William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: conservative choice: encrypt then MAC (Re: general defensive crypto coding principles)
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. Bleichenbacher's attack focused on RSA PKCS#1 decryption. You're thinking of Vaudenay's, which focused on CBC padding errors. There are other lessons to draw too, most notably: don't ever let the sender know the reason why a decryption-and-authentication failed. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: quantum chip built
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 based on discrete log over elliptic curves, where break means reduce to polynomial time. The best description of the ECC variant of Shor's quantum algorithm is in Proos and Zalka's Shor's discrete logarithm quantum algorithm for elliptic curves, http://arxiv.org/abs/quant-ph/0301141. They estimate that ~1000 qubits are needed to break a 160-bit ECC key (as opposed to ~2000 qubits for a 1024-bit RSA key). NTRU and HFE-based schemes (such as QUARTZ and SFLASH) aren't currently known to be broken by quantum algorithms -- there are proposed quantum algorithms that may square-root the time to break NTRU, but this isn't a reduction to polynomial time. I don't know if anyone's looked at quantum computers as applied to HFE. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto for the average programmer
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 before but never with enough context to know what it was; I thought it was some kind of RSA proprietary mumbo-jumbo. But, oh dear, it involves ASN.1. That rules out use by the layperson. I've run into ASN.1 before with regard to SNMP, and it struck me as infinitely more complex than anything I'd ever need to query packet counts on my router. Have a look at PKCS#1. There's hardly any ASN.1 in it at all and the structures are relatively simple. There's also a PKCS examples document that talks you through it. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto for the average programmer
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 is the layperson supposed to do, if they must use crypto and can't use an off-the-shelf product? Check the standards. The RSA PKCS#1 standard, which are free, describe how to do RSA securely and summarize known security results. http://www.rsasecurity.com/rsalabs/node.asp?id=2124. Don't use PKCS#3-style Diffie Hellman; it's been superseded by the versions in ASC X9.42 and IEEE Std 1363-2000. The Standards for Efficient Cryptography Group (www.secg.org) publishes SEC1, which describes how to do Elliptic curve algorithms securely. The standard is free to download, but note that some techniques in it have licensing requirements. 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 they sometimes reference non-free standards. Other standards groups, such as the IEEE P1363 Working Group (which I chair -- http://grouper.ieee.org/groups/1363/) and the ASC X9F1 working group for cryptographic techniques for the financial services industry, publish (for purchase) standards for secure use of other public-key algorithms. 1363 is currently working on - Lattice-based cryptography, such as NTRU (who I work for) - Password-based public key techniques such as SPEKE, SRP, etc - A revision of the 1363-2000 standard. A lot of the documents relevant to these projects are available for free off the site. X9 is working on a wider range of projects, but your company has to be an X9 member for you to access them. Is there any site tracking such gotchas as they show up in the literature? Rather than tracking gotchas minute-by-minute it's probably best to use existing standards. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: crypto for the average programmer
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 they sometimes reference non-free standards. Sorry, meant to include links for these: Overall home page: http://csrc.nist.gov/focus_areas.html#csa FIPS: http://csrc.nist.gov/publications/fips/index.html Special Publications: http://csrc.nist.gov/publications/nistpubs/ Wiliam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: On Digital Cash-like Payment Systems
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 even suggests picking a random r in Z_n and encrypting hash(r) as the symmetric key. More generally, I wonder about salting all operations to prevent using the same value more than once. It seems like it's generally a bad idea to reuse values, as a heuristic, and applying some kind of uniquification operation to everything, just as it's a good idea to pad/frame values in such a way that the output of one stage cannot be used in another stage of the same protocol. I forget the beginning of this conversation... but if you're salting all public-key encryption operations you may as well just use a standard RSA encryption scheme, such as OAEP or RSA-KEM. OAEP is specified in PKCS#1, available from http://www.rsasecurity.com/rsalabs/node.asp?id=2125; it's well- studied and has a proof of security, and should certainly be used in preference to any home-grown system. If you were talking about salting something other than public key operations, accept my apologies... William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: [EMAIL PROTECTED]: Skype security evaluation]
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]; cryptography@metzdowd.com Subject: Re: [EMAIL PROTECTED]: Skype security evaluation] Wasn't there a rumor last year that Skype didn't do any encryption padding, it just did a straight exponentiation of the plaintext? Would that be safe, if as the report suggests, the data being encrypted is 128 random bits (and assuming the encryption exponent is considerably bigger than 3)? Seems like it's probably OK. A bit risky perhaps to ride bareback like that but I don't see anything inherently fatal. CP - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: ECC patents?
I'm not sure what you're trying to demonstrate here. From the fact that NSA chose to license a few curves, we can definitely deduce that they want to use those curves. You deduce from the fact that they didn't license other curves that there is no patent on those curves, but you could equally well deduce that the curves they did license are good enough and they don't need to pay extra money to license on the other curves. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James A. Donald Sent: Friday, September 16, 2005 11:53 PM 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 field curves where the prime was : : greater than 2255. On the NIST list of curves : : 3 out of the 15 fit this field of use: the : : prime field curves with primes of 256 bits, : : 384 bits and 521 bits. Of the NIST list of fifteen, nine are 256 bits or longer. Presumably, if NSA thought certicom had a case, they would have licensed at least the other six NIST curves as well, and most likely the other twelve. The three curves that are licensed look different from the other twelve, though I have no idea of the significance of this, if any. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ZKrN4sA2qyTNIC90h3U/8Er848IPFGfUOQyBxm8h 4xlZJBIqZwgUkOyqgxTzTBcauENSjU46x6oDgn2X4 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: ECC patents?
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 uncompressed point implementations o Use of elliptic curve MQV and ECDSA under the above conditions This hints that indeed only some particular curves are patented. 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 curves, or it could be that operations on those curves aren't patented. The presentation doesn't give enough information to establish which. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: ECC patents?
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 particular curves have been licensed. It could be that NSA has decided not to buy a license for the other curves, or it could be that operations on those curves aren't patented. The presentation doesn't give enough information to establish which. If the NSA paid anything significant for any of the curves, we would be told. Therefore the NSA paid nothing or almost nothing, and therefore if the NSA licensed anything, it would have licensed everything. I doubt that the NSA paid any money whatsoever for this license, making it profoundly unimpressive as evidence that *any* curves have a plausible valid patent. If the NSA paid real money, the patent holders would be sticking it in our face as a price setting precedent. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG uFGgCOtWvwFnmCL5tYGLSloqyccg5nCjgOZZ2xdW 4NjnEzQaXNpdg5TTfRnBvcrjTbnHJ6AGsfz5BcvsG - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: ECC patents?
$25MM figure: http://lists.jammed.com/ISN/2003/10/0097.html More details about what's covered: http://www.nsa.gov/ia/industry/crypto_elliptic_curve.cfm http://www.nsa.gov/ia/industry/crypto_suite_b.cfm 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 particular curves have been licensed. It could be that NSA has decided not to buy a license for the other curves, or it could be that operations on those curves aren't patented. The presentation doesn't give enough information to establish which. If the NSA paid anything significant for any of the curves, we would be told. Therefore the NSA paid nothing or almost nothing, and therefore if the NSA licensed anything, it would have licensed everything. I doubt that the NSA paid any money whatsoever for this license, making it profoundly unimpressive as evidence that *any* curves have a plausible valid patent. If the NSA paid real money, the patent holders would be sticking it in our face as a price setting precedent. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG uFGgCOtWvwFnmCL5tYGLSloqyccg5nCjgOZZ2xdW 4NjnEzQaXNpdg5TTfRnBvcrjTbnHJ6AGsfz5BcvsG - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: I'll show you mine if you show me, er, mine
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 either party to send the password itself at the end. William -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 23, 2005 7:30 AM To: cryptography@metzdowd.com; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: I'll show you mine if you show me, er, mine R.A. Hettinga [EMAIL PROTECTED] forwarded: Briefly, it works like this: point A transmits an encrypted message to point B. Point B can decrypt this, if it knows the password. The decrypted text is then sent back to point A, which can verify the decryption, and confirm that point B really does know point A's password. Point A then sends the password to point B to confirm that it really is point A, and knows its own password. Isn't this a Crypto 101 mutual authentication mechanism (or at least a somewhat broken reinvention of such)? If the exchange to prove knowledge of the PW has already been performed, why does A need to send the PW to B in the last step? You either use timestamps to prove freshness or add an extra message to exchange a nonce and then there's no need to send the PW. Also in the above B is acting as an oracle for password-guessing attacks, so you don't send back the decrypted text but a recognisable-by-A encrypted response, or garbage if you can't decrypt it, taking care to take the same time whether you get a valid or invalid message to avoid timing attacks. Blah blah Kerberos blah blah done twenty years ago blah blah a'om bomb blah blah. (Either this is a really bad idea or the details have been mangled by the Register). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SHA-1 results available
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 provided in a forthcoming paper. I'm not holding my breath. A preprint was circulating at the RSA conference; Adi Shamir had a copy. Similar techniques were used by Vincent Rijmen and Elizabeth Oswald, in their paper available at .http://eprint.iacr.org/2005/010. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Are new passports [an] identity-theft risk?
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 distance, saying a person's keys, bag and body interfere with the radio waves. Who was it that pointed out that radio waves don't interfere, rather, receivers can't discriminate? Absolutely. I'd add that while it's *currently* hard to read at a distance, passports typically have a lifetime of 10 years and I'd be very surprised if the technology wasn't significantly better five years out. William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: How thorough are the hash breaks, anyway?
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 Message- From: Matt Crawford [mailto:[EMAIL PROTECTED] Sent: Monday, August 30, 2004 11:47 AM To: Ian Grigg Cc: Daniel Carosone; crypto Subject: Re: How thorough are the hash breaks, anyway? certificates. The public key data is public, and it's a random bitpattern where nobody would ever notice a few different bits. If someone finds a collision for microsoft's windows update cert (or a number of other possibilities), and the fan is well and truly buried in it. Correct me if I'm wrong ... but once finding a hash collision on a public key, you'd also need to find a matching private key, right? But the odds are that you'd get an easy-to-factor modulus. Would the casual relying party ever notice that? I think not. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: How thorough are the hash breaks, anyway?
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 AM To: Ian Grigg Cc: Daniel Carosone; crypto Subject: Re: How thorough are the hash breaks, anyway? certificates. The public key data is public, and it's a random bitpattern where nobody would ever notice a few different bits. If someone finds a collision for microsoft's windows update cert (or a number of other possibilities), and the fan is well and truly buried in it. Correct me if I'm wrong ... but once finding a hash collision on a public key, you'd also need to find a matching private key, right? But the odds are that you'd get an easy-to-factor modulus. Would the casual relying party ever notice that? I think not. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL
[ 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 analysis paper, avaiable from: http://www.counterpane.com/ssl.html Read it to get a good idea of why certain decisions were made, and why they help. It doesn't tell you how to use OpenSSL, but it's great to let you know what's going on under the bonnet. (I kindof feel like the new Ferguson Schneier book would have been better if it had simply been this paper expanded to book length...) Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: replay integrity
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. [ ... ] SSL just doesn't address the security needs of protocols as well as all that. Where I've seen it used, the core need for it is privacy of the data stream, not anything else. Maybe so, but if you don't have integrity checking, so that an attacker can inject packets into the stream, this can often compromise privacy too. For example, consider Serge Vaudenay's CBC padding attack. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Fwd: [IP] A Simpler, More Personal Key to Protect Online Messages
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 substitute doesn't allow for this. But you don't have to contact the CA to get someone's certificate. A standard way is to send them an email saying can you send me a signed message? This also ensures you have the right public key. I haven't studied the details of IBE, but I assume that (a) there may be multiple IBE-based CAs, with different parameters, and (b) the identity that's used to encrypt will be not just a name, but a name and a date (to ensure that some revocation-like capability exists). In either case, you can't simply pick the email address and use it as the public key; you need to establish some additional information first. This seems to put us back in the same place as with standard PKI, usability-wise. (Or, rather, there may be a usability delta for IBE, but it's very small). When you add to this the fact that the server knows your decryption key... I really don't see why this is worth getting excited about commercially, or even from an engineering perspective. It's cool maths, though. Cheers, William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
New NTRUEncrypt Parameters
(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 information that eventually allows an attacker to recover the private key. The results do not affect the known difficulty of the underlying class of lattice problems; however, they show that care must be taken in choosing parameters to ensure that decryption failures occur with negligible or zero probability, even in the presence of an adversary who is actively trying to cause such failures. NTRU Cryptosystems is proposing slightly altered parameter sets which decrease the probability of average-case decryption failures, and a padding scheme which ensures that an attacker cannot increase the probability of decryption failures above this average-case probability. The new documents analyze the strength of the new parameter sets against all known attacks on NTRU (lattice-based, meet-in-the- middle, and decryption failure based) and show that for N=251 we comfortably achieve 2^80 security against all of these attacks. We also provide the first ever full proof of security to be presented for NTRUEncrypt. If anyone has any questions, I'll be happy to answer them. Cheers, William === William Whyte Director, Cryptographic RD NTRU Cryptosystems 5 Burlington Woods Burlington, MA 01803 tel: +1.781.418.2500 fax: +1.781.418.2532 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
