Re: Crypto++ 5.0 beta available

[Rickey Braddam]

Hi, Wei Dai.
I downloaded beta 5.0, compiled it 'straight up', and it compiled
successfully under VC5 without any errors.

Then I ran the validation, and everything validated correctly, passed all
tests.

When I ran the benchmarks, though, I got the following (copied from the html
output) as the last line:

<TR><TH>LUC 512 Decryption<TD>267<TD>1.001<TD>3.75CryptoPP::Exception
caught: BER decode error

I did compare the luc512.dat file with the one in the CryptoPP 4.2 library,
and they were identical. Sorry, I didn't think to compare the dat files for
the next test, which could have been the one to cause the error.

Just thought you'd like to know.

Rick shared...@earthlink.net http://home.earthlink.net/~sharedsecrets

[Rickey Braddam]

Hello again. Did some more testing and found that I could comment out
specific lines in bench.cpp and run all the way through. Remember that I
originally got these errors with VC6, I'm also getting the same errors with
VC7 (.NET).

These lines generated the error messages that follow them:

BenchMarkCrypto<DLIES<>>("elgc512.dat","ELIES 512",t);

CryptoPP::Exception caught: BER decode error

BenchMarkCrypto<DLIES<>>("elgc1024.dat","DLIES 1024",t);

CryptoPP::Exception caught: BER decode error

BenchMarkCrypto<DLIES<>>("elgc2048.dat","DLIES 2048",t);

CryptoPP::Exception caught: BER decode error

BenchMarkSignature<DSA>("dsa512.dat","DSA 512",t);
CryptoPP::Exception caught: CryptoMaterial: this object contains invalid
values

With those four lines commented out, cryptest b runs to completion and
terminates normally.

Rick shared...@earthlink.net http://home.earthlink.net/~sharedsecrets

[Wei Dai]

I've made a beta release of Crypto++ 5.0. You can download it at
http://www.eskimo.com/~weidai/cryptopp50beta.zip. I'm doing a beta release
before a normal release for two reasons. First, in 5.0 there are many new
interfaces and structural changes (i.e. even more extensive use of
templates) so there is an increased chance of bugs compared to
previous releases. Second, Crypto++ 5.0 is being evaluated against FIPS
140-2, on Microsoft Windows as a static library. If you have any interest
in using Crypto++ as a FIPS 140 validated crypto module, you will probably
want to test this beta release and report any problems ASAP. (If you
are interested in the FIPS validation, please contact me so I have some
idea of how much interest there is.)

This beta release has been tested only with MSVC 6.0 SP5 and Cygwin/GCC
3.0.4. I do plan to port it to other platforms and compilers before the
final release so don't worry too much about that yet. :)

A reference manual for this beta release is available at
http://www.ibiblio.org/weidai/cryptopp50beta/index.html. It should be very
helpful in understanding the interface changes.

Here are the major changes in 5.0:

5.0 (beta)
- added ESIGN, DLIES, WAKE-OFB
- added key validation for asymmetric algorithms
- renamed StreamCipher interface to SymmetricCipher, which is now implemented
by both stream ciphers and block cipher modes including ECB and CBC
- added keying interfaces to support resetting of keys and IVs without
having to destroy and recreate objects
- changed filter interface to support non-blocking input/output
- changed SocketSource and SocketSink to use overlapped I/O on Microsoft Windows
- grouped related classes inside structs to help templates, for example
AESEncryption and AESDecryption are now AES::Encryption and AES::Decryption
- where possible, typedefs have been added to improve backwards
compatibility when the CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY macro is defined
- is being evaluated for FIPS 140-2 compliance
- fixed a bug in HMAC::TruncatedFinal()

[Wei Dai]

Thanks for the report. I'll get the problems fixed. For those who are
wondering what caused the errors, by default Crypto++ now stores all
discrete log keys (not just DSA keys) using the DSA key formats specified
in 7.3.3 of RFC 2459 and 12.9 of PKCS #11 v2.10, instead of the previous
non-standard format (except for ElGamal encryption which continues to use
the old format because the encryption algorithm is not standard anyway).
See DL_PublicKey_GFP class versus DL_PublicKey_GFP_OldFormat. You can
continue to use the old format if you want by specifying
DL_PublicKey_GFP_OldFormat as a template parameter in the appropriate
places, and you can convert existing keys to the new format by doing
something like this:

DL_PublicKey_GFP_OldFormat<DL_GroupParameters_GFP>
key(FileSource("keyfile").Ref());
DL_PublicKey_GFP<DL_GroupParameters_GFP>(key).DEREncode(
FileSink("newkeyfile").Ref());

And similarly for the private key.

The last error happened because to comply with FIPS 186-2 Change Notice 1,
only 1024-bit DSA keys will be allowed. If you need to use smaller DSA
keys, you must #define DSA_1024_BIT_MODULUS_ONLY to 0 in config.h, or use
the GDSA class which stands for Generalized DSA.

[Jim Darby]

Hi All,

I've just downloaded Crypto++ 5.0 beta and given it a shot. I tried it ``out
of the box'' on a Mandrake Linux 8.2 with GCC 3.1 installed as an extra and it
compiled and worked fine. Ok, there were an infinite number of warnings about
missing typenames. Actually, this IS a problem as a compiler is well within
its right to refuse to compile the code because of the missing typenames. It
is a GCC extension that the typename may be omitted.

What is the issue here? Do some compilers not implement typename? If so,
something like:

#if defined (BROKEN_COMPILER_A) | defined (BROKEN_COMPILER_B)
#define TYPENAME
#else
#define TYPENAME typename
#endif

then using TYPENAME where it is needed may solve the problem.

I did notice that by default the code is compiled WITHOUT optimisation. I then
recompiled the code WITH optimisation (-O3 to be specific) and it ended up
with the following:

BlumBlumShub validation suite running...

passed 49ea2cfdb01064a0bbb92af101dac18a94f7b7ce
FAILED 0737bfab3c475bd997d1
cryptest.exe: integer.cpp:1997: void CryptoPP::RecursiveMultiplyTop(word*,
word*, const word*, const word*, const word*, unsigned int, const P*) [with P
= CryptoPP::LowLevel]: Assertion `carry >= 0 && carry <= 2' failed.

which is very worrying. Any ideas?

By the way, as I mentioned earlier Crypto++ 4.2 can be made to compile with
GCC 3.1 but the SHARK validation fails.

Hope this helps,

Jim.

[Christian Gmeiner]

I have some problems:
I use VC++ 6.0 SP 5
If i compile the whole thing with F7 then i get about 80 internal compiler
errors. If i compile every sourcefile per hand (STRG/CRLT + F7) then i
comples with no errors. What shall i do?

Christian Gmeiner

[Neville Franks]

Hi Christian,
When I've had this problem with Crypto++ freeing some disk space often
helps. If you continue to have this problem then from memory if you
continue to press Build VC6 will eventually get through all of the files.

Tuesday, July 09, 2002, 9:03:08 PM, you wrote:

CG> I have some problems:
CG> I use VC++ 6.0 SP 5
CG> If i compile the whole thing with F7 then i get about 80 internal compiler
CG> errors. If i compile every sourcefile per hand (STRG/CRLT + F7) then i
CG> comples with no errors. What shall i do?

CG> Christian Gmeiner
CG> ----- Original Message -----
CG> From: "Wei Dai" <wei...@eskimo.com>
CG> To: <crypto...@eskimo.com>
CG> Cc: <cryptopp...@lists.sourceforge.net>
CG> Sent: Saturday, July 06, 2002 1:16 AM
CG> Subject: Crypto++ 5.0 beta available

>> I've made a beta release of Crypto++ 5.0. You can download it at
>> http://www.eskimo.com/~weidai/cryptopp50beta.zip. I'm doing a beta release
>> before a normal release for two reasons. First, in 5.0 there are many new
>> interfaces and structural changes (i.e. even more extensive use of
>> templates) so there is an increased chance of bugs compared to
>> previous releases. Second, Crypto++ 5.0 is being evaluated against FIPS
>> 140-2, on Microsoft Windows as a static library. If you have any interest
>> in using Crypto++ as a FIPS 140 validated crypto module, you will probably
>> want to test this beta release and report any problems ASAP. (If you
>> are interested in the FIPS validation, please contact me so I have some
>> idea of how much interest there is.)
>>
>> This beta release has been tested only with MSVC 6.0 SP5 and Cygwin/GCC
>> 3.0.4. I do plan to port it to other platforms and compilers before the
>> final release so don't worry too much about that yet. :)
>>
>> A reference manual for this beta release is available at
>> http://www.ibiblio.org/weidai/cryptopp50beta/index.html. It should be very
>> helpful in understanding the interface changes.
>>
>> Here are the major changes in 5.0:
>>
>> 5.0 (beta)
>> - added ESIGN, DLIES, WAKE-OFB
>> - added key validation for asymmetric algorithms
>> - renamed StreamCipher interface to SymmetricCipher, which is now

CG> implemented

>> by both stream ciphers and block cipher modes including ECB and CBC
>> - added keying interfaces to support resetting of keys and IVs without
>> having to destroy and recreate objects
>> - changed filter interface to support non-blocking input/output
>> - changed SocketSource and SocketSink to use overlapped I/O on

CG> Microsoft Windows

>> - grouped related classes inside structs to help templates, for

CG> example

>> AESEncryption and AESDecryption are now AES::Encryption and

CG> AES::Decryption

>> - where possible, typedefs have been added to improve backwards
>> compatibility when the CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY

CG> macro is defined

>> - is being evaluated for FIPS 140-2 compliance
>> - fixed a bug in HMAC::TruncatedFinal()
>>

--
Best regards,
Neville Franks, Author of ED for Windows - the programmers editor, an indispensable tool for great software development.
http://www.getsoft.com Version 4.01 now available. New: Projects, Source Database, Difference Analysis....
Soft As It Gets Pty Ltd,
12 Fairview Grove, Glen Iris, VIC, 3146 Australia
Ph +61 3 9885 4445, Fax +61 3 9885 4444, mailto:read...@getsoft.com

[Jim Darby]

I've done a little further investigation of the problem of Crypto++ 5.o beta
not working with GCC 3.1 on Mandrake Linux 8.2 on an x86.

The problem is in integer.cpp where the assert macro on line 1997 fails. This
only happens when the code is compiled optimised.

I thought it might be a problem with the GCC/x86 optimised code so I altered
the #if stuff so that it used the portable versions. Unfortunately this didn't
solve the problem.

Clearly there is a problem here. Maybe its a bug in Crypto++ and maybe its a
bug in GCC 3.1. I'm still trying to figure it out.

I'll keep the list posted with progress reports.

In the meantime, if anyone else has tried Crypto++ 5.0 beta with GCC 3.1 on
any platform, x86 or otherwise, I'd be very interested in hearing the results.

NEWSFLASH: I've been playing with the optimisation levels. -O1 and -O2 work,
-O3 doesn't. This is VERY interesting! According to the documentation -O3 is
only different from -O2 in that it adds -finline-functions and
-frename-registers. By using -O2 and manually adding the flags one at a time
I've found out that -finline-functions doesn't seem to make a difference but
-frename-registers does!

All very odd...

Any ideas anyone?

Many thanks,

Jim.

[Arthur C. Hsu]

Hello,

There are many kinds of internal error. According to my experience, the
most common one is running out of disk space.
The second suspect is lacking of memory. Try to add a /Zm200 option if
you see the "internal heap limit reached" error.

If you can list these errors distinctly, I think you'll get more precise
answer soon :)

Arthur Hsu

-----原始郵件-----
寄件者: Christian Gmeiner [mailto:cry...@visual-page.de]
寄件日期: Tuesday, July 09, 2002 4:03 AM
收件者: crypto...@eskimo.com
主旨: Re: Crypto++ 5.0 beta available

[Richard Jagodzinski]

Hi,

We've been using 4.1 for about 6 months & have been looking at upgrading to
4.2. I know that fips validation is something that I would really like to
see in Crypto++. It would make selling crypto++ based apps to government
agencies easier. If nothing else it is a potent marketing tool.

Cheers
Richard

implemented
by both stream ciphers and block cipher modes including ECB and CBC
- added keying interfaces to support resetting of keys and IVs without
having to destroy and recreate objects
- changed filter interface to support non-blocking input/output

- changed SocketSource and SocketSink to use overlapped I/O on Microsoft
Windows
- grouped related classes inside structs to help templates, for example

AESEncryption and AESDecryption are now AES::Encryption and

AES::Decryption
- where possible, typedefs have been added to improve backwards

compatibility when the CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY macro

[Neville Franks]

LT> On which operating system platform you built the
LT> Crypto++ library?

>>From my experience, the compilation may have problems
LT> with Win9x. Windows 2000 is free of the problem.

I'm using Win XP Pro and Win XP Home right now, but I'm reasonably
sure that I've had this problem on W98 and W2K as well.

Note that I'm still using Crypto++ 4.1

If you press Build after getting these errors does it progress past
any of the files which raised the fatal error?

As Arthur Hsu suggested more memory may also be required. Also if
you have multiple disk drives make sure that both the drive containing
Crypto++ and the drive containing Windows (temp directories etc.) have
plenty of free space.

LT> --- Neville Franks <read...@getsoft.com> wrote:
>> Hi Christian,
>> When I've had this problem with Crypto++ freeing
>> some disk space often
>> helps. If you continue to have this problem then
>> from memory if you
>> continue to press Build VC6 will eventually get
>> through all of the files.
>>
>>
>> Tuesday, July 09, 2002, 9:03:08 PM, you wrote:
>>
>> CG> I have some problems:

>> CG> I use VC++ 6.0 SP 5
>> CG> If i compile the whole thing with F7 then i get
>> about 80 internal compiler
>> CG> errors. If i compile every sourcefile per hand

>> (STRG/CRLT + F7) then i

>> CG> comples with no errors. What shall i do?
>>
>> CG> Christian Gmeiner
>> CG> ----- Original Message -----
>> CG> From: "Wei Dai" <wei...@eskimo.com>
>> CG> To: <crypto...@eskimo.com>
>> CG> Cc: <cryptopp...@lists.sourceforge.net>
>> CG> Sent: Saturday, July 06, 2002 1:16 AM

>> CG> Subject: Crypto++ 5.0 beta available

LT> http://www.ibiblio.org/weidai/cryptopp50beta/index.html.

>> It should be very
>> >> helpful in understanding the interface changes.
>> >>
>> >> Here are the major changes in 5.0:
>> >>
>> >> 5.0 (beta)
>> >> - added ESIGN, DLIES, WAKE-OFB
>> >> - added key validation for asymmetric
>> algorithms
>> >> - renamed StreamCipher interface to
>> SymmetricCipher, which is now

>> CG> implemented

>> >> by both stream ciphers and block cipher
>> modes including ECB and CBC
>> >> - added keying interfaces to support
>> resetting of keys and IVs without
>> >> having to destroy and recreate objects
>> >> - changed filter interface to support
>> non-blocking input/output
>> >> - changed SocketSource and SocketSink to use
>> overlapped I/O on

>> CG> Microsoft Windows

>> >> - grouped related classes inside structs to
>> help templates, for

>> CG> example

>> >> AESEncryption and AESDecryption are now
>> AES::Encryption and

>> CG> AES::Decryption

>> >> - where possible, typedefs have been added to
>> improve backwards
>> >> compatibility when the
>> CRYPTOPP_MAINTAIN_BACKWARDS_COMPATIBILITY

>> CG> macro is defined

>> >> - is being evaluated for FIPS 140-2
>> compliance
>> >> - fixed a bug in HMAC::TruncatedFinal()
>> >>
>>

[Lawrence Teo]

On which operating system platform you built the

Crypto++ library?

>From my experience, the compilation may have problems

with Win9x. Windows 2000 is free of the problem.

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

[Jim Darby]

Hi Everyone,

I've been experimenting with Crypto++ 5.0 beta. More specifically the
performance of the various cipher modes. It took a little while to get exact
numbers but I've found that those cipher modes the require padding (CBC and
ECB) where running at less than half the speed of the non-padded modes (CFB,
OFB and CTR).

On inspection of the code it would appear that the bottle neck isn't the
actual padding as such; after all, this is only invoked once per encryption.
The problem is the loop in filters.cpp, especially
FilterWithBufferedInput::PutMaybeModifiable where its putting data through the
cipher.

For the case of stream ciphers, such as CFB, OFB and CTR modes, the loop
blasts them all though in one long go (line 290) but in the case of there
being a block size it is forced to go through a single block at a time (line
315) when in fact all blocks that cannot be the last block can be blasted
through at once (for example given n blocks of input plus s spare bytes we
know we can blast n - 1 blocks through).

Or am I missing something?

Jim.

[Jim Darby]

Here's a rather crude patch to filters.cpp that speeds up the CBC mode by a
factor of almost TEN on my machine (400MHz AMD K6-2, Linux, GCC 3.1). Can I
suggest it gets put into 5.0 before its released as it REALLY makes for a
performance increase.

It works by putting as many blocks as possible through rather than just one at
a time.

315,317c315,326
< NextPutMaybeModifiable(inString, m_blockSize, modifiable);
< inString += m_blockSize;
< newLength -= m_blockSize;
---
> unsigned int put (newLength - m_lastSize);
>
> put -= put % m_blockSize;
>
> NextPutMaybeModifiable(inString, put, modifiable);
> inString += put;
> newLength -= put;

I suspect that the entire while loop can be replaced with a simple bit of
code. I would just like for Wei Dai to have a quick check of the code to
ensure that I haven't violated any of the design constraints.

Many thanks,

Jim.

[Jim Darby]

I wrote:

> Here's a rather crude patch to filters.cpp that speeds up the CBC mode by a
> factor of almost TEN on my machine (400MHz AMD K6-2, Linux, GCC 3.1).

Ok, I was wrong, I used the wrong test file. Its actually only a factor of TWO
speed up. Its still worth having though.

Jim.

[Wei Dai]

Thanks. I'll put in a fix for it.