[HN Gopher] Show HN: Age 1.0 - Simple, modern and secure file en...
___________________________________________________________________
Show HN: Age 1.0 - Simple, modern and secure file encryption
Author : FiloSottile
Score : 254 points
Date : 2021-09-06 16:53 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| danenania wrote:
| A tangential question: is there an age equivalent du jour for
| signatures? For release signing and verification.
|
| I'm looking especially for end-user ease of installation.
| minisign seemed promising but `brew install minisign` has _tons_
| of dependencies and takes forever. I found a Go port with
| compiled binaries, but it 's not a popular repository.
|
| Is there anything cross-platform and widely trusted that's better
| than gpg?
| tptacek wrote:
| Yes: it's minisign/signify (a deliberately simple ed25519
| format based originally on OpenBSD's package signing system,
| which I think 'tedunangst designed.) Minisign is packaged by
| the libsodium team.
| danenania wrote:
| Gotcha, thanks! It seemed perfect until I tried the homebrew
| installation. I missed that they're releasing compiled
| binaries as well.
| Tomte wrote:
| It's minisign.
|
| I see a libsodium dependency in the sources, anything else?
|
| Don't the binaries at
| https://github.com/jedisct1/minisign/releases work for you?
| danenania wrote:
| Ok thanks. Maybe the problem is that the homebrew formula is
| building from source instead of using the binaries? I'll have
| to look closer.
| twp wrote:
| age has been an alternative plugin to gpg for transparent file
| encryption and decryption for the chezmoi dotfile manager for a
| couple of years now. age's CLI is so much nicer and easier to
| integrate than gpg's. Now with the Go API being stable, I can
| also bake high-quality modern encryption straight into the
| binary. Much appreciated.
|
| [1] https://github.com/twpayne/chezmoi
| tyingq wrote:
| >age's CLI is so much nicer and easier to integrate than gpg's
|
| Some of that seems to be from omitting features, though. Gpg
| CLI integration allows passing both the cleartext to be
| encrypted and a passphrase on pipes. Which means things like
| --passphrase-fd, which age doesn't seem to have. Makes it
| simpler, but also means you have to have more clear text in
| files, at least temporarily.
| a1369209993 wrote:
| > things like --passphrase-fd, which age doesn't seem to have
|
| You can use /proc/self/fd/N if the program handles files
| correctly (particularly, no seek).
| dang wrote:
| One big past thread and two tinies:
|
| _Age: A simple, modern and secure file encryption tool_ -
| https://news.ycombinator.com/item?id=21895671 - Dec 2019 (197
| comments)
|
| _Age - The PGP Replacement (alpha)_ -
| https://news.ycombinator.com/item?id=21188517 - Oct 2019 (2
| comments)
|
| _Alpha release of Age-tool - A small command line encryption
| utility made in Go_ -
| https://news.ycombinator.com/item?id=21177063 - Oct 2019 (1
| comment)
| jl6 wrote:
| Bold move, grabbing a three-letter name with widespread pre-
| existing meaning, but it looks like you might just have gotten
| away with it! Congratulations!
| FiloSottile wrote:
| Right?! I'm as surprised as you are.
| jchw wrote:
| The main thing that confuses me with age so far is it feels like
| there's no way to have private keys that are automatically
| detected and also encrypted on disk. It seems to have a defacto
| mechanism for a user-local keys.txt, and sops for example uses
| this. However, as far as I can tell, keys.txt can't be encrypted.
| It's probably true that on most developer machines even just
| read-only filesystem access with the user's permissions would be
| catastrophic, but I feel a bit uncomfortable with how easy this
| makes it to extract private keys. Am I missing something? I know
| there's also a mechanism that can use SSH keys as private keys,
| but sops doesn't support that yet. (It also doesn't work with SSH
| agent, but that's still better than nothing I think.)
| FiloSottile wrote:
| 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.
| jchw wrote:
| Oh, OK. So if sops wants to support encrypting its own
| keys.txt file, it would need to be implemented on their end.
| For some reason, I was under the impression age itself had
| some logic for keys.txt files.
|
| I understand that it is an ugly and imperfect layer of
| security to secure keys this way, but I still prefer it over
| nothing. Maybe applications could try implementing OS-level
| 'secure' keyring storage; that seems marginally better... No
| idea, though, I'm no expert on security.
|
| Thanks for age regardless. I'm sure I'll be using it a lot in
| the future.
| ricardobeat wrote:
| Where do you store the key that decrypts your key file?
| jchw wrote:
| You can encrypt with a passphrase.
| flurie wrote:
| Has anyone managed to replace file encryption using gpg or sops
| with age for anything other than simple use cases? I realize age
| doesn't cover the breadth of scope of the other two, but it
| doesn't seem like those gaps are being filled by anything else,
| either.
| cpach wrote:
| What is it that you're missing?
| aborsy wrote:
| Not OP, but I am missing:
|
| * password store (Pass)
|
| * hardware key support
|
| * back up software using Age (as with duplicity)
|
| * integration into operating systems (cross platform)
|
| * integration into apps
|
| * Mobile support
|
| * command line for key management (maybe), to help me
| organize and rotate keys, and maybe share public keys
|
| * An agent?
|
| * robust positive review or audit (security people need to
| review the source code independently), or a long history of
| good security
|
| Mount would be great too!
| wolf550e wrote:
| hardware key support exists: https://github.com/str4d/age-
| plugin-yubikey
| upofadown wrote:
| Correct me if I am wrong, but that doesn't seem to do the
| decryption on the yubikey itself. So the Yubikey wouldn't
| act as a portable air gapped system as in the case of,
| say, GPG.
| lmeyerov wrote:
| Something I've been wondering for awhile: while innovation for
| per-file-level encryption is useful, is there a clean way to run
| encrypted docker volumes for achieving containerized encryption-
| at-rest? In particularly, a _portable_ docker-only way (ex:
| docker-compose containers / users on the network get access and
| that's it), with no host linux FS / k8s extensions?
| [deleted]
| jph wrote:
| Great work, thank you for sharing. I especially appreciate your
| link to your "Goals" section-- I'm listed them below because they
| are important and helpful IMHO.
|
| + An extremely simple CLI that composes well with UNIX pipes, and
| that works well as a backend for other programs
|
| + Small copy-pasteable keys, with optional textual keyrings
| Support for public/private key pairs and passwords, with multiple
| recipients
|
| + The option to encrypt to SSH keys, with built-in GitHub .keys
| support
|
| + "Have one joint and keep it well oiled", no configuration or
| (much) algorithm agility
|
| + A good seekable streaming encryption scheme based on modern
| chunked AEADs, reusable as a general encryption format
| Aachen wrote:
| How do you do AEAD with seeking? Tags (MACs) every few
| kilobytes?
| some_furry wrote:
| https://web.cs.ucdavis.edu/~rogaway/papers/oae.pdf (Section
| 7)
|
| Previously: https://news.ycombinator.com/item?id=21897192
|
| STREAM is a well-studied construction for online
| authenticated encryption. It doesn't _just_ involve an auth
| tag every few kilobytes (or megabytes, or gigabytes). There
| 's also a byte flag (called a "tag" in some implementations)
| to indicate whether or not there should be additional blocks
| or not.
| masklinn wrote:
| > The option to encrypt to SSH keys, with built-in GitHub .keys
| support
|
| It's not built in, just composable in. And to the version in
| the readme I prefer using command substitution personally: it's
| clearer when there are multiple recipients, and the infile
| tends to be much larger than the keys.
|
| The biggest issues wrt github are that it rejects age files (so
| you have to rename them) and there is no /keys at the repo
| level whivh would give you the keys of all maintainers, so you
| have to hunt them by hand.
| charles_f wrote:
| One thing I miss and would imagine probably front and center of
| an encryption tool, is the algorithm(s) it's using to encrypt.
| There are multiple mentions of keys, but not the encryption
| mechanism itself. I've been roaming around the doc for that but
| couldn't find anything. Is there any pointer to that?
| ameliaquining wrote:
| Specification of the format is at
| https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s8...
| and includes all the cryptographic primitives that it uses.
| TL;DR: Mostly the djb stack.
| b8 wrote:
| The DoD has a public encryption wizard
| (https://spi.dod.mil/ewizard_govt.htm). It requires Java and it
| just reached EOL though.
| arthurcolle wrote:
| > requires Java
|
| if the federal government builds a time machine one day I'm
| sure the firmware will consist of a little Java 5 servlet
| running on a Windows XP machine
| schmorptron wrote:
| Big words for someone who doesn't run on over 6 billion
| devices(tm)!
| [deleted]
| fXmBeWm3TQ wrote:
| calling this format "secure" is not sufficient, here is a review
| that asked the right questions.
|
| https://neilmadden.blog/2019/12/30/a-few-comments-on-age/
| Unfortunately, the age spec doesn't document its threat model or
| the security goals it is intended to achieve so I'm having to
| read between the lines to work out what was intended.
| est31 wrote:
| Yeah it's definitely not cutting edge on all fronts. Another
| issue is that the length of the plaintext is being exposed.
| Simple padding would help mask that in most, if not all,
| instances.
| upofadown wrote:
| It's for the case where you are concerned about malicious
| modification and the user is expected to not deal with the
| ramifications of the error message. This case in particular:
| $ gpg2 -d backup.tgz.pgp | tar xz
|
| So the modified backup file can do bad things before anyone can
| stop it because gpg will complete the operation before warning
| of the modification.
|
| It doesn't have integrated signature support so that in most
| cases an attacker can use the public key to entirely replace
| the file and avoid the bother of some sort of known text attack
| in the first place. So I think that the use case is so narrow
| as to disappear.
|
| The linked article covers this. That is really all there is.
|
| It serves best as a demonstration of what an encryption utility
| would be like that blows up and errors out on a possible
| modification, as opposed to completing the operation and
| returning the error at the end.
| tptacek wrote:
| More on this argument here:
|
| https://news.ycombinator.com/item?id=27433186
|
| This is, to put it charitably, an idiosyncratic argument
| about how data encryption is supposed to work.
| upofadown wrote:
| That age does not yet have a data recovery utility is, I
| think, an interesting point, but it is a different point
| entirely.
| tptacek wrote:
| If I've confused this for some other idiosyncratic
| argument about PGP's "authenticated" encryption, I
| apologize for scrambling the thread. Probably the top-
| line response re: PGP is that there might be no
| cryptographic tool in common use with a less coherently
| documented threat model than PGP.
| some_furry wrote:
| Has someone created a Reed-Solomon encoder/decoder CLI
| program to use with age yet?
|
| I think if we did that, the stupid discussion about GPG and
| framing its lack of IND-CCA2 as a "recoverability feature"
| would become moot.
| upofadown wrote:
| The single bit error in the discussion was intended to be
| an extreme example. Typically media errors involve entire
| media blocks. Often the blocks are missing entirely.
|
| I have looked into this a bit and there doesn't seem to
| be any reason age could not have a recovery utility. It
| would involve some minor brute forcing to find the next
| block and block number. It could even skip any 64k block
| that failed the integrity check so that only
| authenticated data was recovered. That would be
| consistent with the general principle about not releasing
| unauthenticated data that age was created to enbody.
| some_furry wrote:
| The reason I suggested a separate utility, and a
| composition thereof, is that complexity is the enemy of
| security.
|
| Error-correction and media block-based encryption is a
| separate utility than what age provides, and should
| therefore be a separate tool.
|
| That separate tool _can_ use age for the cryptography.
| That 's fine.
|
| But I will not advocate for more complexity to be shoved
| into age. It's fine as it is today.
| balu_ wrote:
| I would love to see a password manager based on age. Idealy using
| ssh-keys beeing combinable with git
| honko wrote:
| There is passage that does this:
| https://sr.ht/~gpanders/passage/
| SrslyJosh wrote:
| > The author pronounces it [age], like the Italian "aghe".
|
| I've seen a number of READMEs with this kind of pronunciation
| note recently--I don't think they really help, because I suspect
| that most readers aren't familiar enough with the IPA
| (pronunciation) notation.
|
| I suggest including a link to something like this: http://ipa-
| reader.xyz/?text=a%C9%A1e&voice=Joanna
| aborsy wrote:
| Good job!
|
| I much look forward to: hardware key support, password store,
| mount and integration with back up software (and perhaps rclone
| which is for data movement).
|
| I am pretty happy with GPG, which supports most of these features
| and more (sometimes via third parties that use it), but also
| appreciate Age and may play with it, once it's more useful.
|
| I like that it's, apparently, easier for applications to
| interface with it, particularly in the large and growing Go
| ecosystem.
|
| One complaint: It's hard to find Age by Google search!
___________________________________________________________________
(page generated 2021-09-06 23:00 UTC)