Back

Ed25519-CLI – command-line interface for the Ed25519 signature system (2024)

96 points10 dayslib25519.cr.yp.to
alexjurkiewicz3 days ago

(2024)

My favourite part of these tools is the zany use of numbered file descriptors. `keypair` outputs the public key on fd 5 and secret key on fd 9. But signing reads the secret key on fd 8, while verification reads the public key on fd 4! Why aren't they the same?? I have to read the manpage every time.

gnull3 days ago

That's such a user-hostile design decision. I can't fathom what justifies it (other than kinky taste).

Makes your commands unreadable without a manual, leaves a lot of room for errors that are quietly ignored. And forces you into using a shell that comes with its own set of gotchas, bash is not known to be a particularly good tool for security.

And to those who stay this adds flexibility: it doesn't. Those file descriptors are available under/dev/fd on linux, with named options you can do --pk /dev/fd/5. Or make a named pipe.

minitech3 days ago

> Those file descriptors are available under/dev/fd on linux, with named options you can do --pk /dev/fd/5.

If you have a procfs mounted at /proc and the open syscall to use on it, sure (and even then, it’s wasteful and adds unnecessary failure paths). Even argument parsing is yet more code to audit.

I think the design is pretty good as-is.

gnull1 day ago

It's 2025, dude. You can't be seriously telling me how difficult it is to parse arguments. It may be difficult in C, but then we're down another sick rabbit hole of justifying bad interface with bad language choice.

One open syscall in addition to dozens already made before your main function is started will have no observable effect whatsoever.

+1
minitech1 day ago
PunchyHamster3 days ago

it being option can be nice if you don't want your keys touching disk and need to pass it over to other apps.

it being default is insanity

Retr0id3 days ago

I'm curious, what do you actually use it for?

I'd have otherwise guessed that this tool mainly exists just to test lib25519. Personally I'd only ever want a library, or some higher-level tool. A CLI tool that just does raw signing feels like a weird (and footgun-shaped) middle ground.

tptacek3 days ago

This mostly exists to test lib25519 and ostensibly to build systems with shell scripts (though: few people would do that). It is a weird and footgun-shaped middle ground.

XorNot3 days ago

It's why no one has succeeded in replacing GPG: you need a lot of systems to work in order to have an actual viable one, the ability to spit out signatures from keys is required but not sufficient.

adastra223 days ago

GPG is pervasive for the same reason git is pervasive: network effects. There are plenty of better alternatives.

+2
XorNot3 days ago
Fnoord3 days ago

> I'm curious, what do you actually use it for?

FTA:

> These tools allow lib25519 to be easily used from shell scripts.

I've never used ed25519-cli, but not having to use a library is nice for someone who isn't a programmer.

tptacek3 days ago

The Venn diagram of "not a programmer" and "can safely use Ed25519" is two non-overlapping circles.

+1
PunchyHamster3 days ago
+1
kfreds3 days ago
alexjurkiewicz3 days ago

Simply combine this tool with `openssl enc` and your shell script is as secure as any shell script could be

loeg3 days ago

Someone writing shell scripts is a programmer, for better or worse.

jedahan3 days ago

I was wondering the same thing. My best guess is that is to guard against operator misuse. Like usb-a only plugging in one way. Anything that is secret will never accidentally print to stdout. String interpolation in bash with `—option $empty` might be safer than `8<$empty`. Have to explore more but yeah, this is a new pattern for me as well.

yellowapple3 days ago

Another possible factor driving the decision to use numbered file descriptors: the logic to validate that a file exists (or can exist) at a given path, is readable/writable, etc. gets punted to the shell instead of being something the program itself has to worry about.

gnull3 days ago

Those descriptors like 5 could be mapped to anything, including descriptor 1, stdout.

chuckadams3 days ago

What a strange convention. I'm partial to minisign, which works on plain old files.

tptacek3 days ago

This little CLI is not meaningfully an alternative for signify/minify. Here's a good piece on signify from its author (who also comments here):

https://www.openbsd.org/papers/bsdcan-signify.html

alfiedotwtf3 days ago

I’m guessing it’s to support the test framework it’s built with?

PunchyHamster3 days ago

support is fine. Being default is crazy

pamcake3 days ago

[dead]

pseudohadamard3 days ago

It's djb's web site so it's a djb design. With great genius comes great different thinking.

PunchyHamster3 days ago

> It writes the public key to file descriptor 5, and then writes the secret key to file descriptor 9.

Is the project trying to compete with GPG for worst interface ? Magic numbers BAD, especially in something that will mostly be used in scripts

why-o-why3 days ago

Why not zoidbe... I mean, why not open ssh? It's literally a CLI that does every crypto operation with every primitive (except some PQC)?

tptacek3 days ago

If you mean the OpenSSL CLI, it's hard to think of a more footgun-y cryptographic tool than the one that:

* defaults to unauthenticated encryption

* buries its one authenticated mode

* requires explicit command-line nonces

* defaults to an MD5 KDF

You could probably keep going for another 10 bullets. Never use the OpenSSL CLI for anything other than TLS stuff.

coppsilgold3 days ago

You can use ssh-keygen for signing and verifying signatures.

You can also use age[1] to encrypt payloads targeting ssh public keys. And decrypt using ssh private keys.

[1] <https://github.com/FiloSottile/age>

quotemstr3 days ago

Yeah, the OpenSSL CLI sucks. So what's to be done?

Sure, we can build a 25519-specific tool with a less footgun-y interface. Fine, whatever, for that one use case.

Or we can build an alternative OpenSSL CLI that explodes OpenSSL and its numerous useful features in a general way and helps fix lots of use cases.

tptacek3 days ago

Nothing is to be done. Just don't use the OpenSSL CLI. It's a deeply cursed concept for a tool!

+1
quotemstr3 days ago
pamcake3 days ago

[dead]

why-o-why3 days ago

Are you confusing the open openSSL library with the CLI? Absolutely none of this is true when used as a signing tool on the CLI. Seems like you just needed to rant, rather than answer my question. Which is fine: I do it to, but I was legit asking a question that you ignored and you seem to know about openSSL?

tptacek3 days ago

[flagged]

why-o-why3 days ago

[flagged]

WiSaGaN3 days ago

I can't find the source. Anyone can point to it?

minitech3 days ago

The Download link in the header (https://lib25519.cr.yp.to/download.html).

mrbluecoat3 days ago

Sounds like the perfect place to embed credential stealing malware. Good thing they publish their code on an independent third-party public code sharing platform. Oh wait...

perching_aix3 days ago

Short of suspecting a malicious tarball, I really can't think of a reason why "publish[ing] their code on an independent third-party public code sharing platform" would be a selling point. You're getting the source code straight from the horse's mouth this way.

esseph3 days ago

> feels like a weird (and footgun-shaped) middle ground.

hmm

> It is a weird and footgun-shaped middle ground.

Oh? HMMMMM :|