-----BEGIN PGP SIGNED MESSAGE-----
At 07:24 PM 6/27/00 +0100, Paul Crowley wrote:
>John Kelsey <[EMAIL PROTECTED]> writes:
...
>> A generalization of this idea is:
>>
>> S(K,len) is stream cipher output with key K and length of output
>> len. hash(X) is hash function output of same size as K. Key =
>> S(hash(passphrase),desired key length)
>I don't think I see how this is a generalisation; what are you
>identifying with "K" in my description? It's not the output from
>Panama after hashing the input; that's "Key" itself. It can't be
>the internal state before the blank pulls, that would make "hash(X)"
>a bad hash function, and I think if it were the internal state
>after the blank pulls then that would make "S(K,len)" a bad stream
>cipher. So I'm not sure that using Panama directly fits the model
>you describe.
The Panama engine can be used as either a stream cipher or a hash
function. What you're doing is:
a. Feeding in the input key material to Panama as a hash function.
b. Cranking it until it's ready to generate output.
c. Now, using Panama as a stream cipher, generating keystream which
you'll use as output key material.
The way to generalize this from your description to mine is:
a. X is the input key material.
b. K = hash(X) is the Panama engine's internal state after hashing
X.
c. S(K) is the output of the Panama engine.
I wasn't implying that you'd use Panama to generate a hash, and then
input the hash as a key and use the stream cipher; just that you'd
use both hash function and stream cipher functionality from the same
component with Panama, but could do something very similar with (say)
SHA1 and triple-DES in counter-mode.
...
>I've been trying to think about how you might use a primitive like
>Panama in combination with real entropy sources to provide a
>/dev/random type thing, but I've hit a problem in how to think about
>it. For some appropriate value of N based on the computational
>resources of your attacker, you have to take in at least N bits of
>entropy before generating a single bit of output, or fall foul of an
>iterative guessing attack. The problem I have is that once you've
>got N bits of entropy, you really don't need any more! You could
>merrily ignore all the rest of the entropy at your disposal, and (if
>your components are secure) your attacker will never be any better
>off than they were when you first started producing output.
Right. This runs into two problems:
a. What do you do if your internal state is compromised, either by
never reaching the amount of entropy you need or by some kind of
screw-up in your implementation or something?
b. You are then resting all of your cryptographic keys forevermore
on this one cryptographic primitive, so you'll want to be quite sure
you're using something you trust, and you have to accept that you
can't get any more security than the design strength of your
primitive.
>Given this, what theory can you use to determine if you're using
>those subsequent bits of entropy appropriately?
Our Yarrow-160 paper is at http://www.counterpane.com, and it gives
one approach to this. Our approach to the problem you pose is to
have two hash contexts, called the slow and fast pool. Entropy
inputs are somehow split between them, so that each input goes to
only one pool. The fast pool becomes ``full'' fairly quickly; if the
entropy estimates we're working with are accurate, then it should
give about 160 bits of entropy (assuming SHA1), and this is used to
rekey a triple-DES context running in counter mode, which generates
all outputs. The slow pool becomes full far more slowly, and should
have an unguessable state by the time it becomes full even if we're
really overestimating entropy from some of our input sources.
Our more recent work along these lines is a bit more elegant, but
basically the same--we split it into a fast and slow pool, and reseed
the generator whenever either pool is full.
>--
> __
>\/ o\ [EMAIL PROTECTED] *NOTE NEW EMAIL ADDRESS* \ /
>/\__/ Paul Crowley http://www.cluefactory.org.uk/paul/ /~\
- --John Kelsey, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 Int. for non-commercial use
<http://www.pgpinternational.com>
Comment: foo
iQCVAwUBOVrPKCZv+/Ry/LrBAQE9swQAt4xHbYG2Ufe1JwJg2Y7RYVy3rgcGwS1x
e7zwoX1MCWczoEHYBkVjw5a1ZZPQDeB92sJbFxvD6tEvf6nYj1ydz201hcJBVu+V
HdVfcuOmzx1YGQ0ylikQvu+xqmfDgbTJUQtFpEKqwwHLz8LeEY83OBEwU0sHSmnU
k7RbuQMT1cA=
=bDdH
-----END PGP SIGNATURE-----
