[nullc]

NSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa...).

There are applications where the extra time and space of something like ed448 present uncomfortable trade-offs.

File encryption is not generally one of those applications.

So I find this a little disappointing.

But I suppose that NIST PQ will finalize in the not far future and this will get replaced by something that hybridizes with a PQ scheme. (I say replace because the expectation that a pubkey is something you can easily copy and paste doesn't really work with the PQ schemes you'd likely use with file encryption.)

What happens if auth fails part way through the file? Do you get a truncated decryption on stdout? -- or is this buffering the whole input in memory?

[nullc]

Answering my own question: The reason it would continue to use 255 bit ECC is because an objective is (ab)using people's github ssh authentication keys.

FWIW, if the idea there is that you'll be able to send encrypted reports to github users based on their ssh keys... that might not work so well in the long run esp for security conscious projects, since good practice would have their github ssh key living in a keyfob that won't decrypt messages for them. :)

[FiloSottile]

Native age keys are pure X25519 with no connection to SSH keys. SSH support is kind of a growth hack, I made sure it didn't impact the rest of the design.

Recipient types are the one parameterized thing in the spec, so if we need to switch to Ed448 or a PQ hybrid at some point we absolutely can, without even bumping the version.

[jiofih]

I was ready to use this in a project but “made encryption weaker because GitHub” is not exactly high in its selling points

[tptacek]

It's linked right from the spec: it's a streaming AEAD construction, and getting that is literally one of the motivations behind the tool. It does not buffer the whole message in memory, or fail to detect truncation.

[tedunangst]

I think it's reasonable to ask for clarity on this point. One might, reasonably imo, expect buffering. (And E2BIG if a size limit is exceeded.) You have to dive deeper into the spec than a genre savvy user should need to learn this.

[CodesInChaos]

While the underlying algorithm detects truncation/corruption, the specification does not describe how the command line tool signals this to the caller.

This is problematic since a caller needs to be aware of the need to appropriately handle truncated plaintext output. The readme needs to warn about this pitfall.

[dependenttypes]

I think that you misunderstood nullc's question. They are asking what happens if at some point one of the poly1305 MACs in the file is incorrect. Not if someone truncates the file.

[nullc]

We're talking about the same thing.

I saw that it used a streaming AEAD, but that's actually what inspired my question.

Since (from the github page) it reads stdin, it can't two-pass the file.

So it appears that if you hand it a file with midstream corruption it's going to feed a truncated input down your pipeline.

That has consequences. They may well be less serious consequences than buffering a potentially unlimited amount of data in memory :), but it's useful to make the behavior very clear because it wouldn't require too advanced an idiot to make something that was exploitable on this basis.

[tptacek]

It's Rogaway's STREAM scheme from https://eprint.iacr.org/2015/189.pdf. Are you pointing out a problem in the paper, or in some specific idiosyncrasy you see of how it's implemented here? If so: what is it?

The AGL post the spec links to directly talks more generally about the high-level strategy: you're buffering chunks of files. You're only ever releasing authenticated plaintext. If you're piping to something processing plaintext on-line, that thing might need to wait for the end-of-file signal before processing or else potentially operate on a truncated file (by some integral number of chunks). `age` is still just a Unix program.

[nullc]

My question was asking to confirm that it indeed will put out a truncated output when given a mid-stream corrupted input (and that it doesn't do something like buffer just to validate).

That behavior should be clearly documented, so that users can be advised that their pipelines need to safely handle that case.

> that thing might need to wait for the end-of-file signal before processing or else potentially operate on a truncated file

Exactly. The docs should say this clearly, or someone will manage to create an interesting vulnerability with it eventually. :)

Could go with a message the points out that encryption doesn't authenticate the source-- which is a not uncommon misuse that shows up with PGP, where people assume that the source is authentic if the input was encrypted, even where no signature is used. (the fact that corrupted input gives an "authentication failed" message might be particularly misleading)

[tptacek]

It's streaming on-line encryption. That's literally the point of streaming encryption: not buffering whole messages. The rest of your point directly follows from "not buffering whole messages".

[labawi]

Serious question: If you're not signing (age does not*), then what is the point of the AEAD STREAM scheme? By definition, nothing is authenticated, right?

[nullc]

Consider this attack.

You found a vulnerability in FooSmith and want to collect a bounty. You're keeping the vuln secret both for security reasons, and so no one else can jump your claim.

FooSmith has announced a bounty process where you can claim a bounty by sending an encrypted message with a novel vulnerability according to a specified process.

So you send a report using the mandatory bounty collection form, which starts off with a fixed position field "Bitcoin address to pay bounty to: <address goes here>".

I happen to know what address you're going to use since you posted it so everyone could see when you got paid. I happen to have write access to FooSmith's issue tracker. I xor youraddress xor myaddress into the stream at the right position, and tada thanks to the fragility of stream ciphers, esp unauthenticated ones: it decrypts to a different message that asks for the payout to my address.

Adding a digital signature to the encrypted wouldn't have magically made it secure: I would just rip that one off and replace it with my own-- FooSmith can't authenticate a signature here, the authentication is "common membership inside an encrypted message", and without authentication that can't work securely.

There are other attacks when the encryption lacks a auth. Imagine you run a network service that accepts encrypted messages and decrypts them then reports back various distinct result messages based on what the input decrypted to.

I have an encrypted message for your service authored by someone else and I'd like to learn about its content. Without auth I could start sending it to you over and over again, flipping bits in it to learn about the content. In some cases, when the planets align just right, this kind of bug lets you use the service as a decryption oracle-- you can get the entire encrypted message!

(Toy example: if the service reports the input in an error message, simply corrupting the first bit might instantly get you the content. But it can be much more complex and subtle than that.)

This isn't to say that you couldn't build a security protocol that didn't use authed encryption... you can, but without auth the encryption doesn't form a nice abstracted layer and much more of the application has to be analyzed from the perspective of cryptographic attacks. History has shown people fail to do this well, so authed encryption should almost always be used unless there is a really good reason why it can't be.

[tptacek]

'nullc and I are talking about the same thing.

[CiPHPerCoder]

> NSA recommended people stop using ECC <384 bits

Since when does anyone care about NSA's opinion (who also don't have to care about FIPS compliance)?

[dependenttypes]

> NSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa...).

Yet they are still fine with AES-128, even though it is objectively a weaker link in the chain. See https://blog.cr.yp.to/20151120-batchattacks.html

[nullc]

If you follow the link in my message you will see a table with "Use 256 bit keys" for AES.