4 ms·

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

by nullc 7y ago

NSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm 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?

CiPHPerCoder 7y ago
> 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)?
nullc 7y ago
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 7y ago
  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 7y ago
  I was ready to use this in a project but “made encryption weaker because GitHub” is not exactly high in its selling points
deleted 7y ago
[deleted]
tptacek 7y ago
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 7y ago
  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 7y ago
  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 7y ago
  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.
  - tptacek 7y ago
    'nullc and I are talking about the same thing.
  - nullc 7y ago
    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.
dependenttypes 7y ago
> NSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa... 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 https://blog.cr.yp.to/20151120-batchattacks.html
- nullc 7y ago
  If you follow the link in my message you will see a table with "Use 256 bit keys" for AES.

by nullc 7y ago

CiPHPerCoder 7y ago

> 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)?

nullc 7y ago

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 7y ago
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 7y ago
I was ready to use this in a project but “made encryption weaker because GitHub” is not exactly high in its selling points

deleted 7y ago

[deleted]

tptacek 7y ago

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 7y ago
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 7y ago
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 7y ago
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.
- tptacek 7y ago
  'nullc and I are talking about the same thing.
- nullc 7y ago
  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.

dependenttypes 7y ago

> NSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa... 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 https://blog.cr.yp.to/20151120-batchattacks.html

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