[gnutls-devel] GnuTLS | groups: represent hybrid groups with an array of IDs (!1904)

[Read-only notification of GnuTLS library development activities]

Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1904 was reviewed by Alexander Sosedkin

--
  
Alexander Sosedkin commented on a discussion on lib/algorithms.h: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250479843

 >  #endif
 >  
 > +#define IS_GROUP_HYBRID(group) ((group)->ids[0] != GNUTLS_GROUP_INVALID)

Right. I don't think it's guaranteed to end up in bss, but it looks like zero-initialization is guaranteed.

--
  
Alexander Sosedkin commented on a discussion on lib/algorithms/groups.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904#note_2250479859

 > +}
 > +
 > +static inline bool group_is_supported(const gnutls_group_entry_st *group)

I would argue it's not. Since X25519-MLKEM768 is supposed to be stronger than X25519 alone, I can see a case where X25519 ends up broken, but X25519-MLKEM768 is not. Conversely, the inability to turn on X25519-MLKEM768 without turning on X25519 means a downgrade is always allowed, so one wouldn't be able to force use of hybrid. I think hybrid groups should be configurable independently from the underlying groups.


-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1904
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20241210/c6a84f10/attachment.html>