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

21–30 of 61 posts

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

#21

Post by quotemstr »

tptacek wrote: post #15
quotemstr wrote: post #14

Earlier quoted context omitted.

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.

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

A command like cryptography swiss army knife useful though. If not openssl, then what?

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

#22

Post by tptacek »

quotemstr wrote: post #21
tptacek wrote: post #15

Earlier quoted context omitted.

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

A command like cryptography swiss army knife useful though. If not openssl, then what?

It's useful as a toy and a learning tool, but for nothing else. For those two things, OpenSSL is fine as it is.

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

#23

Post by coppsilgold »

tptacek wrote: post #12
why-o-why wrote: post #10

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

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.

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>

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

#24

Post by alexjurkiewicz »

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.

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

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

#26

Post by adastra22 »

XorNot wrote: post #5
Retr0id wrote: post #3

Earlier quoted context omitted.

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.

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.

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

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

#27

Post by why-o-why »

tptacek wrote: post #12
why-o-why wrote: post #10

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

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.

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?

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

#28

Post by XorNot »

adastra22 wrote: post #26
XorNot wrote: post #5

Earlier quoted context omitted.

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.

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.

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

#29

Post by kfreds »

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.

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

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

#30

Post by perching_aix »

mrbluecoat wrote: post #20

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

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.
Post reply on HN