Hi Guilin, for the sake for clarity; I'm not a cryptographer, though I'd tought IT Security for serveral years (at the Frankfurt University of Applied Sciences - until my retirement) and I extend D.J. Bernstein's software to be usable in the 21st century (see footer).
Am Samstag, dem 11.07.2026 um 12:33 +0000 schrieb Wang Guilin:
>
>
> Interesting topic!
>
> As for a bad NRG, just taking m=NRG () could help attackers. Also, if
> m is a good randomness, hashing or not hashing does not matter.
>
> So, is it poissble that hashing, m'=H(m) or H(m||nonce), will bring
> some new attacks or weaknesses that not applicable to no hashing,
> m=NRG ()?
>
> By assuming that H is secure, it seems possible to prove that hashing
> is more secure or at least secure as not hashing, at the cost of
> running H and lost of some entropy in m.
Let's try to put some systematic approach on that issue:
1. We have a PRNG as given by the system or as part of the TLS spec.
Its output delivers a 'm' (according to John: m <- {0,1}^256)
2. We have the secret key exchange based on ML-KEM according to the
given draft using 'm'. [1]
3. The Client starts with generating a public key and secret key
('pkey_c', 'skey_c'). The Client sends the 'pkey_c' in its HELO message
to the server as KeyShareEntry and also telling the ML-KEM Group
parameter as given in [1]. Details follow RFC 8446 sect. 4.8. [2]
4. The Server now constructs its Server HELO message and sends it as:
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
)
The 'server_share' is derived from 'm' and the 'pkey_c' used as
encapsulation key 'ek'.
Transmitted 'server_share' = ML-KEM.Encaps_internal(ek,𝑚) =>
cipher_text 'ct' [3]
5. IMHO, I don't see an additional hashing of 'm' in [3].
6. Now, the crucial questions are:
a) Should we trust our own PRNG (m = PRNG())? Answer is: Yes we should,
otherwise many other things may be broken too, but probably has no
directly measurable impact.
b) Can we trust our PRNG? Answer is: No, the TLS (1.3) algorithms are
constructed such, that each key derivation step tries to mitigate
previous errors/failures while collecting entropy => minimal trust.
c) Can we judge the quality of the PRNG (and its result)? Here, we have
to consider important merits (of 'm'):
- entropy (can be validated, compression),
- randomness and uniqueness (almost impossible to tell),
- algebraic structure (difficult, AIC).
7. Hashing 'm' either as m = H(m) or m = H(m||nonce) may be valid
choices. Remember, the transmitted value of 'm' belongs to the Server
(only, and should be unique for any transaction) but the Client has no
way to validate its quality. It has to be trusted (TOFU).
8. Hashing may reduce entropy but using a qualified hash function has
little impact on randomness. Rather, based on its none-injective
operation, it will destroy any algebraic useable contents of 'm', even
if the same (manipulated PRNG) is used to generate different values of
'm' (and having a reproducable algebraic content).
9. Since ML-KEM.Encaps_internal(ek,𝑚) => ct (encapsulated
shared_secret) is a bi-jective operation, a potential underpinning
algebraic content of 'm' is preserved, can be reconstructed and used,
since 'ek' is known (and in cleartext transmitted).
Hope that helps and reflects the current situation precisely.
Otherwise, correct me. The current draft should try to describe its
core ingredients without referencing too much external sources, if
published anyhow, Given the result of the previous discussions, this
however becomes unlikely (IMHO).
Regards.
--eh.
PS: I was an early adopter of TLS 1.3 in ucspi-ssl.
References:
[1] https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.txt
[2] https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8
[3] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
> Guilin
--
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 36553F7F9C58D1CC
PGP key-fingerprint: 950B 5555 0B08 5A2A 1C00 9594 3655 3F7F 9C58 D1CC
signature.asc
Description: This is a digitally signed message part
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
