FiloSottile

I mean, most users don't root-install, but anyway the GUI application can drop a different age binary higher on the user's PATH. Or change their shell. Or a million other things.

There really isn't a point to defending against code running unsandboxed on a single-user machine.

Yes, and they can also replace the age binary with one that uploads the password as soon as you type it. There is no meaningful security boundary to defend.

We implemented support for password-encrypted keys for the cases where you store the key file in, say, Dropbox.

We designed the plugin protocol (https://hackmd.io/@str4d/age-plugin-spec) and generally the age recipient/identity structure specifically to enable the use of hardware or remote keys!

For example, https://github.com/str4d/age-plugin-yubikey makes it very easy to use PIV tokens, including YubiKeys, with age. (Well, for now with rage, since plugin support is coming in age v1.1.0.)

I argue against password-protecting keys by default because, unlike using hardware tokens, it doesn't protect against many threat models.

Your network is MitM’d by some incompetently operated security product. https://github.com/FiloSottile/age/issues/370

That’s not really what the issue with the tls-sni challenge was.

How that challenge worked was that the CA would give you a certificate for a fictitious name (say, abc123.acme-challenge.invalid) and you had to present it from the host when asked for that name by the client (the CA) though SNI.

Many hosts that share IPs between customers also let those customers upload their own certificates. The attack just involved uploading a challenge certificate for a colocated site, and letting the host serve it as expected. Even if the host _did_ check that the name on the cert was not the name of another customer (which is itself sometimes impossible), and even if the target site was not abandoned, and even if it had correctly functioning HTTPS, these are fictitious made up names, so the attack would still work.

It involved no ignoring the Host header, or really any misconfiguration, that’s why it requires rolling to tls-alpn.

falcond is CrowdStrike’s endpoint antivirus thingy, not device management.

As usual, antivirus is an exercise in trading performance for increased attack surface (and compliance).

Why do TLS issues need to get patched faster than any other security vulnerability? Or said another way, why is a slow deploy cycle ok for non-TLS vulnerabilities?

So far I haven’t heard any good reason. TLS issues are not more common than other components, at least in Go. Maybe people are just a little traumatized by how often other TLS stacks broke in the past?

We maintain two Go versions with very conservative patch releases specifically to allow quick deployment of critical and security fixes. If that still doesn’t allow for quick patching of security vulnerabilities, it sounds like a process issue (on our side or on the application side), not a reason to make TLS special.

Can you open an issue elaborating on this? I’d expect the ability to disable broken cipher suites to be enough to work around this, and that is not changing. (What’s going away is controlling the order in which enabled cipher suites are picked.)

That’s generally something that might be desirable for a number of reasons but it’s an extremely delicate change because of how stdlib packages import each other, and how types from x/ repos vendored back into the stdlib are not compatible with the original ones. You quickly have to ask questions like “do we let the main module upgrade the version of x/ repos used by the stdlib?” Maybe eventually we’ll find a way to do this cleanly and decide to do it, but large changes like this take time.

My first intuition for how to do that would be to only enable one cipher suite at a time, which still works with this change. Still, do feel welcome to open an issue, I can’t promise any specific outcome but we’ll look at it.

I’ll mention that we had to ignore the requirements of diagnostic and scanning tools in the past, and you might be better served by a fork like BoGo from the BoringSSL test suite. Fundamentally, what an application wants (“make a secure connection”) is at odds with what a test tool wants (“make a connection potentially broken in one of a thousand different ways, and tell me how it went”).

If you encounter such a program that requires PreferServerCipherSuites to run correctly, please open an issue and we’ll look into it as a potential regression.

More in general, it’s unavoidable for packages that implement living protocols like TLS and HTTP to have a higher level concept of backwards compatibility: if the wire behavior of the package were to never change, Go would soon stop working with most of the ecosystem, and wouldn’t implement the likes of HTTP/2 and TLS 1.3. Many standard libraries went that way, and ended up less useful and safe.

_o/ the summary is close, but there's a key detail that might have not come across: you can still enable and disable TLS 1.0-1.2 cipher suites. What we take care of is the preference order in which they are picked.

The two scenarios you present aren’t really affected by this change. However, I want to address the latter: if we fail to make it possible for Go applications to promptly roll out software security fixes, being able to change TLS configuration will be barely a band-aid. I actually can’t remember the last time that would have helped secure a Go application faster.

I don’t trust Facebook’s intentions, but WhatsApp has demonstrated consistency in bringing encryption to users.

The ProPublica article that the ones you saw are based on was flawed, and has been updated. https://twitter.com/propublica/status/1436054877663375372

Thank you for the friction log! This kind of feedback is extremely valuable!

1. It sounds like you were passing an identity file to --recipients-file. We do support using identity files with --encrypt, but you need to pass it to --identity. We can make the error message more helpful when we notice this is happening.

2. Armoring has a lot of space overhead, and most applications don't need it. (age is not for encrypting messages and emails!)

3. It's now in Homebrew Core :)

4. :D

The YubiKey plugin uses the PIV applet with P-256 keys, not RSA. FIPS 140 compliance is not a goal.

You can find them in the linked specification/design document, but I don’t really believe in putting cryptographic primitives front and center on user facing documentation.

First, the average user doesn’t actually care that much. Picking algorithms is my job, not theirs. They want to get their task done, so what I need to tell them is what the tool does and what are the security properties, not how it works.

Second, the choice of primitives is a relatively small part of cryptographic design. How you compose them and how it addresses a real use case matters much more. I usually get suspicious when I read “uses AES-256” in marketing copy because, like, it doesn’t tell me _how_ it’s used, and doesn’t seem to think it’s important.

It decrypts the per-file symmetric key on the YubiKey, the same way the PGP applet works.

Right?! I’m as surprised as you are.

We did eventually add support for encrypted native key files, despite my skepticism around what threat models it actually addresses. You can now pass to “age -d -i” a file encrypted with “age -p”.

Not having a default keychain location though is a deliberate decision that’s here to stay. age keys are application-specific keys, not universal personal identities. We want to avoid implicit state and make rotation and compartmentalization as easy as possible.

That is mostly already the case, you can invoke the extractors through the Python API or through the CLI and do the download yourself.

Extractors regularly require custom logic, so they can’t be described in anything else than a programming language.

Those are just the changes to the language! Many releases have none at all. Keep scrolling for a lot of improvements to the toolchain and standard library, including a couple security changes that might cause necessary behavior changes.

Good news, everyone!

https://github.com/FiloSottile/age/commit/d164fef036a2d19280...

It will be in the next release candidate.

> now I guess you're gonna get a lawyer threat letter to take down the whole blogpost because you've revealed private conversations without both parties' consent?

Absent any NDA or other contract, there is nothing requiring the other party’s consent to publish correspondence in the US.

I think we might have different ideas of the purpose of RFCs, but I don't expect end users to read them. What I'm saying is that RFC 8032 already defines a binary encoding for Ed25519 keys (the octet strings you've found). How to encode a binary string in text is IMHO orthogonal, and has nothing to do with Ed25519. Similarly, PKIX definex binary DER encodings, and PEM defines how to encode DER as text.

DER : PEM = Ed25519 binary encoding : Base64

I'd argue the RFC is already there and it's RFC 8032, which defines "32 bytes string" <-> "public key" and "32 bytes string" <-> "private key" APIs.

Then you can use your preferred format to serialize a 32 bytes string if you need a text-safe encoding. (If you don't you're done!) For example, you can use RFC 4648.

I am positive every language has Base64 code, and if there's an Ed25519 library out there that can't accept 32 byte strings we should talk to the author because it's broken as it doesn't implement RFC 8032.

What else would a serialization RFC say, that is not already said in RFC 8032? Deciding that keys are encoded with Base64 and not with, say, hex seems like a weird thing to force on people.

If there's a language that doesn't take 32 byte strings and give you an Ed25519 public key or private key, please do point me to it and I will message the maintainer. We're basically all on the same Slack :)

Came here to say this. Please don't use PKIX, ASN.1, and Base64-of-DER-without-PEM-headers for Ed25519. Those are all extra complexity from protocols that were misguidedly built with runtime agility, or from a different time in cryptography engineering in which we really felt the need to put dynamic types on everything. [0][1]

An Ed25519 public key is a 32 bytes sequence. An Ed25519 private key (called seed in crypto/ed25519 for unfortunate historical standardization reasons) is a 32 byte sequence. That's it.

Here they are encoded in Base64.

    public key: 5uW7anEGF1nIjGfp5pS2kiN0cn2mGYkuSa+TCBoFIbQ=
    private key: shhKyGTvTeLjXGDCjEQgHRA7ps3LRNNfoO5S714kinU=

age [2] similarly uses Curve25519 keys encoded with Bech32 to make them easier to copy-paste and read aloud. Look how nice they look compared to PKIX blobs!

    $ age-keygen
    # created: 2021-04-23T12:31:14-04:00
    # public key: age1gek0nrawzg9fhkrzcmt4ql7au0n6hwflz7lqqc8wwcvefn2vssgsa4uulp
    AGE-SECRET-KEY-19JFPFAY2DF3HJP5DFGVSY4A4G4YSRHG4ZCJMKNC5MFD9C9ZN5LCSG8VTDL 

I'll think about how to make the crypto/ed25519 godoc point people in the right direction once Go 1.17 enters feature freeze.

[0] https://www.imperialviolet.org/2016/05/16/agility.html

[1] https://buttondown.email/cryptography-dispatches/archive/cry...

[2] https://github.com/FiloSottile/age

Is the cryptography protocol documented anywhere?

The link on your website under the end-to-end heading leads to the Privacy Policy, that only mentions "XChaCha20-Poly1305-IETF & Argon2" which is far from enough details, especially for a closed source app with no audits.

From the names it sounds like you use libsodium, which is good, but it doesn't make rolling your own protocol safe.

dang, just so we are clear, are you saying my use of a technical term of my own field which I prefer, and which I definitely didn't come up with (it's on the Wikipedia page), in a newsletter I did not submit to HN, was a provocation and bait to start a flamewar (to which I was careful not to participate until now, even if there are some pitiful arguments in this thread)?

My position is that this looks like a backdoor but there is no way to know for sure, and I stand by it. If you find it too nuanced that's ok.