[MLS] Re: Thoughts on draft-ietf-mls-pq-ciphersuites

[Rohan Mahy <[e-mail]>]

Hi Soatok,

Yes, that helps, thank you. I believe most ARMv7 processors had AES
hardware acceleration. The good news is that we can check these platforms.

thanks,
-rohan


On Sat, Apr 11, 2026 at 6:42 AM Soatok Dreamseeker <[e-mail]>
wrote:

> Sure.
>
> The main considerations are legacy smartphones (ARMv7-based), Raspberry Pi
> 4 and older devices, older Arduino kits (I don't know if the newer ones
> support hardware AES, but many of my friends do a lot of IoT stuff and I
> know they'll care about this).
>
> Another area of interest for me is scripting languages without hardware
> AES and no access to low-level assembly (e.g., PHP without ext-openssl and
> no FFI or extension permissions).
>
> There is a very long tail of legacy hardware and software and I don't want
> any of that to be left behind in the migration to post-quantum, and I'm not
> limiting MLS deployments on the Fediverse to smartphone apps. If folks want
> to write their own chatbots and talk to it through WordPress plugins, I
> want to make their workflow possible.
>
> I hope that adds some color to the users I'm trying to help.
>
> On Sat, Apr 11, 2026 at 12:21 AM Rohan Mahy <[e-mail]> wrote:
>
>> Hi Soatok,
>> Thanks for joining the discussion.
>>
>> Regarding the ciphersuite "level" being 128 or 192, many have argued that
>> the number is largely irrelevant and we wouldn't have included it if we
>> rewrote the MLS today. It shouldn't have any meaningful difference to who
>> implements or deploys it. Since ML-DSA-44 targets NIST level 2 instead of
>> level 3, I would make it
>> MLS_128_MLKEM768X25519_CHACHA20POLY1305_SHA384_MLDSA44.
>>
>> A non-CNSA 2.0 reason to use PQ signatures is potentially very
>> interesting. Could you please elaborate on the signature algorithm
>> discussions about the ML-DSA-44 vs. Ed25519? What kind of key lifetimes
>> were you considering?
>>
>> Finally, I wanted to ask about this sentence:
>> "I am implementing this in languages and runtimes without access to a
>> native cryptography implementations or raw Assembly, and may be running on
>> hardware without hardware-accelerated AES,"
>>
>> Could you talk a bit about the hardware without accelerated AES? I
>> developed on sub $6 SoCs 12 years ago that have AES acceleration, so I am
>> somewhat surprised by the argument.
>>
>> thanks,
>> -rohan
>>
>>
>> On Fri, 10 Apr 2026, 17:11 Soatok Dreamseeker, <[e-mail]>
>> wrote:
>>
>>> Good afternoon,
>>>
>>> I'm working on a few projects that intersect with MLS in interesting
>>> ways. The most pertinent of which is a key transparency project for the
>>> Fediverse which I hope will enable the secure bootstrapping of public keys
>>> for use in end-to-end encryption (which should, in turn, use MLS).
>>>
>>> You can learn about this project here:
>>>
>>> 1. https://publickey.directory
>>> 2.
>>> https://soatok.blog/category/technology/open-source/fediverse-e2ee-project/
>>>
>>> The actual E2EE on ActivityPub folks (mostly W3C or W3C-affiliated) are
>>> coordinating their efforts on GitHub. In January, I opened a discussion
>>> recommending specific MLS ciphersuites here:
>>> https://github.com/swicg/activitypub-e2ee/issues/59
>>>
>>> In recent weeks, Google and Cloudflare have both announced a 2029
>>> timeline to adopt post-quantum cryptography everywhere. After talking with
>>> some folks at RWC 2026, and seeing those announcements, I'm planning to
>>> update my proposal to migrate to ML-DSA-44 instead of Ed25519 for my key
>>> transparency work. Ideally, we'd also be able to use ML-DSA-44 for the
>>> ActivityPub E2EE work as well.
>>>
>>> However, the current draft is incompatible with my goals. Notably:
>>>
>>> 1. No ChaCha20-Poly1305 ciphersuites
>>> 2. ML-DSA-87 is in the current draft, but -44 is not.
>>>
>>> I specifically need ChaPoly because I am implementing this in languages
>>> and runtimes without access to a native cryptography implementations or raw
>>> Assembly, and may be running on hardware without hardware-accelerated AES,
>>> and I trust myself to implement ChaCha20 and Poly1305 in constant-time, but
>>> I am worried about JIT compilers and VM optimizations undermining my
>>> attempts to make the AES S-box constant-time.
>>>
>>> I recall there were some concerns over the ML-KEM-512 parameter set
>>> being too close to the security margin for comfort, which motivated the
>>> prioritization of ML-KEM-768. A similar concern was not present for ML-DSA,
>>> and the -44 parameter set is considered secure with sufficient margin to
>>> not invite the same kind of bikeshedding discussions that ML-KEM-512
>>> provoked. For this reason, I do not feel that the -65 or -87 security
>>> levels are required for my purposes, and  therefore cannot the bandwidth
>>> costs for the larger parameter sets.
>>>
>>> I am ambivalent about hash functions. SHA-256, SHA-384, SHA-512,
>>> BLAKE2b, BLAKE3, SHA3-256, SHA3-384, SHA3-512, KangarooTwelve. These are
>>> all secure enough for my purposes. Given the widespread availability of
>>> SHA2, my default choice will be SHA512 or SHA384 (since they're both fast
>>> on 64-bit hardware).
>>>
>>> I acknowledge that asking for the draft be expanded to include a few
>>> additional options risks a combinatorial explosion of combinations, so I
>>> will instead ask for one ciphersuite be added to the list that includes
>>> both ChaCha20-Poly1305 and ML-DSA-44. That is to say:
>>>
>>> MLS_X_MLKEM768X25519_CHACHA20POLY1305_SHA384_MLDSA44
>>>
>>> Where X is either 128 (conservative) or 192 (which seems more
>>> appropriate to me, given that the security of the KEM is >= 192 bits, the
>>> AEAD is 256 bits, and the hash function's birthday bound is about 192 bits).
>>>
>>> Thanks for taking the time to consider my request.
>>>
>>> Kind regards,
>>> Soatok
>>> _______________________________________________
>>> MLS mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>