Re: key storage

["Jason Coombs PivX Solutions" <jcoombs () PivX com>]

The original question posed a common scenario of a passphrase-encrypted key file. Ajay presented the general question 
'what do I need to know, and can I just use the SHA-1 hash of the passphrase as the secret key used to encrypt the key 
file?' (to summarize the discussion thus far)

Now, if we add salt as the two Michaels propose, we end up with a salt storage problem. Since the salt impacts the 
secret key, and without the secret key we can't get at our stored keys, we have to store our salt or have some way to 
regenerate the same salt each time, which is mostly pointless cleverness.

The basic question is: anything wrong with just enciphering the key file with a key generated by hashing the passphrase?

The answer is: because you are not actually generating a proper symmetric encryption key using a random or pseudorandom 
seed, you are still giving only as much defense against cryptanalysis as the length and obscurity of your input 
passphrase offers.

A hash of letters and numbers has a significantly smaller keyspace than its resulting bit length. You are thus really 
only getting some small key length, effective, despite the fact that you are dealing with a cipher that uses much 
larger keys. A cryptanalyst can precompute every possible hash of your letters-and-numbers-only passphrases, or 
otherwise brute force using only the subset of keys that your hash-based key generation algorithm might produce, and 
succeed in locating the correct key far easier than would otherwise be the case.

This doesn't mean you have an exploitable flaw in your system, as you still end up with one unique secret key per 
unique input passphrase, it just means that the core weakness is your input passphrase, since it is not going to have 
as many possibilities as we normally wish to see for properly-randomized key generation.

This is a limitation of any passphrase-based key generation for encryption, and you cannot magically transform 
passphrase-based encryption into full-keyspace-large-keylength protection by adding salt or being more clever than just 
doing the hash you've decided is good enough for the value of the secrets you're protecting.

I'll steal all your secrets through the use of a keylogger device, shoulder surfing, or torture until you tell me your 
passphrase, regardless, so don't think that perfect cryptography results in anything other than the appearance of data 
security. In creating perfect computer security we may inadvertently be causing a loss of real safety against any truly 
motivated adversary who thinks the value of our secrets justifies extreme measures to extract them.

Sincerely,

Jason Coombs
Director of Forensic Services
PivX Solutions, Inc.
http://www.PivX.com/forensics/


------Original Message------
From: Michael Howard
To: Scovetta, Michael V
To: Brown, James F.
To: Ajay
Cc: webappsec () securityfocus com
Sent: Aug 31, 2004 8:58 AM
Subject: RE: key storage

Michael, you're suggestion of using SHA-1(passphrase + salt) is
vulnerable to a somewhat esoteric cryptographic attack called a "Length
Extension Attack"

You should use:

H(salt,H(passphrase))

Instead.

The attack is touched upon in Ferguson's Practical Cryptography.

[Writing Secure Code] http://www.microsoft.com/mspress/books/5957.asp
[Protect Your PC] http://www.microsoft.com/protect
[Blog] http://blogs.msdn.com/michael_howard

[On-line Security Training]
http://mste/training/offerings.asp?TrainingID=53074


-----Original Message-----
From: Scovetta, Michael V [mailto:Michael.Scovetta () ca com] 
Sent: Tuesday, August 31, 2004 7:04 AM
To: Brown, James F.; Ajay
Cc: webappsec () securityfocus com
Subject: RE: key storage

I would add a comment here (obviously):
        Don't use the SHA-1 hash of the passphrase, but rather, the
SHA-1 hash of the (passphrase+salt). Otherwise, you rely on the choice
of passphrase to protect against dictionary attacks.

Mike


-----Original Message-----
From: Brown, James F. [mailto:James.F.Brown () FMR com] 
Sent: Monday, August 30, 2004 10:01 AM
To: Ajay
Cc: webappsec () securityfocus com
Subject: RE: key storage

No problem. That's the "best practice", I believe.

- Jim

-----Original Message-----
From: Ajay [mailto:abra9823 () mail usyd edu au] 
Sent: Monday, August 30, 2004 9:29 AM
To: Brown, James F.
Cc: webappsec () securityfocus com
Subject: RE: key storage


yup, thats the idea. do you see any problems with it

cheers


Quoting "Brown, James F." <James.F.Brown () FMR com>:

> You're going to use the SHA-1 hash of the passphrase as the actual key
> for the symmetric encryption, right?
>
> ================================
> James F. Brown  CISM, CISA
> Sr. Director, Information Security
> Fidelity Investments
> james.f.brown () fmr com
> http://www.fidelity.com
>
>
> -----Original Message-----
> From: Ajay [mailto:abra9823 () mail usyd edu au]
> Sent: Saturday, August 28, 2004 12:25 AM
> To: Brown, James F.
> Cc: George Capehart; webappsec () securityfocus com
> Subject: RE: key storage
>
>
> thanks.
> from responses on other mailing lists, i am moving towards the idea of
> having some sort of proxy server application which at startup is
> supplied
> a passphrase. it uses the passphrase to decrypt a passphrase encrypted
> file and loads keys from there. the file itself can be removed then
> my main application can then query the proxy when it needs the keys.
> ofcourse this introduces the problem of securing the exchange between
> the
> main and the proxy.
> the reason i have the proxy in the first place is because my main app
is
> a
> bunch of cgi scripts where state is stored by only writing to a file
and
> i
> do not have access to the webserver where the application is hosted.
> it will all be remarkable slow though...
>
> cheers
>
> --
> Ajay Brar,
>
> Quoting "Brown, James F." <James.F.Brown () FMR com>:
>
> > Chapter 8 in Applied Cryptography only discussed key storage in
areas
> > where users are involved. If you have an server application that
uses
> > crypto with no users involved, it doesn't offer much help. I'll
check
> > Bruce's newer book "Practical Cryptography" to see if he's addressed
> > that topic, but I won't be able to report on it until Monday.
> >
> > ================================
> > James F. Brown  CISM, CISA
> > Sr. Director, Information Security
> > Fidelity Investments
> > james.f.brown () fmr com
> > http://www.fidelity.com
> >
> >
> > -----Original Message-----
> > From: George Capehart [mailto:gwc () acm org]
> > Sent: Thursday, August 26, 2004 1:41 PM
> > To: webappsec () securityfocus com
> > Subject: Re: key storage
> >
> >
> > On Wednesday 25 August 2004 21:12, Ajay allegedly wrote:
> > > and also is there any significant paper on key storage - a journal
> or
> > > conference paper?
> > > its for my thesis and it would be nice if i could quote a the
> > > findings of some paper
> >
> > Ajay,
> >
> > There has been *lots* written about key storage.  It's a pretty
> > important topic . . . :>  Google is your friend.  A great place to
> > start, though is Chapter 8 (Key Management) in_Applied_Cryptology
> > (ISBN 0-471-11709-9) by Bruce Schneier.
> >
> > Cheers,
> >
> > George Capehart
> > --
> > George W. Capehart
> >
> > Key fingerprint:  3145 104D 9579 26DA DBC7  CDD0 9AE1 8C9C DD70 34EA
> >
> > "With sufficient thrust, pigs fly just fine."  -- RFC 1925
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.