RE: Generating Unique Initialization Vectors

[Søren Dreijer]

Jeff,
 
> If the OS blocks, it sleeps the thread until the entire request is
> processed. In Windows, think of a synchronous versus asynchronous disk
> request. Take a look at Wei's code in osrng.cpp.

That's what I've been assuming so far. I was a bit unsure if it referred to, like, blocks of data rather than actual execution.
If you're doing unblocked generation then how do you know when you can actually use the data?
 
What does the seedSize argument in AutoSeededRandomPool's constructor refer to?

> Take a look at CryptGenRandom( ) on page 9 of
> http://csrc.nist.gov/cryptval/140-1/140sp/140sp238.pdf#search=%22microsoft%20cryptographic%20provider%20random%20number%20generator%22.
> This is XP documentation. You'll have to do your own homework for
> previous NT systems.
 
I'll have to take a look whether Wei uses that specific function then. If he does, everything seems to be in order on Windows systems, at least.
 
> IIRC, GeneratBlock( ) defers to multiple GenerateByte( ) calls.
 
I bet it does, but in my opinion the first is still cleaner to use if you need to generate more than a single byte anyway
 
> * Wei's AES implementation is limited to 160 bits at this point. 192
> and higher are not implemented.
 
That I didn't know. So you're saying the maximum symmetric key you can use with Crypto++ is 160 bits? I really, really wanted 256 bits..
As an aside, this is also why I think this library should have a much more extensive documentation. There are so many things with this library that you don't know because there isn't a formal documentation of the basic algorithms.
 
Thanks for the replies, Jeff. It's been very long since I received a constructive reply from this mailing list.
 
- Soren
 

---

> Date: Tue, 5 Sep 2006 11:49:11 -0400
> From: [EMAIL PROTECTED]
> To: cryptopp-list@eskimo.com
> Subject: Re: Generating Unique Initialization Vectors
>
> Hi Soren,
>
> > blocking means compared to nonblocking...
> If the OS blocks, it sleeps the thread until the entire request is
> processed. In Windows, think of a synchronous versus asynchronous disk
> request. Take a look at Wei's code in osrng.cpp.
>
> > I guess using the library on other systems than
> > Windows does not guarantee a unique IV.
> I personally would not make that assumption.
>
> > Also, does using MCP guarantee a unique random value each time
> Take a look at CryptGenRandom( ) on page 9 of
> http://csrc.nist.gov/cryptval/140-1/140sp/140sp238.pdf#search=%22microsoft%20cryptographic%20provider%20random%20number%20generator%22.
> This is XP documentation. You'll have to do your own homework for
> previous NT systems.
>
> > wrap your own random generator on Windows
> > which actually uses that function
> I'd trust Wei's code (for fun, Google for NSA_key) ... He uses
> Cryptographically Secure PRNGs. I think the place to look is rng.cpp
> (but it has been a while). Step Into GenerateByte( ) or GeneratBlock(
> ) function while under a debugger. IIRC, GeneratBlock( ) defers to
> multiple GenerateByte( ) calls.
>
> Also, for completeness, I should use pseudo RNG (PRNG), rather than simply RNG.
>
> Finally, Java is highly regarded. You might research how Gossling and
> crew handle PRNG on the various platforms it supports.
>
> Other caveats (working from memory):
> * Wei's AES implementation is limited to 160 bits at this point. 192
> and higher are not implemented.
> * If AES in modes other than CBC, one requires a an _encryption_
> object to both encryp and decrypt. Google the Crypto++ archives. It
> has come up a few times. The FAQ has an AES sample at
> http://www.eskimo.com/~weidai/cgi-bin/fom-serve/cache/79.html
>
> Jeff
>
> On 9/4/06, Søren Dreijer <[EMAIL PROTECTED]> wrote:
> > Jeff,
> >
> > Thanks for the swift reply!
> >
> > Currently I just use GenerateBlock() to generate the entire random sequence in one go instead of calling GenerateByte() continually.
> >
> > Speaking of which, I'm not really sure what blocking means compared to nonblocking?
> >
> > I guess using the library on other systems than Windows does not guarantee a unique IV. Do you know how the autoseeding function works? Does it take things such as time into account to minimize collisions?
> > Also, does using MCP guarantee a unique random value each time? I know the API provides such a function but I don't know if Crypto++ uses it. If it doesn't it would probably be better to wrap your own random generator on Windows which actually uses that function..
> >
> > Cheers!
> >
> > > Date: Mon, 4 Sep 2006 19:54:04 -0400
> >
> > > From: [EMAIL PROTECTED]
> > > To: cryptopp-list@eskimo.com
> > > Subject: Re: Generating Unique Initialization Vectors
> > >
> > > SNIP...
> > >
> > > On 9/4/06, Søren Dreijer <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Yes, I know how you use it but I don't see anything about how to use it to
> > > > generate a unique IV..
> > > >
> > > > ________________________________
> > > > > Date: Mon, 4 Sep 2006 17:27:38 -0400
> > > > > From: [EMAIL PROTECTED]
> > > > > To: cryptopp-list@eskimo.com
> > > > > Subject: Re: Generating Unique Initialization Vectors
> > > > >
> > > > > SNIP...
> > > > >
>

---

Windows Live Spaces is here! It’s easy to create your own personal Web site. Check it out!