Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lib25519.cr.yp.to

Post reply on HN
Print view View original

41–50 of 61 posts

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

#41

Post by PunchyHamster »

gnull wrote: post #33
alexjurkiewicz wrote: post #2

(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.

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 descr…

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

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

#42

Post by PunchyHamster »

tptacek wrote: post #8
Fnoord wrote: post #7

Earlier quoted context omitted.

> 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.

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

"this app needs me to generate a key and point to it in config" is plenty of overlap

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

#43

Post by PunchyHamster »

alfiedotwtf wrote: post #37
alexjurkiewicz wrote: post #2

(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.

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

support is fine. Being default is crazy

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

#44

Post by minitech »

gnull wrote: post #33
alexjurkiewicz wrote: post #2

(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.

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 descr…

> 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.

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

#46

Post by Retr0id »

kfreds wrote: post #29
tptacek wrote: post #8

Earlier quoted context omitted.

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

I don't consider myself a programmer and I can use Ed25519 safely. I do however understand computing fairly well.

I consider myself a programmer and ed25519-understander, but the idea of using it directly within a shell script terrifies me.

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

#48

Post by Retr0id »

PunchyHamster wrote: post #42
tptacek wrote: post #8

Earlier quoted context omitted.

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

"this app needs me to generate a key and point to it in config" is plenty of overlap

If you just want a raw ed25519 private key then `head -c32 /dev/urandom` does the job. But usually you want a DER/PEM wrapper or similar, which the openssl cli tools handle nicely.

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

#49

Post by adastra22 »

XorNot wrote: post #28
adastra22 wrote: post #26

Earlier quoted context omitted.

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

Such as? I need an alternative which supports commutative trust relationships of some sort which are revocable.

You (knowingly?) picked the one counter example, lol. Web of trust is the one application of PGP/GPG for which there isn’t a product ready replacement tool to point towards. GPG is built around web of trust, but this is generally believed to have been a very, very bad idea and the source of innumerable security problems for nearly every application that has tried to make use of it. The GPG replacements I would point to are purpose-built for specific domains and eschew web of trust:

https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

That said, you might find what you are looking for in the Rebooting Web of Trust project, and the various decentralized identity (DID) implementations that have come out of it:

https://www.weboftrust.info/

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

#50

Post by adastra22 »

C4K3 wrote: post #32
XorNot wrote: post #28

Earlier quoted context omitted.

Such as? I need an alternative which supports commutative trust relationships of some sort which are revocable.

Keybase or any of the tools inspired by keybase (foks.pub etc)

Isn’t keybase to GPG what github is to git?
Post reply on HN