[TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

[Sophie Schmieg <[e-mail]>]

Random faults in ML-DSA can always leak single bits of the private key, but
this is a leak exists whether you use randomized or non-randomized
signatures, simply by hoping the fault messes with the rejection of
signatures with values outside of the limits. The more dangerous fault
would be resigning with the same value for y, which immediately leaks the
full private key, this is the same type of fault that EdDSA is in danger
of. However, different from EdDSA, the where private and public key could
be independently supplied (and therefore faulted) and the masking scalar
only depends on the message and the private key, ML-DSA's y depends on both
the private key and µ, which in turn depends on the message and the public
key. This means the only way to cause this fault attack is by faulting µ
in-between line 8 and 15 of the spec, and hoping that both signatures are
accepted at the same iteration of the rejection loop. That isn't to say
that deterministic signatures are not at a higher risk for fault attacks,
just that compared with EdDSA, this risk is substantially lower here, and I
do think that the argument that deterministic signatures lead to better
testability makes it defensible to use either mode of ML-DSA.

On Fri, Apr 10, 2026 at 1:02 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> On 10.04.26 20:39, Ilari Liusvaara wrote:
>
> > Furthermore, I would be much more concerned about "TEE" (especially
> > something like TDX or SEV) getting possessed by an attacker than side
> > channel attacks.
>
> Well, TEE is already possessed by an attacker. As per white paper of
> Confidential Computing Consortium (CCC) [0], cloud provider is your
> attacker. Industry giants like Microsoft and Google use the same
> attacker model. And if cloud provider is not your attacker, it is not
> clear to me who are you protecting against with TEE? and for what purpose?
>
> Attacks like BadRAM, TEE.fail and wiretap.fail have shown exploitation
> of side channels attacks to be practically feasible within 10 bucks.
> Since Intel and AMD continue to exclude side channel attacks, I believe
> the software design has to be more robust to protect against side
> channel attacks.
>
> Best regards,
>
> -Usama
>
> [0]
>
> https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC_outreach_whitepaper_updated_November_2022.pdf
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]