Leftover questions about age

[UnixCro]

Hello,

please excuse me if it is a stupid question, but I am not familiar with cryptography, so please give me an answer.

age-keygen generates a public key and a private key and a new pair each time it is called.

Isn't it possible that at some point all possible combinations will be used up and that by chance someone will have the same private key as the public key?

2. Which algorithm does age encrypt with, somehow I couldn't find anything about it?

3. I understand the parameter —armor, you might be so friendly and you could explain it to me in more detail, perhaps with examples.

[covert-encryption]

@UnixCro There are so insanely many possible secret keys that it is impossible to ever create the same ones again, assuming that the source of random numbers is working properly. It is impossible to grasp how large the number of possibilities is, but here is a video that covers it quite well: https://www.youtube.com/watch?v=S9JGmA5_unY

The encryption algorithm is ChaCha20 with Poly1305 authentication. This is mentioned in the specification, and is pretty much the best algorithm currently known, and also very widely used in different systems. Different types of recipient keys are used, as explained in the specs, to derive the file encryption key used with ChaCha20 which encrypts all your data.

Armor means conversion into Base64, which is well explained in multiple sources, so that it becomes ASCII text, rather than binary data. This is to allow copy&pasting to messaging software, where you cannot always attach binary files. Age imitates PGP in that it also adds -----BEGIN AGE ENCRYPTED FILE----- headers around the base64 but these are actually quite useless, if not for advertising the software used.

[str4d]

The reason age supports armoring is not for copying files into messaging software (though it does enable that as a side effect), but because Windows machines don't have consistent handling of Unix line endings. The age format consistently uses \n for separating header sections (and requires them for canonicity), but Windows can and will interfere with that and use \r\n instead. The armoring format provides slightly more flexibility in that it accepts either kind of line ending.

The BEGIN headers around the armored format are there because age uses the strict textual encoding format defined in RFC 7468.

[covert-encryption]

This is becoming off topic, and I certainly respect the effort to follow an RFC, but a few comments on armoring...

Indentation, different EOLs and quote marks > can be handled/removed just fine without those headers.

Verifying that each line except for the last one is of full length, and that the last line is divisible by four protect against loss of characters (some systems miss characters when a large amount of text is pasted on a terminal, and in messaging if not properly code tagged, /slashes/ in Base64 may be interpreted as italics and removed). Invalidating anything with non-Base64 characters within the lines quite reliably rejects any text snippets that are not actually Base64. The headers are particularly prone to corruption by Unicode hyphen conversions or --overstrike-- markup (but again one should be using code tags, so this might be a good thing, catching such issues early).

Given that Age has its plain text header also within the Base64 encoded content, the format can be easily verified even without these headers, and certainly one can just base64 -d the content and hand it over to Age as a non-armored file.

Presumably the headers would allow for easier extraction of Age snippets from a longer text, and the footer would allow Age to stop reading more input lines from console once the footer is seen. However, it seems that the current implementation does not do either of these, but instead decodes the message before even reading the footer: #364

[FiloSottile]

The reason for the headers is just that it's PEM, and PEM is a thing that already exists, has plentiful language support, and does the job well enough. We did not set out to improve on the state of the art of textual encoding (which is something that, for example, SaltPack did), we just wanted a default answer for "what if I can't trust my medium to be 8-bit safe?" PEM will do, and many users have encountered PEM at some point.

It's also nice that you can look at a file with head or tail or cat or anything that's not specific to the encoding and know "ah, this is an age encrypted file".

If you have other specific requirements, like Markdown compatibility, or error correction, or very low overhead, then you are in a better position than we were to pick an optimal solution for your use case and compose it with age binary input and output.