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
 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

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 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

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 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:

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
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

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 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:

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 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?

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: 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

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.
 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?

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

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 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)

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.

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

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 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

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 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

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 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

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 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

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 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]

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]; 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?

2005-09-17 Thread Whyte, William
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?

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 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?

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 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?

2005-09-15 Thread Whyte, William
$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

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 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

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 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?

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 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?

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 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?

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 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

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
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

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.

[ ... ]

 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

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 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

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 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]