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 <noloa...@gmail.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) > <t...@hammerofgod.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/