On Tue, Jun 9, 2026 at 12:12 PM Bas Westerbaan <bas=
[email protected]> wrote:
> - The idea that the server can use the client random to protect against
>> side-channel attacks is obviously wrong.
>>
>
> Which is not claimed. Client randomness is mentioned as we're also
> concerned with client authentication.
>
> - The server random and the ML-DSA rnd value are used in different parts
>> of the input and could affect side-channel behavior in different ways.
>
>
> For those reading along, the only place ML-DSA rnd and the input message M
> is used, is in the computation of rho'':
>
> rho'' = H(K || rnd || H((tr) || 0 || len(ctx) || ctx || M))
>
> M contains the transcript hash which includes the client/server randomness.
>
> - The server random and the ML-DSA rnd value might be generated by
>> completely different random number generators with different quality. It
>> is not clear that the ML-DSA rnd can be replaced by server random.
>>
> This PR should not be merged in its current form. It makes very strong
>> statements ("do not apply") with little motivation. I think more analysis
>> would be needed even to support weaker statements.
>>
> The TLS standard requires a good source of randomness. Indeed, its
> security analysis has several *very strong statements *(eg. replay
> protection) which would need to be revisited if we were to put that
> requirement into question.
>
I don't have an opinion on ML-DSA, but is strong randomness rather than
uniqueness a requirement for replay protection?
-Ekr
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
