I am compiling Crypto++ 5.1 on Redhat 9.0, and it seems to work fine (for
what I'm using it for). I do have a couple of comments and questions.
My system as configured:
uname -a:
Linux localhost 2.4.20-8 #1 Thu Mar 13 17:18:24 EST 2003 i686 athlon i386
GNU/Linux
gcc -v:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Question the first:
Within polynomi.cpp, the deprecated header (according to g++) <strstream>
should not be used. I changed it to <sstream>. I also changed references
to istrstream and ostrstream to istringstream and ostringstream.
While the remainder of the code is clean (as far as header usage), it seems
odd to me that <strstream> is the only remaining "odd" header. Is there a
plan to change this in the future?
Question the second:
Within zinflate.cpp, there is a compiler warning:
zinflate.cpp: In member function `bool CryptoPP::Inflator::DecodeBody()':
zinflate.cpp:502: warning: unreachable code at beginning of switch
statement
I look at the code, and I see the following:
switch (m_nextDecode)
{
while (true)
{
case LITERAL:
if (!m_literalDecoder.Decode(m_reader, m_literal))
...
...
}
}
Of course, such a construct, i.e. a while loop outside a case statement,
yet inside a switch statement, before any case statement has been reached,
seems quite odd. It makes sense that such code is unreachable. But is
such code legal? Is such code desirable? Is there some effect on another
system system that I'm not aware of? Why is it there?
Thinking perhaps it was fixed in a later release, I went to the CVS
repository itself. There are no version numbers in zinflate.cpp file
itself, so I just perused the one online vs the one in the release. They
are different. The above code still exists, but not at line 502. It's now
at line 446. So, this construct did not get changed in the newest code.
I don't use the inflator, so it doesn't bother me that it results in a
warning. However, I'm just curious about the code and why it is there. If
it shouldn't be there, perhaps someone has a fix?
Question the third:
The random number generation in Crypto++ is a nice portion. In fact, I
found the X9.17 implementation nice. Unfortunately, NIST has yanked
support of X9.17 because of ANSI's decertification. Instead, NIST now says
that the random number generation in FIPS 186-2, ANSI X9.31 or ANSI X9.62
are the only approved algorithms. Crypto++ does offer SHA1 (and DES) as
primitives to build a FIPS compliant RNG. I've read through the FIPS
documentation, and Appendix 3 explains the implementation.
I've been considering writing the RNG, but for my use. I'm not 100%
(perhaps not even 50%) certain of how to fit the DSS RNG into the Crypto++
framework. Given the task of generating an Crypto++ friendly
implementation of the DSS RNG, I thought perhaps Wei was considering
updating his RNGs (or adding to them).
So, does a Crypto++ friendly version of the DSS RNG (SHA1 or DES based)
exist? Is Wei working on it?
Thanks for the info,
Pete LaDow
[EMAIL PROTECTED]
------------------------------------------------
This e-mail may contain SEL confidential information. The opinions
expressed are not necessarily those of SEL. Any unauthorized disclosure,
distribution or other use is prohibited. If you received this e-mail in
error, please notify the sender, permanently delete it, and destroy any
printout. Thank you.
