[32750] in Perl-Users-Digest
Perl-Users Digest, Issue: 4014 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 15 09:09:35 2013
Date: Thu, 15 Aug 2013 06:09:07 -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: 4014
Today's topics:
can some please help me , can we use perl for testing j <suri.71@gmail.com>
Re: can some please help me , can we use perl for testi (Jens Thoms Toerring)
openssl compatible key and IV calculation <news.10.msteinborn@spamgourmet.com>
Re: openssl compatible key and IV calculation <glex_no-spam@qwest-spam-no.invalid>
Re: openssl compatible key and IV calculation <news.10.msteinborn@spamgourmet.com>
Re: openssl compatible key and IV calculation <jurgenex@hotmail.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 <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 <news.10.msteinborn@spamgourmet.com>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <derykus@gmail.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 <rweikusat@mobileactivedefense.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 <ben@morrow.me.uk>
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 <ben@morrow.me.uk>
Re: s modifier doesn't seem to work fmassion@web.de
Re: s modifier doesn't seem to work <rweikusat@mobileactivedefense.com>
Re: s modifier doesn't seem to work <derykus@gmail.com>
Re: s modifier doesn't seem to work <derykus@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 13 Aug 2013 22:02:19 -0700 (PDT)
From: Suresh Macharla <suri.71@gmail.com>
Subject: can some please help me , can we use perl for testing java applications.
Message-Id: <32584198-811b-4ffd-803a-755248b014e7@googlegroups.com>
Can some one please let me know can we test java applications using perl. If yes, can you please help me with some links or tools that will help in this case.
eagerly waiting for your replay.
thanks in adv,
Suresh
------------------------------
Date: 14 Aug 2013 13:24:59 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: can some please help me , can we use perl for testing java applications.
Message-Id: <b71ep9Fgg6hU1@mid.uni-berlin.de>
Suresh Macharla <suri.71@gmail.com> wrote:
> Can some one please let me know can we test java applications using perl. If
> yes, can you please help me with some links or tools that will help in this
> case. eagerly waiting for your replay.
What kind of tests are you talking about?
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Tue, 13 Aug 2013 18:21:29 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: openssl compatible key and IV calculation
Message-Id: <kudmeb$sv8$1@dont-email.me>
Hello,
I'd like to compute the initialisation vector and the key for decrypting
ciphertexts. The operation I'd like to do can be done with openssl by
the following command:
openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64 -P -S
ab001d77079ba218
Obviously "Secret passphrase" is the passphrase and "ab001d77079ba218"
is the salt - we'll assume that both are known.
The goal is to compute the initialisation vector (IV) and the key.
How to do that in perl?
The openssl man-pages and google did not help me.
Thanks
Markus Steinborn
------------------------------
Date: Tue, 13 Aug 2013 12:23:17 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <520a6b85$0$63202$815e3792@news.qwest.net>
On 08/13/13 11:21, Markus Steinborn wrote:
> Hello,
>
> I'd like to compute the initialisation vector and the key for decrypting
> ciphertexts. The operation I'd like to do can be done with openssl by
> the following command:
>
> openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64 -P -S
> ab001d77079ba218
>
> Obviously "Secret passphrase" is the passphrase and "ab001d77079ba218"
> is the salt - we'll assume that both are known.
>
> The goal is to compute the initialisation vector (IV) and the key.
>
>
> How to do that in perl?
>
> The openssl man-pages and google did not help me.
openssl is a command/executable and the above produces output, so it's
not anything special or different from many other commands. If you
want to execute the command, capture the output, and do something
with it...
use strict;
use warnings;
my $str = `/usr/bin/openssl enc -a -aes-256-cbc -pass pass:"Secret
Passphrase"-base64 -P -S ab001d77079ba218`;
my %fields = $str =~ / (\S+) \s* = \s* (\S+) /xg;
use Data::Dumper;
print Dumper( \%fields );
$VAR1 = {
'salt' => 'AB001D77079BA218',
'iv' => 'B99974A9FF1F39AF888BC378015C37D1',
'key' =>
'A4430C9C6AD9B88836B7277193CC21C56E5503F6F0DBF3E777A31BE7D42765F8'
};
------------------------------
Date: Tue, 13 Aug 2013 19:56:44 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kuds0u$ti8$1@dont-email.me>
Hi Gleixner,
thanks for your answer.
J. Gleixner schrieb:
>
> my $str = `/usr/bin/openssl enc -a -aes-256-cbc -pass pass:"Secret
> Passphrase"-base64 -P -S ab001d77079ba218`;
Not bad... I'm developinig under Linux, but the hard encoded path might
be a portability problem, especcially on windows (ActiveState Perl 5.16
with Crypt::CBC and Crypt::OpenSSL::AES).
Perhaps there is a trick to use either the OpenSSL system library (on
linux/Unix) or the openSSL library ActiveState Perl uses (on windows).
But anyway: An enviromnent variable poiting to the openssl binary might
help out of this situation - if we do not find anything better.
I just thought that there might be a perl solution like
Crypt::OpenSSL::AES for the encryption/decryption.
Greetings from Germany
Markus
------------------------------
Date: Tue, 13 Aug 2013 12:29:54 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <b72l091o93tukgi0takv8t1nsh3n9od75m@4ax.com>
Markus Steinborn <news.10.msteinborn@spamgourmet.com> wrote:
>I'd like to compute the initialisation vector and the key for decrypting
>ciphertexts. The operation I'd like to do can be done with openssl by
>the following command:
>
>openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64 -P -S
>ab001d77079ba218
>
>Obviously "Secret passphrase" is the passphrase and "ab001d77079ba218"
>is the salt - we'll assume that both are known.
>
>The goal is to compute the initialisation vector (IV) and the key.
>How to do that in perl?
It looks like you got a working solution already. Is there a specific
reason why you can't just call 'openssl' from you Perl script?
jue
------------------------------
Date: Wed, 14 Aug 2013 07:52:37 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kuf5v6$6fh$1@dont-email.me>
Jürgen Exner wrote:
> It looks like you got a working solution already. Is there a specific
> reason why you can't just call 'openssl' from you Perl script?
Well, I've a weak one: I'd prefer to get rid on openssl dependencies...
There exist Crypt::Rijndael (which might need some fixing). But it's
always nice to have a working fallback - it might happen that I cannot
get rid of OpenSSL.
The problem with openssl is: It is not installed on an average windows
machine.
Markus
------------------------------
Date: Wed, 14 Aug 2013 09:34:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <d2srda-0c2.ln1@anubis.morrow.me.uk>
Quoth Markus Steinborn <news.10.msteinborn@spamgourmet.com>:
> J. Gleixner schrieb:
> >
> > my $str = `/usr/bin/openssl enc -a -aes-256-cbc -pass pass:"Secret
> > Passphrase"-base64 -P -S ab001d77079ba218`;
>
> Not bad... I'm developinig under Linux, but the hard encoded path might
> be a portability problem, especcially on windows (ActiveState Perl 5.16
> with Crypt::CBC and Crypt::OpenSSL::AES).
Well, have you tried using those two together? I can't see any reason it
shouldn't work. You could also try Crypt::Cipher::AES, which has its own
AES implementation and doesn't depend on OpenSSL.
Ben
------------------------------
Date: Wed, 14 Aug 2013 11:32:24 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kufira$vk4$1@dont-email.me>
Hi Ben,
Ben Morrow schrieb:
> Well, have you tried using those two together? I can't see any reason it
> shouldn't work. You could also try Crypt::Cipher::AES, which has its own
> AES implementation and doesn't depend on OpenSSL.
thanks, that's exactly I'm looking for - noticing that it does not solf
key and IV calculation without openssl, but decrypting without openssl.
Markus
------------------------------
Date: Wed, 14 Aug 2013 11:34:02 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kufiub$vk4$2@dont-email.me>
Ben Morrow schrieb:
>
> Quoth Markus Steinborn <news.10.msteinborn@spamgourmet.com>:
>> with Crypt::CBC and Crypt::OpenSSL::AES).
>
> Well, have you tried using those two together? I can't see any reason it
> shouldn't work.
They work fiine tohether under Linux (Windows not tested yet) - but
offer no methood for an openssl compatible key and IV calculation.
Markus
------------------------------
Date: Wed, 14 Aug 2013 16:38:31 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <nsksda-fo72.ln1@anubis.morrow.me.uk>
Quoth Markus Steinborn <news.10.msteinborn@spamgourmet.com>:
> Ben Morrow schrieb:
> > Quoth Markus Steinborn <news.10.msteinborn@spamgourmet.com>:
> >> with Crypt::CBC and Crypt::OpenSSL::AES).
> >
> > Well, have you tried using those two together? I can't see any reason it
> > shouldn't work.
>
> They work fiine tohether under Linux (Windows not tested yet) - but
> offer no methood for an openssl compatible key and IV calculation.
Oh, sorry, I missed the significance of the -P option.
Looking through the source of Crypt::CBC, the key/IV calculation doesn't
depend on either the cipher or the plaintext, and this gives me the same
results as openssl(1):
#!/usr/bin/perl
use 5.012;
use Digest::MD5 qw/md5/;
sub aes_key_and_iv {
my ($pass,$salt) = @_;
my $key_len = 32;
my $iv_len = 16;
my $desired_len = $key_len+$iv_len;
my $data = '';
my $d = '';
while (length $data < $desired_len) {
$d = md5($d . $pass . $salt);
$data .= $d;
}
return (substr($data,0,$key_len),substr($data,$key_len,$iv_len));
}
my ($pass, $salt) = @ARGV;
$salt = pack "H*", $salt;
my ($key, $iv) = map unpack("H*", $_), aes_key_and_iv $pass, $salt;
say for "key [$key]", "iv [$iv]";
Ben
------------------------------
Date: Wed, 14 Aug 2013 20:34:41 +0200
From: Markus Steinborn <news.10.msteinborn@spamgourmet.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kugik3$av0$1@dont-email.me>
Hi Ben,
Ben Morrow schrieb:
> Oh, sorry, I missed the significance of the -P option.
>
> Looking through the source of Crypt::CBC, the key/IV calculation doesn't
> depend on either the cipher or the plaintext, and this gives me the same
> results as openssl(1):
Wow, you've got it - that is what I've been looking for... and a handy
source code which clearly documents how these values are calculated --
perfect.
I'm testing it in the next few days.
Thanks
Markus
------------------------------
Date: Thu, 15 Aug 2013 01:29:10 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <mvjtda-2uc2.ln1@anubis.morrow.me.uk>
Quoth Markus Steinborn <news.10.msteinborn@spamgourmet.com>:
> Ben Morrow schrieb:
>
> > Oh, sorry, I missed the significance of the -P option.
> >
> > Looking through the source of Crypt::CBC, the key/IV calculation doesn't
> > depend on either the cipher or the plaintext, and this gives me the same
> > results as openssl(1):
>
> Wow, you've got it - that is what I've been looking for... and a handy
> source code which clearly documents how these values are calculated --
> perfect.
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.
Ben
------------------------------
Date: Wed, 14 Aug 2013 22:44:52 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kuhpts$iva$1@speranza.aioe.org>
On 8/14/2013 5:29 PM, Ben Morrow wrote:
>
> Quoth Markus Steinborn <news.10.msteinborn@spamgourmet.com>:
>> Ben Morrow schrieb:
>>
>>> Oh, sorry, I missed the significance of the -P option.
>>>
>>> Looking through the source of Crypt::CBC, the key/IV calculation doesn't
>>> depend on either the cipher or the plaintext, and this gives me the same
>>> results as openssl(1):
>>
>> Wow, you've got it - that is what I've been looking for... and a handy
>> source code which clearly documents how these values are calculated --
>> perfect.
>
> 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...
--
Charles DeRykus
------------------------------
Date: Thu, 15 Aug 2013 12:00:37 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87a9kjdxre.fsf@sapphire.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.
> If you're using this one-iteration-of-MD5 function for encrypting
> anything important,
JFTR: The algortihm you posted does 3 rounds of MD5, not one.
------------------------------
Date: Thu, 15 Aug 2013 12:02:47 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <8761v7dxns.fsf@sapphire.mobileactivedefense.com>
Markus Steinborn <news.10.msteinborn@spamgourmet.com> writes:
> Ben Morrow schrieb:
>
>> Oh, sorry, I missed the significance of the -P option.
>>
>> Looking through the source of Crypt::CBC, the key/IV calculation doesn't
>> depend on either the cipher or the plaintext, and this gives me the same
>> results as openssl(1):
>
> Wow, you've got it - that is what I've been looking for... and a
> handy source code which clearly documents how these values are
> calculated -- perfect.
Except one minor nit: For algorithms without (known) 'classes of weak
keys' (such as AES), you can as well just use (cryptographically
strong) random numbers (aka 'a sufficient quantity of randomly
generated bytes').
------------------------------
Date: Thu, 15 Aug 2013 12:07:37 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <871u5vdxfq.fsf@sapphire.mobileactivedefense.com>
Markus Steinborn <news.10.msteinborn@spamgourmet.com> writes:
> I'd like to compute the initialisation vector and the key for
> decrypting ciphertexts. The operation I'd like to do can be done with
> openssl by the following command:
>
> openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64 -P
> -S
> ab001d77079ba218
>
> Obviously "Secret passphrase" is the passphrase and "ab001d77079ba218"
> is the salt - we'll assume that both are known.
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?
------------------------------
Date: Thu, 15 Aug 2013 12:12:25 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <plpuda-05j.ln1@anubis.morrow.me.uk>
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.)
Ben
------------------------------
Date: Thu, 15 Aug 2013 12:36:57 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <877gfnchie.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Charles DeRykus <derykus@gmail.com>:
[...]
> ...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. And using a more
'expensive' calculation to derive this key is totally pointless _for
encryption_ because it won't increase the amount of entropy in the
input and once an attacker knows the key, he can decrypt away to his
hearts content without caring about how it was created.
It is not pointless when the derived key is supposed to be used in an
authentication system relying on 'the /etc/passwd fallacy' that no one
will ever be able to figure out the input (password) and thus, be able
to impersonate another user, based on knowing output and algorithm
alone. Or at least 'sort of not pointless': Expensive computations of
today tend to become 'inexpensive computations of tomorrow' quickly
...
------------------------------
Date: Thu, 15 Aug 2013 13:44:24 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <82vuda-mrj.ln1@anubis.morrow.me.uk>
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. 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.
As krb5 was originally specified, it was possible to do this without
intercepting anything: the AS-REQ didn't contain anything encrypted or
secret, so an attacker could generate an AS-REQ for any principal, send
it to the KDC, and get an AS-REP of their very own to play with. (This
is effectively equivalent to making the shadow password file visible
over the network.) All current Kerberos systems use preauth, which means
the AS-REQ contains some known data (usually a timestamp) encrypted with
the user's key. This removes the completely blind attack, but makes the
intercept attack rather easier: since the AS-REQ can now be used as the
target of a dictionary attack, an attacker who can hijack DNS can get
users to send AS-REQs directly to him.
There are at least two defences against this: Heimdal supports
SSL-enabled KDCs, which brings all the fun of maintaining a secure PKI
in addition to a secure Kerberos infrastructure, and MIT has a rather
better system called FAST which protects the AS transactions with a
machine-generated key owned by the user's workstation. I don't believe
MS Kerberos supports anything similar; I don't know about Sun Kerberos.
> > If you're using this one-iteration-of-MD5 function for encrypting
> > anything important,
>
> JFTR: The algortihm you posted does 3 rounds of MD5, not one.
So it does. I couldn't be bothered to work it out. From the point of
view of wasting an attacker's time, 3 is very little better than 1. MD5
is so fast that thousands of iterations are required to do any good.
Ben
------------------------------
Date: Thu, 15 Aug 2013 13:46:53 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <t6vuda-mrj.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Markus Steinborn <news.10.msteinborn@spamgourmet.com> writes:
> > Ben Morrow schrieb:
> >
> >> Oh, sorry, I missed the significance of the -P option.
> >>
> >> Looking through the source of Crypt::CBC, the key/IV calculation doesn't
> >> depend on either the cipher or the plaintext, and this gives me the same
> >> results as openssl(1):
> >
> > Wow, you've got it - that is what I've been looking for... and a
> > handy source code which clearly documents how these values are
> > calculated -- perfect.
>
> Except one minor nit: For algorithms without (known) 'classes of weak
> keys' (such as AES), you can as well just use (cryptographically
> strong) random numbers (aka 'a sufficient quantity of randomly
> generated bytes').
Unless you're trying to decrypt something encrypted with 'openssl enc'
with a known passphrase, or encrypt something using a known passphrase
which 'openssl enc' will be able to decrypt...
Ben
------------------------------
Date: Thu, 15 Aug 2013 14:00:29 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <d00vda-mrj.ln1@anubis.morrow.me.uk>
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.
> And using a more
> 'expensive' calculation to derive this key is totally pointless _for
> encryption_ because it won't increase the amount of entropy in the
> input and once an attacker knows the key, he can decrypt away to his
> hearts content without caring about how it was created.
Also wrong. Given the ciphertext, and no prior knowledge of the key, an
attacker can conduct a dictionary attack by guessing a passphrase,
deriving the key, using that key to decrypt the data, and seeing if the
result 'looks like plaintext'. This last step is nearly always extremely
easy, unless the plaintext was already carefully chosen to be
cryptographically random.
Ben
------------------------------
Date: Thu, 15 Aug 2013 13:49:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <mbvuda-mrj.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> Markus Steinborn <news.10.msteinborn@spamgourmet.com> writes:
> > I'd like to compute the initialisation vector and the key for
> > decrypting ciphertexts. The operation I'd like to do can be done with
> > openssl by the following command:
> >
> > openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64 -P
> > -S
> > ab001d77079ba218
> >
> > Obviously "Secret passphrase" is the passphrase and "ab001d77079ba218"
> > is the salt - we'll assume that both are known.
>
> 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?
Passphrases can be remembered (by a human); random data usually cannot.
The salt is included (in plaintext) in the encrypted data; it's only
there to defend against precalculated dictionaries.
Ben
------------------------------
Date: Tue, 13 Aug 2013 00:05:46 -0700 (PDT)
From: fmassion@web.de
Subject: Re: s modifier doesn't seem to work
Message-Id: <e3a40af2-f5c3-49bb-b264-61b2e92af096@googlegroups.com>
Thanks to all of you for your efforts and ideas. Let me summarize the lesso=
ns I've learned in this discussion.
The task was: Import a text, apply a regex which extends over a linebreak a=
nd display/modify the lines matching the expression.
The original approach failed because the text was not read in one string, b=
ut split into lines in an array.
I then wanted to be able to print each individual line of the array and to =
use ^ and $ in line-based regular expression.=20
I have tried all the suggested code. Not everything has worked. This is my =
current code with which I manage to get the matched lines and the entire te=
xt:
use utf8; # damit lassen sich UTF8 Dateien bearbeiten
binmode STDIN, ":utf8"; # input
binmode STDOUT, ":utf8"; # output
#undef $/; # is not required as <DATA> read into array and then joined
open(DATA,'D:\temp\a.txt') || die("Datei kann nicht ge=F6ffnet werden!\n");
seek(DATA, 3, 0);
my @satz =3D <DATA>;=20
my $alles =3D join('', @satz);=20
my $match;=20
if ( $alles =3D~ /^.*\d.*Zahl.*?\n/gsma ) {=20
$match =3D ${^MATCH}; # I don't understand what is this ${^MATCH}
# $match =3D $1; # doesn't work
print "$match<<\n"; # prints only the match
foreach my $satz (@satz) {=20
# if ( $match =3D~ /$satz/ ) { # if activated prints nothing
print "sentence is part of match: $satz\n"; # prints the enti=
re text
# }=20
}=20
}
------------------------------
Date: Tue, 13 Aug 2013 10:15:41 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: s modifier doesn't seem to work
Message-Id: <871u5ygddu.fsf@sapphire.mobileactivedefense.com>
fmassion@web.de writes:
[...]
> use utf8; # damit lassen sich UTF8 Dateien bearbeiten
This is only needed if your source code contains UTF-*.
> binmode STDIN, ":utf8"; # input
> binmode STDOUT, ":utf8"; # output
>
> #undef $/; # is not required as <DATA> read into array and then joined
Except in 'short files' (as here), it is usually better to use
local $/;
instead. This creates a new binding for $/ while preserving the old
one which will be restored after the containing block.
> open(DATA,'D:\temp\a.txt') || die("Datei kann nicht geöffnet werden!\n");
This "it didn't work" style of error reporting is a bit useless. The
message should also contain the system error code/ message.
> seek(DATA, 3, 0);
> my @satz = <DATA>;
> my $alles = join('', @satz);
> my $match;
> if ( $alles =~ /^.*\d.*Zahl.*?\n/gsma ) {
> $match = ${^MATCH}; # I don't understand what is this ${^MATCH}
As 'perldoc perlvar' could have told you: The text which matched the
regex. At least for the perl version I'm using (5.10.1), the
documentation also says the /p match modifier is needed in order to
use this builtin variable.
> # $match = $1; # doesn't work
Since the regex isn't capturing anyhing, that is to be expected.
--
To anybody who feels inclined to flame me for
'attention seeking by gratuitious e-mail address changes':
Chances are I don't care for you attention but as people
change employers, their e-mail addresses also change.
------------------------------
Date: Tue, 13 Aug 2013 03:30:39 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: s modifier doesn't seem to work
Message-Id: <kud1tk$o98$1@speranza.aioe.org>
On 8/13/2013 12:05 AM, fmassion@web.de wrote:
> Thanks to all of you for your efforts and ideas. Let me summarize the lessons I've learned in this discussion.
> The task was: Import a text, apply a regex which extends over a linebreak and display/modify the lines matching the expression.
> The original approach failed because the text was not read in one string, but split into lines in an array.
> I then wanted to be able to print each individual line of the array and to use ^ and $ in line-based regular expression.
> I have tried all the suggested code. Not everything has worked. This is my current code with which I manage to get the matched lines and the entire text:
>
> use utf8; # damit lassen sich UTF8 Dateien bearbeiten
> binmode STDIN, ":utf8"; # input
> binmode STDOUT, ":utf8"; # output
>
> #undef $/; # is not required as <DATA> read into array and then joined
> open(DATA,'D:\temp\a.txt') || die("Datei kann nicht geöffnet werden!\n");
> seek(DATA, 3, 0);
> my @satz = <DATA>;
> my $alles = join('', @satz);
> my $match;
> if ( $alles =~ /^.*\d.*Zahl.*?\n/gsma ) {
> $match = ${^MATCH}; # I don't understand what is this ${^MATCH}
> # $match = $1; # doesn't work
> print "$match<<\n"; # prints only the match
> foreach my $satz (@satz) {
> # if ( $match =~ /$satz/ ) { # if activated prints nothing
> print "sentence is part of match: $satz\n"; # prints the entire text
> # }
> }
> }
>
The $^{MATCH} is only valid with /p and was not needed. I'm not certain
it's at all relevant to what you're doing now either.
I think Ben's suggestion is the most promising if you want to identify
the sentences over which the match extends:
while (my ($match) =
$alles =~ /([^\n]* \d .* Zahl [^\n]*)/gsx
# or perhaps /(.* \d (?s:.)* Zahl .*)/gx
# or /(\N* \d .* Zahl \N*)/gsx if you've got 5.12
) {
for my $satz (split /\n/, $match) {
# make that /(?<=\n)/ if you don't want to chomp
print "sentence is part of match: $satz\n\n";
}
}
--
Charles DeRykus
------------------------------
Date: Tue, 13 Aug 2013 03:38:34 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: s modifier doesn't seem to work
Message-Id: <kud2cf$pdc$1@speranza.aioe.org>
On 8/13/2013 3:30 AM, Charles DeRykus wrote:
> On 8/13/2013 12:05 AM, fmassion@web.de wrote:
> ...
> I think Ben's suggestion is the most promising if you want to identify
> the sentences over which the match extends:
>
> while (my ($match) =
> $alles =~ /([^\n]* \d .* Zahl [^\n]*)/gsx
> # or perhaps /(.* \d (?s:.)* Zahl .*)/gx
> # or /(\N* \d .* Zahl \N*)/gsx if you've got 5.12
> ) {
> for my $satz (split /\n/, $match) {
> # make that /(?<=\n)/ if you don't want to chomp
> print "sentence is part of match: $satz\n\n";
> }
> }
>
Also, to take care of the endless loop problem:
while (my ($match) =$alles =~ /([^\n]* \d .* Zahl [^\n]*)/gsx ) {
Replace above with:
for my $match ($alles =~ /([^\n]* \d .* Zahl [^\n]*)/gsx/) {
--
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 4014
***************************************
