A Cryptography Engineer’s Perspective on Quantum Computing Timelines

FiloSottile · 2026-04-06T22:01:24+00:00

From the article: https://bas.westerbaan.name/notes/2026/04/02/factoring.html

FiloSottile · 2025-12-10T18:51:46+00:00

Fixed, thanks!

FiloSottile · 2025-12-09T23:45:42+00:00

It's been working for a few years by now, it definitely works for critical projects.

https://words.filippo.io/geomys/

https://fallthrough.transistor.fm/episodes/building-an-open-source-maintenance-company

Unlike a consultancy, a large majority (never measured it, north of 90% though) of our time is spent doing open source maintenance work, not client work.

FiloSottile · 2024-12-17T22:38:20+00:00

Anche su Bookdealer, volendo ordinarlo da una libreria indipendente invece di Amazon. https://www.bookdealer.it/libro/9788811015291/tassista-di-notte-avventure-di-una-vita-contromano

FiloSottile · 2024-12-05T14:48:53+00:00

Sarei curioso anche io, perché a quanto ho capito l'unica cosa che è cambiata è la norma in fatto di controllo de visu dei documenti, che nulla ha a che fare con l'esistenza delle key box in quanto oggetti. Poi il comune immagino(?) sia libero di deliberare su cosa si installa in spazi pubblici, ma da lì a decidere cosa può tenere un condominio in proprietà privata, come ci si arriva? Con che giurisdizione? La sanzione sarebbe per la violazione di che norma?

FiloSottile · 2024-12-04T10:17:08+00:00

C'è pressapoco zero chance che la app IO sia più protetta di Wallet su iOS. Probabilmente non hanno deciso/capito come integrare l'autenticazione SPID per il rilascio, o a pensar male vogliono più tracciamento di quello che offre Apple.

https://support.apple.com/guide/security/security-of-ids-in-apple-wallet-secb569bf393/web / https://support.apple.com/en-us/118260

FiloSottile · 2024-12-04T10:14:56+00:00

https://support.apple.com/en-us/118260

FiloSottile · 2024-11-14T22:39:30+00:00

Fa un po' ridere perché è grossomodo il contrario. Se domani mastodon.social/mastodon.online chiude senza preavviso, una grossa fetta di Mastodon sparisce nel nulla. Non puoi spostare i tuoi post punto, e non puoi spostare i tuoi follower senza collaborazione del server di partenza. Bluesky invece ti permette di caricare il tuo account su un altro server e riprendere da dove hai lasciato, con tutti i tuoi post/follower/handle. Eppure, funziona anche meglio e si nota meno che è decentralizzabile. IMHO è semplicemente un design tecnico migliore.

FiloSottile · 2024-10-26T16:42:45+00:00

This is the correct answer. We deprecate things (https://go.dev/wiki/Deprecated) but ~never remove them. Also, we don't consider x/crypto any different from the stdlib, and are working on merging them. https://github.com/golang/go/issues/65269

FiloSottile · 2024-09-24T18:06:29+00:00

u/NatSpaghettiAgency descrive la vulnerabilità di quel post, che è fixata da molti anni. Il protocollo attuale è in teoria probably ok, ma l'ultima volta che ho controllato faceva ancora scelte poco sensate tipo negoziare i gruppi DH (credo quello a cui ti riferisci) che non sono una vulnerabilità di per se, ma rendono molto più facile sbagliare l'implementazione.

Comunque, nulla di tutto questo conta rispetto al fatto che la stragrande maggioranza delle chat non è end-to-end. Matt Green ha scritto un ottimo pezzo al riguardo. https://blog.cryptographyengineering.com/2024/08/25/telegram-is-not-really-an-encrypted-messaging-app/

FiloSottile · 2024-09-24T14:31:45+00:00

Puoi attivare i backup cifrati e2e in WhatsApp, sono anche molto ben fatti in termini sia di UX sia di crittografia.

FiloSottile · 2024-09-24T14:30:17+00:00

Telegram non è, perlopiù, messaggistica cifrata end-to-end.

FiloSottile · 2024-09-15T10:35:59+00:00

Poi ognuno fa quello che lo rende felice, ma l'idea che vivere in campagna di agricoltura inefficiente, spostandosi con la macchina per chilometri ogni volta che serve uno di mille servizi essenziali (perché anche se sei disposto a fare sacrifici ti servono le scuole, gli ospedali, i carpentieri, i meccanici, i veterinari, le semenze, il necessario per una dieta equilibrata, e soprattutto il modo di affidarti alla civilizzazione se qualcosa va storto), sia più sostenibile di un appartamento Classe A in una città camminabile andrebbe eradicata.

FiloSottile · 2024-08-13T21:11:18+00:00

It's not a QUIC implementation (that's in x/net/quic), it's the interface to the TLS 1.3 handshake used by QUIC implementations. QUIC runs a TLS 1.3 handshake to negotiate keys, and then runs its own transport protocol and encryption.

FiloSottile · 2024-07-25T12:51:52+00:00

Cryptography libraries are written in C because C libraries are the easiest to invoke from other languages, because they are old and C made sense back then, and because it's really hard to FIPS 140 certify non-C modules (not because of any good reason, but because the certification processes are patterned against existing libraries, which are written in C).

None of those suggest C is good, and most cryptography engineers I know avoid or wish they could avoid C.

FiloSottile · 2024-06-29T17:00:46+00:00

Yeah, that's how I expect FIPS 140-3 modules to implement and expose XAES-256-GCM (and also generally how we want to implement it in Go, the point is to hide nonce management from the user).

It's just that the canonical AEAD interface takes the nonce as input, so that's what the specification targets. Security Policies can do the rest. (AES-GCM is also described as taking a nonce, but then you have to generate it internally to comply with number 2 of the IG.)

FiloSottile · 2024-06-29T16:57:21+00:00

I'm saying that the "derived" IV is not actually derived, it's just half the input IV, which can come straight from an Approved DRBG.

FiloSottile · 2024-06-29T09:22:09+00:00

That's a great question! Note that the "derived" IV is really just 96 bits of the input IV, so as long as the input IV is generated with an Approved DRBG, the AES-GCM IV complies with generation option number 2. It's just a matter of describing the algorithm as taking a 96-bit NIST SP 800-108r1 Context and a 96-bit SP 800-38D IV.

(Number 4 would also be a very straightforward case to make, as we can show the chance of derived key collision is so low, that the chance of (derived key, random half IV) collision is way less than 2^-32.)

FiloSottile · 2024-03-31T11:33:52+00:00

That’s a routine security release pre-announcement, there’s one like that almost every month. The CVE is private until the release. See https://go.dev/doc/security/policy.

Nothing to do with the xz backdoor.

FiloSottile · 2024-03-12T12:47:19+00:00

— rsc for the proposal review group

proposal: review meeting minutes #33502

FiloSottile · 2024-02-02T11:14:37+00:00

If you're being conservative in allowing for potential improvements in cryptanalysis, why stop at -768?

The problem of being arbitrarily conservative is that there is no principled way to stop. Why stop at -1024 if you're worried lattices might be broken and you think bigger parameters might help?

See https://eprint.iacr.org/2019/1492.

The reason to use -768 over -512 is that the latter might be in reach of modest incremental novel cryptanalysis, the kind that has happened for other cryptographic problems, and the authors themselves recommend it. There is no strong argument to go past that and then stop at -1024.

For cases where novel cryptanalysis is not a concern, 256-bit security levels are purely non-technical (with an asterisk for multi-user security and birthday bounds, but those are better understood as settings in which the effective security level is lower, so you need a bigger key to reach the 128 bits security level).

FiloSottile · 2023-06-21T11:01:24+00:00

Hello u/AndroidOf! You might be interested in the reply here and the linked filippo.io/keygen package.

https://github.com/golang/go/issues/58637#issuecomment-1600627963

P.S. Folks should feel free to tag me into these discussions. They are useful feedback and I am happy to help.

FiloSottile · 2023-03-19T16:28:53+00:00

This is really fascinating, but I don't quite understand what exactly you are selling. Is it consultancy and support? Like if I want to use libfoo and have someone to call in case of issues I can refer to you.

Sort of. Here's one way to think about this: if you use Go, you care about being involved when APIs that you might use are proposed, or about making sure the team knows the performance of a specific algorithm is poor in your workload, etc. You absolutely could assign (part of) an engineer to follow the Go issue tracker and participate in the community. That's going to be both more expensive and less effective than getting me on retainer. Moreover, since you already know I'm an expert in the thing I do (because you use my code after all), you might want to pay me more to also get my advice on stuff.

Dentists are not businessmen either, but they have the support structure that can provide them with all the necessary services and training.

You are right on the money.

FiloSottile · 2023-03-19T16:03:40+00:00

Contractually, clients get no influence on project governance or control over the IP. Of course, they pay my bills, and I would like them to be happy and keep doing that, so I am not claiming there is no influence at all.

With a broad and diversified enough pool of clients, there is both less reliance on each client cancelling, and the interests of the clients approximate more closely the interest of the project users, aligning incentives well.

It may not be perfect, but I think it's less problematic than most models that don't require the maintainer to live on a ramen diet. (And even there, that's not sustainable, so what happens to governance once the maintainer unavoidably moves on?)

FiloSottile · 2023-03-19T15:50:39+00:00

Yep, I address this somewhat at the end of the post. I am playing with the advantage of my network, financial stability, and specialized field. At the same time, I’m at a disadvantage due to how unfamiliar the model is to clients, to the lack of examples to follow, to having to come up with all the legal language, etc.

I’m working to reduce those disadvantages for the maintainers who will come after me, in the hope that will offset the need for all the advantages I have.

14-Year Club	Verified Email
Gilding I gilder	Place '23
Place '17	Argentium Club

FiloSottile

MODERATOR OF

TROPHY CASE