Re: fun with nonces

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

Rich wrote:

Stefan Claas <pollux@tilde.club> wrote:

He does not need to send Alice the nonces, once he
arrived, because they both have a shared secret.
Alice and Bob can generate them by themselves, no
matter what timezone they are in and the nonces will
be random and can be re-generated with the same values

 
They cannot be simultaneously "random" and be capable of being
"re-generated with the same values".
 
At best, they are psudeo-random.  And, looking over the code, indeed,
they are generated from a psudeo-random generator, go's 'rand'.

 
It uses now xorshift128+ instead of math.rand, to have a  128bit
seed instead of 64bit.

 
And it is still psudeo-random.

 
And that is perfectly fine, unless of course someone here would show
me a better solution, for using nonces without transmitting them.

There is really no need for "shared secret nonces" given standard
encryption modes.  The 'nonce' (meaning: "used once" [1]) is present to
randomize a given use of a mode [2] under the same key and plaintext as
a prior use of the same mode/plaintext [3] under the same key.  The only
'security' required of the nonce is that eve not be able to predict any
given nonce in advance, which is why they are preferably derived from
true random sources or created by cryptography secure random number
generation algorithms (with a good true randomness seed).  But the
security of the encrypted data does not depend upon the actual nonce
being secret to Eve.  This is why they are transmitted in the clear at
the start of modes that use a nonce.

But going to great length to generate "secret" nonce's for use by Bob
and Alice is unnecessary.

You appear to be beginning to climb down the same rabbit hole that
Chris quite deeply entered when he was so overly concerned about the
IV/Nonce being in the clear as part of the protocol that Eve got to
examine some years back.


[1] https://www.merriam-webster.com/dictionary/nonce

[2] i.e.: CBC, CFB, CTR, etc)

[3] note that in many encrypted protocols there will often be some
constant plaintext in the underlying message such that without the
randomizing provided by the nonce, a known-plaintext attack can be
performed on those parts of the underlying message.