Re: [Cryptography] prism-proof email in the degenerate case

2013-10-11 Thread Nico Williams
On Thu, Oct 10, 2013 at 04:22:50PM -0400, Jerry Leichter wrote: > On Oct 10, 2013, at 11:58 AM, "R. Hirschfeld" wrote: > > Very silly but trivial to "implement" so I went ahead and did so: > > > > To send a prism-proof email, encrypt it for your recipient and send it > > to irrefrangi...@mail.uni

Re: [Cryptography] AES-256- More NIST-y? paranoia

2013-10-07 Thread Nico Williams
On Mon, Oct 07, 2013 at 11:45:56AM -0400, Arnold Reinhold wrote: > If we are going to always use a construction like AES(KDF(key)), as > Nico suggests, why not go further and use a KDF with variable length > output like Keccak to replace the AES key schedule? And instead of Note, btw, that Keccak

Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

2013-10-07 Thread Nico Williams
On Sat, Oct 05, 2013 at 09:29:05PM -0400, John Kelsey wrote: > One thing that seems clear to me: When you talk about algorithm > flexibility in a protocol or product, most people think you are > talking about the ability to add algorithms. Really, you are talking > more about the ability to *remo

Re: [Cryptography] AES-256- More NIST-y? paranoia

2013-10-06 Thread Nico Williams
On Fri, Oct 4, 2013 at 11:20 AM, Ray Dillinger wrote: > So, it seems that instead of AES256(key) the cipher in practice should be > AES256(SHA256(key)). More like: use a KDF and separate keys (obtained by applying a KDF to a root key) for separate but related purposes. For example, if you have a

Re: [Cryptography] The hypothetical random number generator backdoor

2013-09-25 Thread Nico Williams
On Sep 25, 2013 8:06 AM, "John Kelsey" wrote: > On Sep 22, 2013, at 8:09 PM, Phillip Hallam-Baker wrote: > > Either way, the question is how to stop this side channel attack. > > One simple way would be to encrypt the nonces from the RNG under a > > secret key generated in some other fashion. > >

Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan

2013-09-13 Thread Nico Williams
't care about active attacks, then you can get BTNS with minimal effort. This is quite true. At least some times we need to care about active attacks. > On Thu, 12 Sep 2013, Nico Williams wrote: > >Note: you don't just want BTNS, you also want RFC5660 -- "IPsec > >ch

Re: [Cryptography] Summary of the discussion so far

2013-09-13 Thread Nico Williams
On Fri, Sep 13, 2013 at 03:17:35PM -0400, Perry E. Metzger wrote: > On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams > wrote: > > Traffic analysis can't really be defeated, not in detail. > > What's wrong with mix networks? First: you can probably be observed using t

Re: [Cryptography] Summary of the discussion so far

2013-09-13 Thread Nico Williams
On Wed, Sep 11, 2013 at 04:03:44PM -0700, Nemo wrote: > Phillip Hallam-Baker writes: > > > I have attempted to produce a summary of the discussion so far for use > > as a requirements document for the PRISM-PROOF email scheme. This is > > now available as an Internet draft. > > > > http://www.iet

Re: [Cryptography] Why prefer symmetric crypto over public key crypto?

2013-09-13 Thread Nico Williams
On Mon, Sep 09, 2013 at 02:48:56PM -0400, Jeffrey I. Schiller wrote: > I don’t believe you can do this without using some form of public key > system. My $.02: - protocols based entirely on symmetric keying are either PSK or a flavor of Needham-Schroeder (e.g., Kerberos) - neither PSK nor N

Re: [Cryptography] Killing two IV related birds with one stone

2013-09-13 Thread Nico Williams
On Wed, Sep 11, 2013 at 06:51:16PM -0400, Perry E. Metzger wrote: > It occurs to me that specifying IVs for CBC mode in protocols > like IPsec, TLS, etc. be generated by using a block cipher in counter > mode and that the IVs be implicit rather than transmitted kills two > birds with one stone. >

Re: [Cryptography] [cryptography] very little is missing for working BTNS in Openswan

2013-09-13 Thread Nico Williams
On Mon, Sep 09, 2013 at 10:25:03AM +0200, Eugen Leitl wrote: > Just got word from an Openswan developer: > > " > To my knowledge, we never finished implementing the BTNS mode. > > It wouldn't be hard to do --- it's mostly just conditionally commenting out > code. > " > There's obviously a large p