Date: Tue, 15 Jun 2010 08:12:29 -0400
From: Jeffrey Walton <noloader@...il.com>
To: "Thor (Hammer of God)" <Thor@...merofgod.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Introducing TGP...

Hi Thor,

This is focused less on the fact that message m is a private key, and
more on good crypto and how to encrypt/authenticate a message m in
general.

> The SHA256 hashing of the private key may not result in authenticity
> assurances on the key (if I'm reading it correctly). I believe that's
> an Athenticate-then-Encrypt scheme, and the details of the
> interactions in AtE can be tricky.

I had an opportunity to sleep on this, so here's my two cents. If I
read the docs correctly, this construction is:

ENC( HASH(m) || m )

Good news: Handbook of Applied Cryptography recommends the
construction as a message integrity code (see HAC, Section 9.6). Bad
news: the HAC is kind of old, the crypto landscape has changed, and
this is no longer recommended.

ENC( HASH(m) || m ), and variants such as ENC( m || HASH(m) ), suffer
from extension attacks. So HASH(m) does not provide any assurances on
m. Others have tried to fix the construction with some variation of
length added to the hash:

ENC( LEN(m) || HASH(m) || m ) or ENC( HASH( LEN(m) || m) || m ) or ...

As the interactions are tricky (and NIST took a different approach), I
will not use it. First, standards bodies (such as IEEE, ANSI, and
NIST) discarded unkeyed hasing in favor of keyed hashing. Next, an
ipad and opad (inner padding and outer padding) were added. So this
gets us to the following, which might work:

ENC( HMAC(m) || m )

My complaints with the above are (1) interations in an
Athenticate-then-Encrypt are tricky, (2) there are cipher modes
available (namely, 'authenc' modes) which add authenticity assurances,
and (3) I have not encountered the scheme in the wild, so its
something I have been required to research (ie, I know very little
about it).

> Perhaps a more traditional Encrpyt-then-Authenticate
> (for example, IPSec) might be useful for TGP.

Prior to the standardization of authenticated encryption modes, the
community had to pair a block cipher with an authenticator. The block
cipher was usually 3DES or AES, the mode was CBC, and the
authenticator was a CBC-MAC, HMAC, or CMAC.

Pairing and *properly constructing* a block cipher operated in CBC
mode with a CBC-MAC was what Krawczyk proved to be generically secure.
He did *NOT* prove others were not secure - they have to be evaluated
on a case-by-cases basis (and the interactions cabe be tricky). So
nearly everyone selected the following (which is
Encrypt-then-Autenticate):

CBC-MAC(CBC-ENC(m))

The residue of CBC mode encryption (the CBC-MAC), acts a a PRF just as
the hash, but it is keyed. The 'residue of CBC mode encryption' is a
second, separate pass over the data.

We now have modes specifically designed for authenticated encryption
('authenc'): CCM and GCM. Instead of the pairing of a CBC-MAC and CBC
mode encryption, all we have is:

CCM(m) or GCM(m)

If you don't need a NIST approved mode, use Bellare, Rogaway, and
Wagner's EAX. Its superior in many respectes to CCM and GCM. There are
other authenc modes: CWC and XCBC to name a couple (see
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_development.html). As
a benefit to using EAX, Dr. Wagner hangs out on sci.crypt on occasion,
so he's available to the community. (Wagner the same fellow who broke
Netscapes RNG, with Ian Goldberg, way back when. See
http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html).

Jeff

On Mon, Jun 14, 2010 at 4:22 AM, Jeffrey Walton <noloader@...il.com> wrote:
> Hi Thor,
>
> I'm probably splitting too fine a hair here...
>
> The SHA256 hashing of the private key may not result in authenticity
> assurances on the key (if I'm reading it correctly). I believe that's
> an Athenticate-then-Encrypt scheme, and the details of the
> interactions in AtE can be tricky. Hugo Krawczyk evaluated similar AtE
> systems (for example, SSL) in The Order of Encryption and
> Authentication for Protecting Communications. The two AtE schemes
> which are provably secure are (1) a block cipher operated in CBC mode,
> and (2) stream ciphers which XORs data with a pseudorandom pad.
>
> I can see where the hash might satisfy the psuedo random pad, but I
> don't see the stream cipher in the equation. Perhaps a more
> traditional Encrpyt-then-Authenticate (for example, IPSec) might be
> useful for TGP.  [At least TGP is not using Authenticate-and-Encrypt,
> which Krawczyk proved insecure (for example, early SSH)].
>
> If your using SHA-256 as the PRF of a KDF, then TGP might be reducing
> the security of the system protecting the private assymmetric key (I'm
> presuming AES-256 was chosen for a reason). AES-256 provides a
> security level of ~2^255, while SHA-256 provides ~2^128. Its mostly a
> theoretical observation: I'd attack the password/passphrase before
> attempting pre-image attacks on the hash. [After all these years,
> SHA-160 has only been reduced to ~2^50 from a theoretical 2^80, and
> 2^50  is still beyond my reach].
>
> Jeff
>
> On Sun, Jun 13, 2010 at 5:44 PM, Thor (Hammer of God)
> <Thor@...merofgod.com> wrote:
>>
>> This is what I’ve been talking about... Here is the first part of the docs I wrote up - make sure you see that I'm not yet supporting huge files unless you have huge RAM.  **.Net 4.0 Client profile is required to run this.**
>>
>> Right now the install bits are only available on the pilot site at: http://www.owa.hammerofgod.com in the downloads section.   I have to wait on Raging Haggis to return from Canada before posting on www.hammerofgod.com .
>>
>> Here's a bit from the TGP Overview document included with the install and on the web site.  Please read through it before asking silly questions. :)
>>
>> Also, feel free to hack it up as much as you would like.  I know this is full disclosure, so feel free to zing them at me, or if you prefer, I can work with you on any issues you might have
>>
>> Remember, this is totally free, so my ability to handle custom requests will be limited.  For those looking to break it, I would look at fuzzing the XML documents and the "drag and drop public XML" parsing feature.
>>
>> If you have questions or challenges about any of the security, I would ask to keep it on the list so that everyone can get the full benefit of productive security development.   The read-me should pretty much lay everything out for you.  If not, we'll take it up from there.
>>
>> t
>>
>> [SNIP]

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists