[PATCH 07/10] password: add pbkdf2 support
plagnioj at jcrosoft.com
Mon Mar 16 04:25:07 PDT 2015
On 12:05 Mon 16 Mar , Jan Lübbe wrote:
> On Mo, 2015-03-16 at 12:01 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:49 Mon 16 Mar , Jan Lübbe wrote:
> > > On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > We will use "barebox_password" as salt and 10000 round to generate a
> > > > 64 bytes key.
> > >
> > > The purpose of a salt is to protect a against dictionary or
> > > rainbow-table (precomputed) attacks. That means that the Salt must be
> > > randomly generated and saved with the password.
> > This will be a enough stong enven with static one to protect against
> > reverse hack for barebox protection
> > Use a 32 byte pass try to do an attack agaist dictionary.
> > it will take you more than 10 years to break it
> > >
> > > For setting a new password in barebox, even a low entropy salt will make
> > > attacks significantly more expensive. So we should add some entropy from
> > > user interaction timing in that case.
> > yes we could do this too
> > >
> > > For hashing a password at compile time, we should get the salt from the
> > > host system.
> > yes
> > do we really need it?
> Yes, definitely. We must use the algorithms as they are intended to be
> If we try to move users away from RSA2048 because it will be vulnerable
> in the future, we should not go against established practice for
> password salts by hard-coding it.
I'm not against it but with the barebox entropy did not see the point to use
so how do we generate the salt? what length
Personnaly I'll prefer
a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 10000 round
result a 64 bytes password file <salt 32 byes><key 32 bytes>
More information about the barebox