Hiya,
Michael Wojcik wrote:
> How do you select a "random bit" of a message if you don't have a source of
> randomness in the first place? From a cryptographic perspective, you'd best
> assume an attacker knows which bit of the message you're using, even without
> knowing what the message contains.
Fair point. I was thinking along the lines of msglen/n where I'd pick
n(hardcoded) out of a hat. The msg
lengths won't be predictable but I guess they probably won't be
cryptographically random <sigh>.
>
> Also, note that a crypto PRNG seed should ideally contain considerable
> entropy. Are these messages themselves unpredictable enough to provide
> sufficient seed material?
They obviously have some standard header portion that I was proposing to omit.
As to the contents I can't say. Depends on the application.
> > I mean, if someone can predict the contents of the data well enough to
> work
> > out what my seed is, surely they've defeated the purpose of the encryption
> > anyway .. true ???
>
> That's a very big assumption. An attacker could know enough about the
> structure or probable contents of the message to greatly reduce the actual
> amount of entropy in the seed, without being able to guess the message.
> (Perhaps details in the message are important, but the message is known to
> always be English text.) An attacker might be able to inject a
> known-plaintext attack and defeat the PRNG seeding entirely. (Bob is a
> legitimate user of your system, but he's secretly trying to crack it as
> well, so he can read other people's data.)
>
> Of course, there are many ways to sanitize the sampled data to reduce the
> attacker's effective knowledge about it - hashing it, for example. That's
> certainly better than the original Netscape time+pid+ppid approach.
>
> Ultimately it's a question of your threat model. Does your model try to
> account for serious attacks by knowledgeable people with lots of resources?
> If not, how you seed your PRNG isn't something to lose a lot of sleep over.
> If so, then you'd be better off hiring crypto and security experts to vet
> your application.
I don't think we're concerned about serious high-resource attacks, after all,
we're not going to
use authentication but use ADH instead. I'm not sure if this is an attempt by
management to tick the encryption box or a serious attempt at supplying a useful
option. I'm trying to do the best I can within the constraints. The seed is the
toughest bit. We're supplying a library that won't have user interaction.
It also needs to run on about 10 different architectures (from NT through Unix
to MVS and AS400).
The only time I'll get user interaction is during installation <sigh>.
Thanks,
g.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
