[32751] in Perl-Users-Digest
Perl-Users Digest, Issue: 4015 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 15 16:09:35 2013
Date: Thu, 15 Aug 2013 13:09:04 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 15 Aug 2013 Volume: 11 Number: 4015
Today's topics:
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <news.10.msteinborn@spamgourmet.com>
Re: openssl compatible key and IV calculation <news.10.msteinborn@spamgourmet.com>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <derykus@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 15 Aug 2013 14:16:39 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <8738qbccw8.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> > In the Kerberos world, which I'm more familiar with, this function
>> > is called 'string2key' and is considered cryptographically
>> > significant. Modern Kerberos enctypes, in particular the AES
>> > enctypes, use a function from PKCS#5, which uses SHA-1 rather than
>> > MD5 and performs many iterations to increase the cost of a
>> > dictionary attack.
>>
>> Ehh ... there is no way to do 'a dictionary attack' against Kerberos
>> because the keys derived from user passphrases are supposed to be kept
>> secret. There also wouldn't be any point in performing such a
>> dictionary attack because the key derived from such a passphrase is
>> what is actually used for authentication: Someone who knows that
>> doesn't need to know the passphrase.
>
> Pretty-much any system which relies solely on human-memorable keys is
> vulnerable to dictionary attacks. The fact Kerberos is vulnerable is
> well-known: the attack goes something like this.
>
> Before a user can use a Kerberised network service, s/he has to log in
> to Kerberos. This means the user sends an AS-REQ to the KDC,
> containing their principal name and the TGT they are requesting, and the
> KDC sends back an AS-REP containing (among other things) the user's TGT
> for this session, encrypted with the user's own key. Wait for a user to
> log on, and arrange to intercept the AS-REP (Kerberos explicitly assumes
> this is possible; it's designed for use on insecure networks).
>
> Now you have a data structure, several parts of which are known or can
> be guessed (for instance, the TGT contains the TGT principal in
> plaintext), encrypted with the user's key. Guess a password, derive a
> key from it, and try the decryption. If you get a valid TGT, you've just
> worked out the user's key.
That's not a dictionary attack on the _key_, aka 'someone recovering a
"a secret input" from some scrambled transformation of that' by
running the 'scramble' operation on 'words from some dictionary' and
compare the output created in this step with the other. That's just
ordinary brute-force decryption of something which has been encrypted
with 'knowledge about the plaintext' being used to determine when the
attack was successful.
> Repeat until successful. The only limit on how long it takes is the
> length of time required to derive the key, which is why slow hashes
> with many iterations are important.
Let's assume someone use a single letter password picked from the set
of lowercase and uppercase letters. That would make 52 different
possible passwords and the time required to determine that by brute
force won't sigificantly depend on the speed of the key derivation
algortim for any key derivation algorithm which is still 'fast enough'
that a user cannot possibly throw the computer out of the window and
buy a competing product in the time he has to wait while logging in.
No matter how 'slow' the derivation function is, the main 'time
consuming operation' needs to be 'going through the set of all
possible inputs'.
------------------------------
Date: Thu, 15 Aug 2013 14:26:24 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87y583axvj.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> > ...that said, I've just looked at the source of 'openssl enc', and there
>> > *is* an apparently-undocumented -md option to choose the hash function
>> > to use for string2key, so it might be possible for the OP to switch to
>> > SHA-1. However, there still isn't an option to add iterations, which is
>> > almost more important.
>>
>> In the sense that neither one nor the other matters, yes. The hash is
>> here solely used a 'compression function' capable of turning an
>> arbitrarily long string into a fixed-size encryption key, not because
>> of any cryptographic properties it might have.
>
> Wrong. A hash which produces partially-predicatable output given
> partially-predicatable input will map the thoroughly-non-uniform space
> of passphrases onto a non-uniform subset of the space of possible keys,
> effectively reducing the size of the key.
In other words, "f(x) = 1 is not a suitable compression function for
deriving an encryption key from some 'password' string". I agree with
that.
------------------------------
Date: Thu, 15 Aug 2013 14:40:44 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87txirax7n.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
>> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>>> Ben Morrow <ben@morrow.me.uk> writes:
>>> > In the Kerberos world, which I'm more familiar with, this function
>>> > is called 'string2key' and is considered cryptographically
>>> > significant. Modern Kerberos enctypes, in particular the AES
>>> > enctypes, use a function from PKCS#5, which uses SHA-1 rather than
>>> > MD5 and performs many iterations to increase the cost of a
>>> > dictionary attack.
>>>
>>> Ehh ... there is no way to do 'a dictionary attack' against Kerberos
>>> because the keys derived from user passphrases are supposed to be kept
>>> secret.
[...]
>> Before a user can use a Kerberised network service, s/he has to log in
>> to Kerberos. This means the user sends an AS-REQ to the KDC,
>> containing their principal name and the TGT they are requesting, and the
>> KDC sends back an AS-REP containing (among other things) the user's TGT
>> for this session, encrypted with the user's own key. Wait for a user to
>> log on, and arrange to intercept the AS-REP (Kerberos explicitly assumes
>> this is possible; it's designed for use on insecure networks).
>>
>> Now you have a data structure, several parts of which are known or can
>> be guessed (for instance, the TGT contains the TGT principal in
>> plaintext), encrypted with the user's key. Guess a password, derive a
>> key from it, and try the decryption. If you get a valid TGT, you've just
>> worked out the user's key.
>
> That's not a dictionary attack on the _key_,
After some superficial amount of research, it seems that Ben's more
general use of the term is consistent with 'established practice' (eg,
RFC494) while my more limited interpretation is not.
------------------------------
Date: Thu, 15 Aug 2013 14:37:37 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <162vda-1bk.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >>
> >> > ...that said, I've just looked at the source of 'openssl enc', and there
> >> > *is* an apparently-undocumented -md option to choose the hash function
> >> > to use for string2key, so it might be possible for the OP to switch to
> >> > SHA-1. However, there still isn't an option to add iterations, which is
> >> > almost more important.
> >>
> >> In the sense that neither one nor the other matters, yes. The hash is
> >> here solely used a 'compression function' capable of turning an
> >> arbitrarily long string into a fixed-size encryption key, not because
> >> of any cryptographic properties it might have.
> >
> > Wrong. A hash which produces partially-predicatable output given
> > partially-predicatable input will map the thoroughly-non-uniform space
> > of passphrases onto a non-uniform subset of the space of possible keys,
> > effectively reducing the size of the key.
>
> In other words, "f(x) = 1 is not a suitable compression function for
> deriving an encryption key from some 'password' string". I agree with
> that.
No, in other words, the compression function must be a cryptographically
strong hash, in the sense that it's impossible to predict any properties
of the output given knowledge of any properties of the input. I believe
MD5 is no longer considered to be cryptographically strong.
Ben
------------------------------
Date: Thu, 15 Aug 2013 14:52:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <t13vda-1bk.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >>
> >> > In the Kerberos world, which I'm more familiar with, this function
> >> > is called 'string2key' and is considered cryptographically
> >> > significant. Modern Kerberos enctypes, in particular the AES
> >> > enctypes, use a function from PKCS#5, which uses SHA-1 rather than
> >> > MD5 and performs many iterations to increase the cost of a
> >> > dictionary attack.
> >>
> >> Ehh ... there is no way to do 'a dictionary attack' against Kerberos
> >> because the keys derived from user passphrases are supposed to be kept
> >> secret. There also wouldn't be any point in performing such a
> >> dictionary attack because the key derived from such a passphrase is
> >> what is actually used for authentication: Someone who knows that
> >> doesn't need to know the passphrase.
> >
> > Pretty-much any system which relies solely on human-memorable keys is
> > vulnerable to dictionary attacks. The fact Kerberos is vulnerable is
> > well-known: the attack goes something like this.
[...]
>
> That's not a dictionary attack on the _key_, aka 'someone recovering a
> "a secret input" from some scrambled transformation of that' by
> running the 'scramble' operation on 'words from some dictionary' and
> compare the output created in this step with the other. That's just
> ordinary brute-force decryption of something which has been encrypted
> with 'knowledge about the plaintext' being used to determine when the
> attack was successful.
I don't know where you're getting your definitions from, but any attack
which consists of starting with a likely list of keys and trying them
one at a time is usually called a 'dictionary attack'. They are a
specific vulnerability of human-memorable passwords.
> > Repeat until successful. The only limit on how long it takes is the
> > length of time required to derive the key, which is why slow hashes
> > with many iterations are important.
>
> Let's assume someone use a single letter password picked from the set
> of lowercase and uppercase letters. That would make 52 different
> possible passwords and the time required to determine that by brute
> force won't sigificantly depend on the speed of the key derivation
> algortim for any key derivation algorithm which is still 'fast enough'
> that a user cannot possibly throw the computer out of the window and
> buy a competing product in the time he has to wait while logging in.
The difference between a computation which, done once, takes a
nanosecond and one which takes a whole second is a billionfold, yet a
user is extremely unlikely to notice an additional delay of a second.
> No matter how 'slow' the derivation function is, the main 'time
> consuming operation' needs to be 'going through the set of all
> possible inputs'.
That simply isn't possible with human-memorable keys, especially if
users are allowed to choose their own passwords. (And not allowing them
to do so brings a whole other set of security problems, starting with
PostIt notes on monitors.)
Please, go and do some basic reading before you keep making a fool of
yourself by posting such complete nonsense.
Ben
------------------------------
Date: Thu, 15 Aug 2013 15:12:13 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87pptfavr6.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> >> Ben Morrow <ben@morrow.me.uk> writes:
>> >>
>> >> > ...that said, I've just looked at the source of 'openssl enc', and there
>> >> > *is* an apparently-undocumented -md option to choose the hash function
>> >> > to use for string2key, so it might be possible for the OP to switch to
>> >> > SHA-1. However, there still isn't an option to add iterations, which is
>> >> > almost more important.
>> >>
>> >> In the sense that neither one nor the other matters, yes. The hash is
>> >> here solely used a 'compression function' capable of turning an
>> >> arbitrarily long string into a fixed-size encryption key, not because
>> >> of any cryptographic properties it might have.
>> >
>> > Wrong. A hash which produces partially-predicatable output given
>> > partially-predicatable input will map the thoroughly-non-uniform space
>> > of passphrases onto a non-uniform subset of the space of possible keys,
>> > effectively reducing the size of the key.
>>
>> In other words, "f(x) = 1 is not a suitable compression function for
>> deriving an encryption key from some 'password' string". I agree with
>> that.
>
> No, in other words, the compression function must be a cryptographically
> strong hash, in the sense that it's impossible to predict any properties
> of the output given knowledge of any properties of the input.
As written, this requirement makes no sense: Except if a function
performs a random mapping, predicting the output based on the input is
always possible.
> I believe MD5 is no longer considered to be cryptographically
> strong.
There's a known algorithm for creating different inputs yielding the
same MD5 hash. This means MD5 is known to be a bad choice for digital
signatures supposed to apply to 'document formats' which allow a
prospective attacker to embed arbitrary 'binary noise' in ways which
will usually not be noticed by a human 'consumer' of the document.
------------------------------
Date: Thu, 15 Aug 2013 15:30:51 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87li43auw4.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
[...]
>> Let's assume someone use a single letter password picked from the set
>> of lowercase and uppercase letters. That would make 52 different
>> possible passwords and the time required to determine that by brute
>> force won't sigificantly depend on the speed of the key derivation
>> algortim for any key derivation algorithm which is still 'fast enough'
>> that a user cannot possibly throw the computer out of the window and
>> buy a competing product in the time he has to wait while logging in.
>
> The difference between a computation which, done once, takes a
> nanosecond and one which takes a whole second is a billionfold, yet a
> user is extremely unlikely to notice an additional delay of a
> second.
And the difference between a brute-force attack which needs 52
seconds to recover a password and one which needs 52 nanoseconds is
practically irrelevant except if a 'large' number of passwords are
supposed to be uncovered. And the algorithm may well need only 1s to
recover the password when 52 $somethings can calculate different
possibly correct results in parallell. Of course, two months from now,
hardware or even software(!) capable of performing the '1s'
calculation in a nanosecond will become available ...
>> No matter how 'slow' the derivation function is, the main 'time
>> consuming operation' needs to be 'going through the set of all
>> possible inputs'.
>
> That simply isn't possible with human-memorable keys, especially if
> users are allowed to choose their own passwords. (And not allowing them
> to do so brings a whole other set of security problems, starting with
> PostIt notes on monitors.)
"It is not possible. It is possible but humans won't do that. If they
do it, they will trigger "the PostIt" and then, we're all doomed, mark
my words!" ?
------------------------------
Date: Thu, 15 Aug 2013 16:44:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <mj9vda-qjl.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >> >
> >> > Wrong. A hash which produces partially-predicatable output given
> >> > partially-predicatable input will map the thoroughly-non-uniform space
> >> > of passphrases onto a non-uniform subset of the space of possible keys,
> >> > effectively reducing the size of the key.
> >>
> >> In other words, "f(x) = 1 is not a suitable compression function for
> >> deriving an encryption key from some 'password' string". I agree with
> >> that.
> >
> > No, in other words, the compression function must be a cryptographically
> > strong hash, in the sense that it's impossible to predict any properties
> > of the output given knowledge of any properties of the input.
>
> As written, this requirement makes no sense: Except if a function
> performs a random mapping, predicting the output based on the input is
> always possible.
I didn't say 'given the input', I said 'given some properties of the
input'. Suppose you know (or guess) the input is an English phrase. Does
this make some parts of the output space more likely than others? If it
does you've just weakened your key, by making it less random.
> > I believe MD5 is no longer considered to be cryptographically
> > strong.
>
> There's a known algorithm for creating different inputs yielding the
> same MD5 hash. This means MD5 is known to be a bad choice for digital
> signatures supposed to apply to 'document formats' which allow a
> prospective attacker to embed arbitrary 'binary noise' in ways which
> will usually not be noticed by a human 'consumer' of the document.
That and rainbow tables are the only completely-implemented breaks I
know of, yes, but I believe it's considered likely there are ways of
partially predicting the output given limited knowledge of the input
(such as, 'it's probably an English phrase'). I'm not a cryptographer,
and I don't pretend to understand this stuff in detail, but if those who
do are saying 'don't use MD5 for this purpose' ISTM it's a good idea to
listen to them.
Ben
------------------------------
Date: Thu, 15 Aug 2013 18:13:41 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kuiunm$8c8$1@dont-email.me>
Rainer Weikusat schrieb:
> If you have access to 'a secure channel' which can be used to
> communicate two non-random strings which can be turnt into an
> encyrption key and initialization vector, why don't you just use a
> random key and a random IV and the same 'secure channel' to enable
> sender and recipient to share them?
The secure channel is the users memory - quite good for passphrases, but
very very bad for random numbers. And the salt is stored with the
encrypted message.
And for security reasons, I'm developing a perl script for reencryption
(that is decrypting and then encrypting with a new passphrase. That way
I might change the key generation algoririthm witghout pain, but for now
the ciphertexts are encrypted in the same way "openssl enc" would do.
Greetings
Markus
------------------------------
Date: Thu, 15 Aug 2013 18:32:01 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kuivq3$eg9$1@dont-email.me>
Charles DeRykus schrieb:
> openssl will handle SHA so perhaps a very small patch to Crypt::CBC and
> the script itself to replace Digest::MD5::md5 with Digest::SHA::sha1
> might be another option...
Well, I am not using openssl for encryption/decryption. But I found out
by testing that key generation is compatible to openssl with default
values, so asking the question this way seemed the best way to me.
Currently we are using JavaScript for encryption/decryption - and I am
building a perl script that allows changing passphrases by decrypting
and then encrypting the data.
In the middle term whis would allow canging the key generation
algorithm, too. But for now, it is even more important allowing changing
of passphrases.
I'll consider changing the algorithm to use PBKDF2 (with SHA-3 as HMAC?).
Markus
------------------------------
Date: Thu, 15 Aug 2013 19:57:30 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <qtkvda-r2n.ln1@anubis.morrow.me.uk>
Quoth Markus Steinborn <news.10.msteinborn@spamgourmet.com>:
> Charles DeRykus schrieb:
>
> > openssl will handle SHA so perhaps a very small patch to Crypt::CBC and
> > the script itself to replace Digest::MD5::md5 with Digest::SHA::sha1
> > might be another option...
>
> Well, I am not using openssl for encryption/decryption. But I found out
> by testing that key generation is compatible to openssl with default
> values, so asking the question this way seemed the best way to me.
>
> Currently we are using JavaScript for encryption/decryption - and I am
> building a perl script that allows changing passphrases by decrypting
> and then encrypting the data.
>
> In the middle term whis would allow canging the key generation
> algorithm, too. But for now, it is even more important allowing changing
> of passphrases.
>
> I'll consider changing the algorithm to use PBKDF2 (with SHA-3 as HMAC?).
I think HMAC-SHA1 is currently considered strong enough. (This is not
the same algorithm as plain SHA-1: the HMAC step makes it stronger.)
Ben
------------------------------
Date: Thu, 15 Aug 2013 20:29:07 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87r4duu518.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>> >> Ben Morrow <ben@morrow.me.uk> writes:
>> >> >
>> >> > Wrong. A hash which produces partially-predicatable output given
>> >> > partially-predicatable input will map the thoroughly-non-uniform space
>> >> > of passphrases onto a non-uniform subset of the space of possible keys,
>> >> > effectively reducing the size of the key.
>> >>
>> >> In other words, "f(x) = 1 is not a suitable compression function for
>> >> deriving an encryption key from some 'password' string". I agree with
>> >> that.
>> >
>> > No, in other words, the compression function must be a cryptographically
>> > strong hash, in the sense that it's impossible to predict any properties
>> > of the output given knowledge of any properties of the input.
>>
>> As written, this requirement makes no sense: Except if a function
>> performs a random mapping, predicting the output based on the input is
>> always possible.
>
> I didn't say 'given the input', I said 'given some properties of the
> input'.
Actually 'any properties of the input' and 'any properties of the
output'. And the input itself is surely a property of the input.
> Suppose you know (or guess) the input is an English phrase. Does
> this make some parts of the output space more likely than others? If it
> does you've just weakened your key, by making it less random.
If this was so, someone had inadvertently invented an algorithm
capable of understanding English. This algorithm might be a bad 'key
generation algorithm' but it probably a great, commercial opportunity.
Joking aside, a lossy compression function (like MD5 or any other hash
function) always causes 'loss of information' which implies 'loss of
entropy' if there was more in the input than can remain in the 16
output bytes.
[...]
> That and rainbow tables are the only completely-implemented breaks I
> know of, yes, but I believe it's considered likely there are ways of
> partially predicting the output given limited knowledge of the input
> (such as, 'it's probably an English phrase'). I'm not a cryptographer,
> and I don't pretend to understand this stuff in detail, but if those who
> do are saying 'don't use MD5 for this purpose' ISTM it's a good idea to
> listen to them.
Some musings on this:
http://tools.ietf.org/html/rfc6151
------------------------------
Date: Thu, 15 Aug 2013 12:50:23 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kujbf5$ea9$1@speranza.aioe.org>
On 8/15/2013 4:12 AM, Ben Morrow wrote:
>
> Quoth Charles DeRykus <derykus@gmail.com>:
>> On 8/14/2013 5:29 PM, Ben Morrow wrote:
>>>
>>> Well, all I did was pull the code out of Crypt::CBC.
>>>
>>> I don't know where this function is specified, but I have to say I'm a
>>> little worried about the unconditional use of MD5. In the Kerberos
>>> world, which I'm more familiar with, this function is called
>>> 'string2key' and is considered cryptographically significant. Modern
>>> Kerberos enctypes, in particular the AES enctypes, use a function from
>>> PKCS#5, which uses SHA-1 rather than MD5 and performs many iterations to
>>> increase the cost of a dictionary attack.
>>>
>>> If you're using this one-iteration-of-MD5 function for encrypting
>>> anything important, it's probably worth being rather careful to use very
>>> strong passphrases.
>>
>> openssl will handle SHA so perhaps a very small patch to Crypt::CBC and
>> the script itself to replace Digest::MD5::md5 with Digest::SHA::sha1
>> might be another option...
>
> I think you're not entirely understanding where this is used. It's not
> used as an ordinary digest function, it's part of the function which
> turns a human-readable passphrase into a binary encryption key. It's
> obviously necessary that both ends do this the same way, otherwise
> typing in the same passphrase won't produce the same key, and the
> ciphertext will be undecipherable.
>
> Given that 'openssl enc' has no option to choose the string2key method,
> I presume that whatever standard this is implementing (if this isn't
> simply an OpenSSL-specific feature) doesn't allow anything except MD5 to
> be used. Given that the OP presumably wants the results to be compatible
> with OpenSSL, using a string2key function which is more secure but
> different from OpenSSL's would be useless.
>
> ...that said, I've just looked at the source of 'openssl enc', and there
> *is* an apparently-undocumented -md option to choose the hash function
> to use for string2key, so it might be possible for the OP to switch to
> SHA-1. However, there still isn't an option to add iterations, which is
> almost more important. (The documentation for the underlying
> EVP_BytesToKey even says that function is deprecated, and apps should
> use the PKCS#5 function instead.)
>
Thanks, I knew minimally that both would need to sync... but little more.
With 1.0.1e, I did spot the -md option in 'man enc' but only the full
option details inside openssl enc:
-md the next argument is the md to use to create a key
from a passphrase. One of md2, md5, sha or sha1
$ openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64
-md sha1 -P -S ab001d77079ba218
salt=AB001D77079BA218
key=890B75B7502649E8EF8EAF71B0A978F48229DCC4DE4F43F6825422694B311364
iv =FF77D7B00DD3D950DC7F788E52EC8644
Tweaking sub "aes_key_and_iv" to use Digest::SHA::sha1 does generate an
identical key but, interestingly?, only a partial iv match:
perl tmp.pl "Secret Passphrase" ab001d77079ba218
key [890b75b7502649e8ef8eaf71b0a978f48229dcc4de4f43f6825422694b311364]
iv [ff77d7b00dd3d950ec46c8be1f2ebf5e]
--
Charles DeRykus
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4015
***************************************
