Re: Importance of salt

From: Dominick Baier [DevelopMentor] (dbaier_at_pleasepleasenospamdevelop.com)
Date: 09/15/05 

Date: Thu, 15 Sep 2005 07:49:28 -0700

Hello vla10d@gmail.com,

inline

> If I want to avoid static salt, I have to generate it somehow, and
> then store it so I can use it when decrypting, right? If I store it in
> a message, again, whats the point? The attacker can again retrieve the
> salt and use it with his dictionary.

again, the salt helps against precomputed tables

>
> I repeat, the assumption is that we are using an publicly available
> software for encryption, so the attacker can decompile it or do
> whatever he wants with it.

thats always the assumption in crypto. Only the key is secret - nothing else.

>
> As for the iteration count... if I understood you correctly, all this
> does is increase the time that it takes to generate the key from the
> password? In other words, if I use 10 iterations to generate the
> key/hash for the password, that key can ONLY be generated with the
> same password and exactly 10 iterations? The attacker would have to
> run 10 iterations for each word in his dictionary to get the key,
> assuming he even knows the correct iteration count used.

yes exactly, but we are talking 50.000 iterations or more - it is really
there to slow down the attacker

That all said - this is not the usual approach for encryption. To minimize
risk when using password based keys:

a) enforce strong, non dictionary passwords
b) encrypt the data using a randomly created key
c) encrypt the random key with the password generated key (add salt if you
like, but does not improve security dramatically IMO)
d) store the encrypted key

now an attacker has 2 choices

a) mount an attack against the encrypted data. infeasible as a full entropy
random key was used
b) mount an attack against the encrypted key. Also hard because it will not
be easy to distinguish between valid and invalid data when trying to decrypt.

makes sense?

>
> Thanks again for your help,
>
> V.
>
> Dominick Baier [ DevelopMentor ] wrote:
>
>> Hello vla10d@gmail.com,
>>
>> first of all - you are mixing some terms here
>>
>> Encryption - the term salt isn't commonly used here, you may think of
>> an
>> IV (initialization vector) which is used to start a feedback chain
>> when using
>> CBC.
>> but i think you really mean hashing (e.g. for passwords) -
>>
>> salted hashes are : H(salt+password)
>>
>> reasons for salting
>>
>> a) you are not leaking information, e.g. if alice and bob have the
>> same password
>> - the resulting hash would be the same - not with salted hashes
>> b) there a tables of pre-computed hashes, so e.g. you encounter a
>> hashed
>> password of "HJK)((bbnmm" - all you have to do is, look up that table
>> for
>> the hash and retrieve the clear text value. If you use salted hashes,
>> you
>> cannot use pre-computed tables, but have to calculate the hash on
>> each try.
>> this takes time.
>> By using PasswordDeriveBytes with a high iteration count, you even
>> raise the bar
>>
>> a) the attacked does not know the iteration count from looking at the
>> hash
>> b) it takes even longer now to mount brute force/dictionary attacks -
>> say
>> a simple hash needs 1 ms - and a iterated hash 1 s to calculate -
>> this makes
>> password guessing really infeasible
>> this all depends of course on the password complexity and the
>> computing power the attackers has at his disposal.
>>
>> you are basically buying time.
>>
>> That said - go for salted, iterated hashes by using
>> PasswordDeriveBytes - or even better the new .NET 2.0
>> Rfc2898DeriveBytes class.
>>
>> ---------------------------------------
>> Dominick Baier - DevelopMentor
>> http://www.leastprivilege.com
>>> Hello,
>>>
>>> I have one question regarding the importance of salt in encryption.
>>>
>>> As I understand, the salt is used to prevent dictionary attacks.
>>> Also, it is recommended that the salt isn't always the same, and
>>> that it should be randomly generated for each message. This random
>>> salt should then be stored in the encrypted message, as a prefix for
>>> example, so that it could be retrieved during the decryption.
>>>
>>> Now, I don't understand how this helps with dictionary attacks? For
>>> example, if the attacker knows that the first 8 bytes for example
>>> are salt, can't he simply modify his attacking program to include
>>> that salt for each word he retrieves from the dictionary? The
>>> assumption here is that the attacker gets access to the original
>>> encryption software as well as the message.
>>>
>>> Secondly, can someone explain how do the increased interations in
>>> PasswordDeriveBytes help?
>>>
>>> Thanks for your help,
>>>
>>> V.
>>>

Relevant Pages

  • Re: Importance of salt
    ... generate a key which is then used for encryption. ... The salt is used on ... The attacker really couldn't use his ... As for the iteration count... ...
    (microsoft.public.dotnet.security)
  • Re: [PATCH] 2.6.16.16 Parameter-controlled mmap/stack randomization
    ... I'm trying to control the stack and heap randomization via command-line ... That's why we have 8M stack and 1M mmap. ... Let us also assume that an attacker has an efficient way to ... Third iteration is 10,000,000 attacks and 5,000 newly infected. ...
    (Linux-Kernel)
  • Re: Importance of salt
    ... That is the problem with using one-way hash ... The salt is used on ... The attacker really couldn't use his ... > even knows the correct iteration count used. ...
    (microsoft.public.dotnet.security)
  • Vulnerability in encrypted loop device for linux
    ... An attacker is able to modify the content of the encrypted device ... considered a aim of the encryption mode, so most modes (e.g. ECB, CFB, ... As we need to authenticate the device across mounts and not while it is ... It slows down mount operations but they are ...
    (Bugtraq)
  • [UNIX] Vulnerability in Encrypted Loop Device for Linux
    ... Encrypting a disk device aims to protect against an off-line attacker who ... The encryption mode used by encrypted loop device is CBC. ... We propose 2 types of fixes: one that authenticate at mount time (see ...
    (Securiteam)