Re: key storage

[Ajay <abra9823 () mail usyd edu au>]

thanks everyone for your inputs.
this is supposed to be a moderately secure application (since we can never
have full security). The emphasis in the system is really on maintaining
privacy. Its a research prototype, the data stored are simple user models
(no bank account details) and the keys are used to provide some session
protection.

there will be methods to get the keys and forge sessions. The idea is
simply to increase the cost of getting those keys.

thanks again for your input to the discussion. Its given me plenty of stuff
to argue about in my thesis.

cheers


--
Ajay Brar,
CS Honours 2004
Smart Internet Technology Research Group


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


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