Memo: RE: key storage

[tim.m.james () hsbc com]

Michael H,

Not knowing anything about the Length Extension Attack, I looked it up and
learned something, so thanks for that !

Having read about it, I don't see why this use is vulnerable at all. The
suggestion was to use a SHA-1 hash to generate a key, not as a message
digest. The Length Extension Attack is all about being able to create
correct Message Digests for extended messages, based on the knowledge of a
Message Digest for a certain shorter unknown message (and the message
length, as it happens).

In Ajay's case, at no point would the hash

H(salt+passphrase)

be visible to any attacker, which means the Length Extension Attack cannot
be used.

Just for completeness, the best statement of the Length Extension Attack
I've seen is

"Given the hash and length of some unknown message M I can find the hash of
some message N=M | Z (where M | Z means M concatenated with Z).
Z is a message of my choosing which has to begin with some special bits but
can end as I choose".

Would like to hear how you would use this attack in this case.

Tim





Michael Howard <mikehow () microsoft com> on 31 Aug 2004 19:58

To:    "Scovetta, Michael V" <Michael.Scovetta () ca com>
       "Brown, James F." <James.F.Brown () FMR com>
       Ajay <abra9823 () mail usyd edu au>
cc:    webappsec () securityfocus com
bcc:

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 originated from the Internet. Its originator may or
 may not be who they claim to be and the information contained in
 the message and any attachments may or may not be accurate.
******************************************************************





************************************************************
HSBC Bank plc
Registered Office: 8 Canada Square, London E14 5HQ
Registered in England - Number 14259
Authorised and regulated by the Financial Services Authority

Member of the HSBC Bank marketing group. We sell life assurance, pensions
and collective investment schemes and advise only on our own range of these
products.
************************************************************



This E-mail is confidential.  
It may also be legally privileged. If you are not the addressee you may not copy, 
forward, disclose or use any part of it. If you have received this message in error, 
please delete it and all copies from your system and notify the sender immediately 
by return E-mail.

Internet communications cannot be guaranteed to be timely secure, 
error or virus-free. The sender does not accept liability for any 
errors or omissions.