I am not advocating for the use of PBKDF2. It is not a particularly good KDF,
though it avoids the defects of S2K.
There is one exception: At present, the WebCrypto API does not provide any good
password hash, so PBKDF2 may be the only option for some apps.
Again: scrypt is widely used, BSD-licensed code in every language under the sun
is available. and it is much better than S2K. Is there some reason *not to* use
it?
—
Sent using alpine: an Alternatively Licensed Program for Internet News and Email
On Mon, Apr 27, 2015 at 2:12 PM, Andrey Jivsov <openpgp(_at_)brainhub(_dot_)org>
wrote:
On 04/27/2015 08:09 AM, David Gil wrote:
A hash function which is secure on short inputs may not be secure on
long inputs. This is, indeed, the case (generically) for the MD and
SHA-[12] functions: See papers by Schneier et al. inter alia.
I didn't look at the paper (which one?), but you are saying that if I
have SHA-2 signed e-mail, I can concatenate the same message and achieve
some "insecurity". As attacker can exploit this insecurity by e.g.
prep-ending signed PGP/MIME messages. Most higher-level uses of OpenPGP
will probably simply drop duplicated PGP/MIME parts or TAR files, etc.
Not only the collision resistance is a more difficult problem (and thus
is easier to exploit), the attacker knows the message and the output,
which is not the case for S2K.
My argument was that other parts of OpenPGP protocol will fail before
S2K and we can count on the quick upgrade of the hash function.
Of course, one can similarly come up with hypothetical insecurities in
PBKDF2, e.g. how it cripples the sponge construction due to iterative
nature of PBKDF2 and shrinking the sponge state to the hash output in
each iteration...
At Apr 24, 2015, 11:06:40 PM, Andrey Jivsov wrote:
On 04/24/2015 04:45 AM, Werner Koch wrote:
> On Fri, 24 Apr 2015 09:19, openpgp(_at_)brainhub(_dot_)org
<javascript:return> said:
>
>> 2. The Iterated S2K is essentially a
>>
>> M = M1 || M2 || M2 || M2 || ... || M2, where M1 includes the salt.
>> S2K = Hash( M )
> Actually M2 also includes the salt:
>
> | Then the salt, followed by the passphrase data, is repeatedly
hashed
> | until the number of octets specified by the octet count has been
> | hashed. [...]
>
>
>
I stand corrected.
My argument holds with even greater simplifications with the
following
adjustment:
M = M1 || M1 || M1 || M1 || ... || M1, where M1 includes the salt.
S2K = Hash( M )
If we use the Hash() which is insecure in this setting, we should
expect troubles in other application of this hash function: e.g.
in digital signatures or MAC.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org <javascript:return>
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp