Filippo Valsorda, a cryptography engineer and Go maintainer, writes about cryptography, security tools like age, and open source work.
HN commenters cite his post on quantum computing timelines to argue for deploying post-quantum crypto soon, and his age encryption advice.
> So what do you use for signing and encryption today when setting up a heterogeneous system like email or git?
I don't. For Email, quoting the aforementioned post[0]...
> Encrypting Email
> Don’t.
> Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.
> This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending?
> Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.
For signing commits in git, I'll quote Filippo[1]'s 'Sigining git commits considered harmful'[2] rant on Twitter.
> One of my issues with it is that it's marketed for a problem it does not solve (git metadata authentication and identity) and it's way suboptimal for the problem it solves (signed releases).
> I don't believe it works for that. You need at least a rebase (and key rotation, and…
> I'm sorry for your bad experiences with the Palemoon guys. You are obviously not who this software is meant for.
Who is it meant for if it's not meant for users? Are they intentionally trying to turn away certain people?
> I don't need or want sandboxing for my extensions
I think you'll find with all security, it's best to have the "principal of least privilege" https://en.wikipedia.org/wiki/Principle_of_least_privilege at all levels of software. The reason for this is because if something happens to exploit one area of your setup, the hope is that it will be stopped somewhere else.
> I can take care of my own sandboxing external to the browser profile instance.
As do I. I use multiple VLANs (network segregation), Virtual Machines, and other things in addition to browser profiles. Most people however do not. Software should be designed for "most people".
> And I don't want it either, because it makes them less flexible and powerful. XUL based extensions turn my browser into a power tool,
There's plenty of frameworks out there. Perhaps what you're trying to do shouldn't be a browser extension.
> Chrome is a toy.
Okay if you mean high performance web browser with a lot of market share that Mozilla must compete against in order to stay relevant?
> I don't know why you are upset, because the vast majority of the Internet agrees with you.
They do because I am right. I rarely say this as I do often like a good debate, however in this situation I will.
> Most people…
I also attended the Recurse Center years ago, but it didn’t quite click for me, which was surprising because everyone I spoke to had such positive experiences there. Even now, I find it hard to pinpoint exactly why it didn’t feel worthwhile for me.
Perhaps it was the location. New York City is expensive, and although I had enough savings to justify taking unpaid leave from work, many things seemed unreasonably priced. New Yorkers also have a reputation for being unfriendly, which added to my feeling of disconnect. Despite hearing glowing reviews from others, I didn’t quite mesh with the environment at Recurse Center, similar to how some visitors to the city might not feel entirely welcomed during certain encounters.
On the bright side, some of the residents and alumni [1] have become quite well-known in the tech industry. You might get lucky and find one of them around the space, which could lead to some really insightful conversations. During my time there, I had the chance to meet people like Robert Lefkowitz [2] and Filippo Valsorda [3], which was pretty cool. They definitely added some interesting perspectives to my experience.
[1] https://www.recurse.com/residents
[2] https://www.linkedin.com/in/r0ml
[3] https://filippo.io
That is probably true, when you live in a society where you probably still want some money for your work.
The greater implications of that might have something to do with how we get articles like "Software below the poverty line": https://staltz.com/software-below-the-poverty-line.html
Or maybe the revelations about how "well" supported the people who maintained Log4j were from the open source community: https://words.filippo.io/professional-maintainers/
Earlier this week, a severe RCE in a logging library called Log4j2 got everyone, from Apple to Minecraft. As of yesterday, the maintainer who patched the vulnerability had three sponsors on GitHub: Michael, Glenn, and Matt.
That's why it's hard to be angry with companies and people trying to get paid for their work, supported by various software licenses in one way or another. I do still mostly support open source in spirit, though doing that with my wallet on OpenCollective (or GitHub Sponsors or whatever) is also a good thing to do.
Indeed. And the readme and the usage output makes no mention of streaming, buffering, on-line, authentication, or anything related.
This is a potential security relevant behavior that most users-- who haven't written or analyzed tools like this-- would find surprising.
For those following along, I went and tested it-- since the behavior wasn't documented or clear from the code. If it encounters midstream corruption it truncates the output, exits with a non-zero return and prints some error text std stderr: "Error: chacha20poly1305: message authentication failed\n[ Did age not do what you expected? Could an error be more useful? Tell us: https://filippo.io/age/report ]"
If the input is truncated, it either does that-- or if the truncation is on a block boundary it prints "Error: unexpected EOF\n[ Did age not do what you expected? Could an error be more useful? Tell us: https://filippo.io/age/report ]" instead.
It's not a problem, but it should be documented.
> But if I recall, it seems that the age key file itself is 128 bits! Thus in the symmetric mode, Age provides only 128 bits of security. This is substandard, and in particular secure only until 2035 or so.
This is not the case. To meet NIST's Category 1 requirements, post-quantum cryptography "must require computational resources comparable to or greater than those required for key search on a block cipher with a 128-bit key (e.g. AES128)" [0]. It is therefore completely appropriate to pair any Category 1 post-quantum KEMs with 128-bit symmetric keys. See [1] for more details about post-quantum age. Symmetric passphrase age similarly is fine because it's the same as the post-quantum KEM case but without the KEM.
[0] https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria)
[1] https://words.filippo.io/dispatches/post-quantum-age/