What do LLMs mean for GnuPG?

Hakun_the_eril hakuntheeril at gmail.com
Mon Mar 30 15:27:35 CEST 2026


I agree that actual code for ciphers must be 100% written by humans, and
reviewed by humans,-  but for everything else it can be a OK tool.


man. 30. mars 2026, 13:01 skrev Robert J. Hansen via Gnupg-users <
gnupg-users at gnupg.org>:

> > I am a user of tools like Cursor,- and my personal opinion is that LMM
> > is not perfect. But for those who cannot program because  of
> > neurological conditions, it is a valuable tool.
>
> As a hacker who deals with mental illness, I am massively in favor of
> creating a community that is welcoming to people with psychological,
> psychiatric, and/or neurological troubles. But I draw the line at
> thinking we should lower our professional standards to accommodate these
> conditions.
>
> I do not believe LLMs should be authoring security-sensitive code, ever.
>
> > If the programming follows programming standards like  PEP 8, |rustfmt|,
> > clippy etc..
>
> None of these verify quality code. The version of pwgen that Claude.ai
> created passed the normal clippy checks.
>
> > tested against Wycheproof test vectors, RFC 5639, and BSI specifications
>
> Having implemented more cryptographic algorithms in my life than I ever
> want to think about, "it passes the test vectors" does not create in me
> very much faith in the overall quality of the implementation.
>
> Circa 2008 at USENIX/EVT we gave a round of applause to a team of nerds
> who had implemented AES in Java, and given rigorous Floyd-Hoare proofs
> of correctness. It took them two and a half years of work.
>
> I once had to implement a highly reliable Galois counter mode. I yearned
> for the sweet release of death.
>
> > But,- who can write 100% perfect code ?
>
> It's hard but it's been done. The provably-correct AES implementation
> comes to mind, as does the RSRE VIPER processor. The IBM System 360
> minicomputers that controlled the Space Shuttle never suffered a
> life-threatening bug, ever: even as _Challenger_ and _Columbia_ came
> apart the HAL/S software stack continued functioning correctly.
>
> https://en.wikipedia.org/wiki/VIPER_microprocessor
> https://en.wikipedia.org/wiki/HAL/S
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260330/53420565/attachment.html>


More information about the Gnupg-users mailing list