Failure of verification test when collecting random data.
Hezekiah
Hash: SHA1
Hello, all! :)
I've been working with Crypto++ for a while now, and have been keeping a
close eye on progress of 5.0. I downloaded it when it came out and compiled
it using gcc 3.2 without a hitch. Then, I ran the verification suite. A while
back when I was playing around with the 5.0 beta, I had noticed that
sometimes the second test of the blocking random number generator failed. I
was wondering if this still occurred under the 5.0 release. Thus, I gave it a
shot and tried to make it mess up.
I have discovered that I can make the test bomb predictably by just maxing
the CPU out at 100% while it's on the second test. For me that isn't too
hard. Just start 2-3 copies of Konquerer! :) Here's the output of the test
when it fails.
Using seed: 1033610324
Testing operating system provided blocking random number generator...
passed: it took 0 seconds to generate 16 bytes
FAILED: it generated 14588 bytes in 2 seconds
passed: 23166 generated bytes compressed to 23176 bytes by DEFLATE
Testing operating system provided nonblocking random number generator...
passed: 100000 generated bytes compressed to 100035 bytes by DEFLATE
Test ended at Wed Oct 2 21:58:57 2002
Seed used was: 1033610324
Just in case the seed was to blame I have tried the same test again using the
same seed, but letting the CPU usage remain at a normal level. This works
great! Here's the output of it working:
Using seed: 1033610324
Testing operating system provided blocking random number generator...
passed: it took 0 seconds to generate 16 bytes
passed: it generated 641 bytes in 15 seconds
passed: 1154 generated bytes compressed to 1159 bytes by DEFLATE
Testing operating system provided nonblocking random number generator...
passed: 100000 generated bytes compressed to 100035 bytes by DEFLATE
Test ended at Wed Oct 2 22:03:14 2002
Seed used was: 1033610324
Notice the HUGE difference in the number of bytes generated. Is this a bug in
Crypto++, or is there some weird condition that makes the operating system
random number generator go weird when the CPU maxes out? Either way, should I
be worried about this affecting the quality of the cryptography?
In case it helps any, my box has AMD K6-2 333MHz, and I'm running Gentoo
Linux. As I said before, I compiled with gcc 3.2. (However, I have noticed
this on the 5.0 beta with lesser versions of gcc as well.)
Hope this gets solved/fixed/figured-out!! If you need me to do any kind of
other tests to figure this out, just let me know! :)
Sincerely,
Hezekiah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9m6bNicjSr4uiPQERAt6gAKCE7wAbtyaLmgL3pq6kIcmd99gZrACdH3A1
X4KxAKSxdEcVzF3LNgAoAB0=
=ngfD
-----END PGP SIGNATURE-----
Wei Dai
> Notice the HUGE difference in the number of bytes generated. Is this a bug in
> Crypto++, or is there some weird condition that makes the operating system
> random number generator go weird when the CPU maxes out? Either way, should I
> be worried about this affecting the quality of the cryptography?
That is wierd. The test that failed tries to make sure that the blocking
RNG's (in this case /dev/random) entropy estimation isn't totally off. It
seems unlikely that /dev/random was actually able to gather 14588
bytes of entropy in 2 seconds, so I'd say there might be a bug in the
/dev/random driver. Can you look in the source code for your OS, find out
the person who wrote the /dev/random driver, and ask him to look into
this?
Lawrence Teo
Can anyone point me to an appropriate place that lists
down the complete release dates for different versions
of Crypto++ (starting from version 1.0)
And, are those older versions still available for
downloading?
Thanks.
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Wei Dai
> Can anyone point me to an appropriate place that lists
> down the complete release dates for different versions
> of Crypto++ (starting from version 1.0)
It's not listed anywhere, but you can possibly dig them up from various
mailing list archives.
> And, are those older versions still available for
> downloading?
These ones are, by appending the appropriate filename to
"http://www.weidai.com/".
crypto23.zip crypto31.zip crypto40.zip crypto42.zip
crypto30.zip crypto32.zip crypto41.zip crypto50.zip
If you really need the others, let me know why and I'll try to dig them up
for you (except version 1.0 which I withdrew at the request of RSA DSI,
now RSA Security).
Lawrence Teo
I spent some time searching around the mailing archive
and recording down the release dates for each version.
The release dates for version 1.0 to version 2.1 were
found from the mailing archive. While the release
dates for version 2.3 onwards were found directly from
the Readme files included with the Crypto++ packages.
I do not have the copies for version 1.0 to version
2.2.
Unfortunately, I could not find any release date
information for version 2.2
Please correct me if there is any error.
Crypto++ 1.0 - 23 Jun 1995
Crypto++ 1.1 - 04 Nov 1995 (this date is obscure)
Crypto++ 2.0 - 19 Feb 1996
Crypto++ 2.1 - 10 May 1996
Crypto++ 2.2 -
Crypto++ 2.3 - 17 Jan 1998
Crypto++ 3.0 - 01 Jan 1999
Crypto++ 3.1 - 27 Apr 1999
Crypto++ 3.2 - 20 Mar 2000
Crypto++ 4.0 - 02 Nov 2000
Crypto++ 4.1 - 13 Jan 2000
Crypto++ 4.2 - 05 Nov 2001
Crypto++ 5.0 - 11 Sep 2002
Lastly, I suggest to include these release dates in
the history section of Readme file in the future
releases. These dates are important especially from
the historic aspect and value.
Thanks.
Wei Dai
> I spent some time searching around the mailing archive
> and recording down the release dates for each version.
> The release dates for version 1.0 to version 2.1 were
> found from the mailing archive. While the release
> dates for version 2.3 onwards were found directly from
> the Readme files included with the Crypto++ packages.
Why the interest in these dates? Are you a historian?
The dates in the Readme files do not always correspond to release dates.
Usually they list dates when the last code change takes place, but release
often happens later for various reasons (for example further testing, or
waiting for export-controlled FTP sites to publish the files (thankfully
that's no longer a worry)).
> Unfortunately, I could not find any release date
> information for version 2.2
Readme for 2.2 is dated 5/2/1997.
> Crypto++ 1.1 - 04 Nov 1995 (this date is obscure)
Readme is dated 10/27/1995.
> Crypto++ 4.0 - 02 Nov 2000
> Crypto++ 4.1 - 13 Jan 2000
Did you notice that 4.1 is dated *earlier* than 4.0? It's a typo, and
should be 1/13/2001 instead.
Lawrence Teo
> Why the interest in these dates? Are you a
historian?
I am not a historian, but I like history. :-) I feel
software should keep a good record of their important
dates, e.g. the release date. This information might
be a valuable material for future. Anyway, this is
rather a personal opinion.
> The dates in the Readme files do not always
>correspond to release
>dates.
>Usually they list dates when the last code change
>takes place, but
>release
>often happens later for various reasons (for example
>further testing,
>or
>waiting for export-controlled FTP sites to publish
>the files
>(thankfully
>that's no longer a worry)).
In that case, I shall treat the release dates as the
one included in the Readme file.
>> Crypto++ 4.0 - 02 Nov 2000
>> Crypto++ 4.1 - 13 Jan 2000
>Did you notice that 4.1 is dated *earlier* than 4.0?
>It's a typo, and
>should be 1/13/2001 instead.
Oh ya, I didn't notice it. Thanks.
-------------------------------------------------
This is the corrected version of Crypto++ release date
history:
> Crypto++ 1.0 - 23 Jun 1995
> Crypto++ 1.1 - 27 Oct 1995
> Crypto++ 2.0 - 19 Feb 1996
> Crypto++ 2.1 - 10 May 1996
> Crypto++ 2.2 - 02 May 1997
> Crypto++ 2.3 - 17 Jan 1998
> Crypto++ 3.0 - 01 Jan 1999
> Crypto++ 3.1 - 27 Apr 1999
> Crypto++ 3.2 - 20 Mar 2000
> Crypto++ 4.0 - 02 Nov 2000
> Crypto++ 4.1 - 13 Jan 2001
> Crypto++ 4.2 - 05 Nov 2001
> Crypto++ 5.0 - 11 Sep 2002
-------------------------------------------------
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
Hezekiah
Hash: SHA1
Hi! :)
On Thursday, October 03, 2002 13:56, Wei Dai wrote:
> On Wed, Oct 02, 2002 at 10:09:11PM -0400, Hezekiah wrote:
> > Notice the HUGE difference in the number of bytes generated. Is this a
> > bug in Crypto++, or is there some weird condition that makes the
> > operating system random number generator go weird when the CPU maxes out?
> > Either way, should I be worried about this affecting the quality of the
> > cryptography?
>
> That is wierd. The test that failed tries to make sure that the blocking
> RNG's (in this case /dev/random) entropy estimation isn't totally off. It
> seems unlikely that /dev/random was actually able to gather 14588
> bytes of entropy in 2 seconds, so I'd say there might be a bug in the
> /dev/random driver.
Yeah. This IS weird! :) There might be a bug in the /dev/random driver, but
is it possible that the amount /dev/random returned got mangled someplace
along the way? (Just a thought. I could be [and probably am] way off!)
> Can you look in the source code for your OS, find out
> the person who wrote the /dev/random driver, and ask him to look into
> this?
Well, I looked at the source for /dev/random for Linux. I've reproduced the
information on the author below:
/*
* random.c -- A strong random number generator
*
* Version 1.89, last modified 19-Sep-99
*
* Copyright Theodore Ts'o, 1994, 1995, 1996, 1997, 1998, 1999. All
* rights reserved.
That's all that I saw. The only other names in the begining comment block are
just credits. Since Mr. Ts'o didn't give us an email address, I don't know
how to contact him (though perhaps it could be dug up with a search through
the kernel archives.)
Even if we could contact him, I would suggest that you talked to him. I will
be the first to admit that I am NO crypto genius! IF there really is a bug in
/dev/random, then I think the two of you could hunt it down a lot faster than
I could! If this helps any, I'm running a patched version of the Linux 2.4.19
kernel. I've also noticed this same thing under 2.4.18 as well.
If there is anything I else I can do to help, just ask. I can't promise that
I'll be able to do it (as I said, I'm no crypto genius), but I'm more than
willing to try! :)
Sincerely,
Hezekiah
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9nPcdicjSr4uiPQERApRlAJ9yUpj+7NhKP8F10UZSmrGKti489QCfZjqv
Z1MLesxBSZQ+jAdg5ARdXkQ=
=Ex4B
-----END PGP SIGNATURE-----
Voronkov Konstantin
I have a problem when verifying a signature.
What have I done wrong and why my stack breaks?
bool f(PCBYTE pSignature, int signatureSize,
PCBYTE pModulus, int pModulusSize,
PCBYTE pKey, int pKeySize,
PCBYTE pMessage, int pMessageSize)
{
StringSource signature(pSignature, signatureSize, true, new ByteQueue);
RSASSA_PKCS1v15_SHA_Verifier *ppub;
VerifierFilter *verifierFilter;
ppub = new RSASSA_PKCS1v15_SHA_Verifier(Integer(pModulus, pModulusSize),
Integer(pKey, pKeySize));
if(signature.MaxRetrievable() != ppub->SignatureLength())
{
delete ppub;
return false;
}
SecByteBlock sb_signature(ppub->SignatureLength());
signature.Get(sb_signature, sb_signature.size);
verifierFilter = new VerifierFilter(*ppub);
verifierFilter->PutSignature(sb_signature);
StringSource ss(pMessage, pMessageSize, true, verifierFilter);
byte result = 0;
ss.Get(result);
delete ppub;
return result == 1;
}
Regards,
Voronkov Konstantin
ICQ 40202717
Voronkov Konstantin
Wei Dai
error message, and stack trace that you see. Also, what version of
Crypto++, what compiler, OS are you using?
I would think this is common sense, but people keep posting questions
without these pieces of information. I'll update the web site to tell
people to submit them. Maybe that'll help.