I've seen Wei on a few times since I've posted this message. I haven't
seen a response, so in case it has been missed, I'm reposting it. Some of
the questions are important to our development (such as support for RNGs
based upon the DSS), and I'm hoping someone can reply.
Thanks,
Pete LaDow
[EMAIL PROTECTED]
__________________
Thanks for the prompt reply. For a free library, your activity on
development and maintenance is outstanding. Thanks for your work.
I have a couple of responses below.
Wei Dai <[EMAIL PROTECTED]> wrote on 07/29/2003 04:50:06 PM:
> <sstream> is not available with GCC 2.9x. I'll have to use
> <strstream> until GCC 2.9x is no longer supported.
I see. Makes sense. Perhaps an #ifdef on the GCC version? I can submit a
patch if you like.
> The code is not unreachable. The compiler is just not smart enough to
> notice. Still, I've moved the code around a bit to remove the warning.
> It was checked into CVS already before you posted your message, so I
> don't know why you didn't see it. If you're looking at CVS on the web
> site, it may be time delayed.
I used the sourceforge interface. I grabbed version 1.5. I just grabbed
it again, and it hasn't changed. I see though that it hasn't been updated
in 24 hours.
Either way though, can you explain the syntax? How should it work?
Should it be identical to:
while(true)
{
switch(...)
{
case ...:
}
}
And from my college days in compiler design, I though a switch/case
statement resolves to a branch table where the case labels are the branch
targets. Any code between the switch and the branch target would be
compiled in-between--thus unreachable.
I've never seen the syntax that exists, and I'm curious as to how it is
supposed to operate.
> ANSI X9.31's RNG is just X9.17's RNG with Triple-DES. So Crypto++
> already implements it.
True, as outlined in Appendix A.2.4 of ANSI X9.31. I asked the wrong
question then.
Is there any plan to support the RNGs as defined in ANSI X9.31, ANSI X9.62,
or FIPS 186-2 constructed from SHA1 or the DEA?
I ask this because we need something other than the X9.17 equivalent
process. Our current application has access to a time source (as required
by Append A.2.4: "Let DT be a date/time vector which is updated on each
iteration"), but our next design will not have access to such a source.
Perhaps you can answer this question: Must the date/time vector match (or
closely match) the true time (be it GMT, whatever)? Or can the date/time
vector just be a free running counter? Can the counter be bounded (i.e.
wrap)?
Our final design will have a free running counter, but of limited size.
Access to the "true" time is impossible. However, we do have a noise
source available for sampling "random" numbers. As such, we like the
Appendix A.2.1 approach. This gives us the source for the seed and XKEY as
needed by A.2.1 implementation.
Am I making sense?
Thanks for your help,
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.
