[26126] in Perl-Users-Digest
Perl-Users Digest, Issue: 8319 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 12 21:05:35 2005
Date: Fri, 12 Aug 2005 18:05: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 Fri, 12 Aug 2005 Volume: 10 Number: 8319
Today's topics:
Re: Padding Problem UPDATE (Still broken) <hal@thresholddigital.com>
Re: Padding Problem UPDATE (Still broken) <jgibson@mail.arc.nasa.gov>
Padding Problem with Blowfish and Crypt::CBC and Java C <hal@thresholddigital.com>
Re: Perl numerics: EPSILON and equality between floats (Anno Siegel)
Re: sort <glex_no-spam@qwest-spam-no.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 12 Aug 2005 16:53:51 -0400
From: Hal Vaughan <hal@thresholddigital.com>
Subject: Re: Padding Problem UPDATE (Still broken)
Message-Id: <r_adnYren7jDkWDfRVn-uw@comcast.com>
Hal Vaughan wrote:
> I have to admit I barely understand any cryptography beyond the simple A=1
> type codes my friends and I used in grammar school. I have a server,
> running Perl, that takes a file, encrypts it with Blowfish, then MIME
> encodes it, sends it out via e-mail. Then I have a Java program that
> retrieves the e-mail, MIME decodes it, then decrypts it. I am having no
> problem on the Perl end, and any encrypted e-mail I create I can retrieve
> and decode. There seems to be no problem with MIME encoding/decoding.
> The problem comes when my Java program tries to decrypt the file created
> and
> sent by Perl. I always get:
>
> javax.crypto.BadPaddingException: Given final block not properly padded
>
> When I first set this up, with the Perl code on another computer, I got
> errors like that. They stopped, but I was never sure exactly what I did
> to solve the problem (and I'm never comfortable with a situation like
> that). I tried to examine my changes, and I could never be sure just what
> fixed
> it. Now the Perl code is running on a new system. I'm using a later
> version of Crypt::CBC (from 2.08 to 2.12), but I can't see anything in the
> changelog that should effect the problem I'm having. I'd also like to
> solve the problem once and for all, which means either understanding what
> is going wrong with the BadPaddingException, or knowing what to do so Java
> has no problem reading the encrypted data Perl sends.
>
> My Perl code to encrypt the data is this:
>
> $cipher = Crypt::CBC->new( { 'key' => $key, iv => $vector,
> prepend_iv => 0, 'cipher' => 'Blowfish', 'regenerate_key' => 0 }
> );
> $data = $cipher->encrypt($rawdata);
>
> My Java code to decrypt the data is this:
>
> //sCryptoKey and sCryptoVector are strings with the key and vector
> //bCrypto is byte[] of encrypted data
> //bDecrypted is byte[] of decrypted data
> try {
> SecretKeySpec oKey = new
> SecretKeySpec(sCryptoKey.getBytes("UTF8"),
> "Blowfish");
> IvParameterSpec oIV = new
> IvParameterSpec(sCryptoVector.getBytes("UTF8"));
> Cipher oCipher = Cipher.getInstance("Blowfish/CBC/PKCS5Padding");
> oCipher.init(Cipher.DECRYPT_MODE, oKey, oIV );
> bDecrypted = oCipher.doFinal(bCrypto);
> } catch (Exception e) {
> //Log the error
> sysConfig.log("error", "error decrypting incoming file -- saving
> to
> log
> directory: " + e);
> }
>
> I'd like to have some better understanding of why I'm getting errors. I'm
> not even fully clear on what padding is. I've tried reading up on how
> Blowfish works, but I really don't follow it. From what I can see, I
> suspect if I change the PKCS5Padding to NoPadding in the Java code should
> work, but I'm assuming Padding is just the padding of data on the end. Is
> there a way to tell Cipher to figure out the padding, or to take the data
> "as is"? I'm also trying to find if there is a way to specify padding on
> the Perl end. According to the docs for CBC on CPAN, the padding() method
> in CBC is read-only, and I don't see a way to specify the padding in CBC.
> I would think as long as I can specify the same padding on both ends there
> should be no problem, but, again, there seems to be no way to specify
> padding for Crypt::CBC.
I found the "padding" setting, and now use this to encrypt:
$cipher = Crypt::CBC->new( { 'key' => $key, iv => $vector,
prepend_iv => 0, 'cipher' => 'Blowfish', 'regenerate_key' => 0,
padding => 'standard' });
$data = $cipher->encrypt($rawdata);
And now I get a different error on the Java end:
javax.crypto.BadPaddingException: Given final block not properly padded
So now it's padding properly (which is should have done anyway, since it is
supposed to default to "standard") but the last block is not being padded
properly. At first I thought I had to change and use the sequence of
"start, crypt, finish" for encoding, but according to the docs, encrypt()
does it all. So is there something I can do to make sure the last block is
padded? Apparently Crypt::CBC isn't doing that.
Thanks!
Hal
------------------------------
Date: Fri, 12 Aug 2005 16:20:16 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Padding Problem UPDATE (Still broken)
Message-Id: <120820051620163182%jgibson@mail.arc.nasa.gov>
In article <r_adnYren7jDkWDfRVn-uw@comcast.com>, Hal Vaughan
<hal@thresholddigital.com> wrote:
> Hal Vaughan wrote:
>
>
[problem description snipped]
> I found the "padding" setting, and now use this to encrypt:
>
> $cipher = Crypt::CBC->new( { 'key' => $key, iv => $vector,
> prepend_iv => 0, 'cipher' => 'Blowfish', 'regenerate_key' => 0,
> padding => 'standard' });
> $data = $cipher->encrypt($rawdata);
>
> And now I get a different error on the Java end:
>
> javax.crypto.BadPaddingException: Given final block not properly padded
>
> So now it's padding properly (which is should have done anyway, since it is
> supposed to default to "standard") but the last block is not being padded
> properly. At first I thought I had to change and use the sequence of
> "start, crypt, finish" for encoding, but according to the docs, encrypt()
> does it all. So is there something I can do to make sure the last block is
> padded? Apparently Crypt::CBC isn't doing that.
Have you tried the other values of the padding setting ('space',
'onesandzeroes', 'null')?
Padding applies only to the last block. Block cipher algorithms like
Blowfish work on blocks of bits. Blowfish uses blocks of size 64 bits.
If the last block is short, padding is added to make it a full block.
The 'standard' padding method is to add 1 to 8 bytes, depending upon
the length of the original data, each byte containing the number of
bytes being added. That way the padding bytes may be unambiguously
removed from the decrypted message. Note that if your message is a
multiple of 64 bits, an extra block of '0808080808080808' will be
added. All of this is explained in the documentation for Crpyt::CBC and
in the references below.
You might try 'null' or 'spaces' on the Perl side and
'Blowfish/CBC/Nopadding' on the Java side. I have not used either
Crypt::CBC nor javax.crypto, so can't give much additional help.
References:
<http://www.faqs.org/rfcs/rfc1423.html>
<http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html
#AppA>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---
------------------------------
Date: Fri, 12 Aug 2005 16:21:45 -0400
From: Hal Vaughan <hal@thresholddigital.com>
Subject: Padding Problem with Blowfish and Crypt::CBC and Java Cipher
Message-Id: <E4mdnQjWT59KmWDfRVn-gw@comcast.com>
I have to admit I barely understand any cryptography beyond the simple A=1
type codes my friends and I used in grammar school. I have a server,
running Perl, that takes a file, encrypts it with Blowfish, then MIME
encodes it, sends it out via e-mail. Then I have a Java program that
retrieves the e-mail, MIME decodes it, then decrypts it. I am having no
problem on the Perl end, and any encrypted e-mail I create I can retrieve
and decode. There seems to be no problem with MIME encoding/decoding. The
problem comes when my Java program tries to decrypt the file created and
sent by Perl. I always get:
javax.crypto.BadPaddingException: Given final block not properly padded
When I first set this up, with the Perl code on another computer, I got
errors like that. They stopped, but I was never sure exactly what I did to
solve the problem (and I'm never comfortable with a situation like that).
I tried to examine my changes, and I could never be sure just what fixed
it. Now the Perl code is running on a new system. I'm using a later
version of Crypt::CBC (from 2.08 to 2.12), but I can't see anything in the
changelog that should effect the problem I'm having. I'd also like to
solve the problem once and for all, which means either understanding what
is going wrong with the BadPaddingException, or knowing what to do so Java
has no problem reading the encrypted data Perl sends.
My Perl code to encrypt the data is this:
$cipher = Crypt::CBC->new( { 'key' => $key, iv => $vector,
prepend_iv => 0, 'cipher' => 'Blowfish', 'regenerate_key' => 0 } );
$data = $cipher->encrypt($rawdata);
My Java code to decrypt the data is this:
//sCryptoKey and sCryptoVector are strings with the key and vector
//bCrypto is byte[] of encrypted data
//bDecrypted is byte[] of decrypted data
try {
SecretKeySpec oKey = new SecretKeySpec(sCryptoKey.getBytes("UTF8"),
"Blowfish");
IvParameterSpec oIV = new
IvParameterSpec(sCryptoVector.getBytes("UTF8"));
Cipher oCipher = Cipher.getInstance("Blowfish/CBC/PKCS5Padding");
oCipher.init(Cipher.DECRYPT_MODE, oKey, oIV );
bDecrypted = oCipher.doFinal(bCrypto);
} catch (Exception e) {
//Log the error
sysConfig.log("error", "error decrypting incoming file -- saving to
log
directory: " + e);
}
I'd like to have some better understanding of why I'm getting errors. I'm
not even fully clear on what padding is. I've tried reading up on how
Blowfish works, but I really don't follow it. From what I can see, I
suspect if I change the PKCS5Padding to NoPadding in the Java code should
work, but I'm assuming Padding is just the padding of data on the end. Is
there a way to tell Cipher to figure out the padding, or to take the data
"as is"? I'm also trying to find if there is a way to specify padding on
the Perl end. According to the docs for CBC on CPAN, the padding() method
in CBC is read-only, and I don't see a way to specify the padding in CBC.
I would think as long as I can specify the same padding on both ends there
should be no problem, but, again, there seems to be no way to specify
padding for Crypt::CBC.
Thanks for any help!
Hal
------------------------------
Date: 12 Aug 2005 22:05:00 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Perl numerics: EPSILON and equality between floats
Message-Id: <ddj6ec$ebs$1@mamenchi.zrz.TU-Berlin.DE>
bill <please_post@nomail.edu> wrote in comp.lang.perl.misc:
> In <ddi69e$o30$1@mamenchi.zrz.TU-Berlin.DE>
> anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) writes:
>
> >bill <please_post@nomail.edu> wrote in comp.lang.perl.misc:
> >> In <ddhtkk$iuq$1@mamenchi.zrz.TU-Berlin.DE>
> >> anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) writes:
[snip comparison of floats]
> >Something like that "binary eq" could probably be written (in Perl
> >or otherwise), but what would it gain? In effect, it gives you a
> >choice of epsilons that are powers of two, instead of powers of ten
> >like rounding. The practical difference is small.
>
> The effect is to leave it up to the user to decide, instead of
> forcing him/her to rationalize a suboptimal situation after the
> fact. The phrase "practical difference" makes a huge blanket
> assumption about the task at hand. What's "good enough"? 10%?
> 1%? 0.0001%?
Hmmm? Even the rounding approach gives you the choice of exactly
that? I don't get the big diff. The right approach to float
comparison is an epsilon approach, where (in principle) epsilon
must be specified for each comparison. The same goes for rounding,
whether done in decimal or binary. In principle, the number of
places to round must be specified on each comparison. There's your
chance to decide what's good enough. Nothing is being forced on you.
The rounding approach is basically equivalent to epsilon values
that are powers of ten (or two), just more convenient than a
specific comparison procedure. You get fewer choices of epsilon,
but you don't need that many.
> The answer obviously depends on the application, and
> my philosophy is to give as much power to the user as possible.
> In this case, the best that can be done is to allow a binary
> specification of precision, and let the user avail him/herself of
> this as desired.
Nah... that would depend on the odds and ends of the local representation
of floating point numbers. That's not a good thing for a program to
depend on. Specify the "range of equality" numerically, explicitly
or implicitly through rounding.
> I suppose "binary eq" could be written using pack/unpack, but even
> though I've been programming Perl for 8+ years and consider myself
> pretty proficient at it, I remain a pack/unpack illiterate. For
> some reason, even after I study pack/unpack intensively, its
> operations seem mysterious to me, and therefore my minds retains
> whatever I learn about it for roughly one nanosecond. Maybe I
> should just read the perl source to finally understand it.
That's not the way to understand pack/unpack. To learn about them,
play with them. Few people learn all the pack/unpack specifications
by heart, that's something to look up in each case. But it's useful
to acquaint oneself with the basic possibilities, so write a few test
cases and see what you get. It isn't used often, but for some things
it is just the ticket. One of them is reading of fixed-column data,
another (somewhat surprisingly) is counting the one-bits in a bit
string. Pack/unpack might be used in a "binary compare", but not
before we know what exactly it does.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Fri, 12 Aug 2005 12:09:49 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: sort
Message-Id: <xJ4Le.11$v27.325@news.uswest.net>
Pietro wrote:
> Thanks to all, now I have understood (above all I did not use -w).
If it's IP addresses that you're trying to sort, use the already
provided, and very fast, sort_by_ip_address method from Net::Netmask:
If it's not IP addresses, and your data just happened to look like it,
then, nevermind. :-)
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 8319
***************************************
