Hacker News Reader

Comment by upofadown | Hacker News Reader

>It is by no means a complete replacement for GPG, but that is a good thing considering the sheer number of features is what makes GPG practically unusable.

Kryptor example:

    $ kryptor -e -p test.jpg

Same thing with GPG:

    $ gpg -c test.jpg

So how can unused features in a command line utility make something "practically unusable"?

View on HN

You're going to take the position that "gpg" is easy to use?

Good luck with that.

'So how can unused features in a command line utility make something "practically unusable"?'

By destroying the documentation's utility to someone who just wants to do some particular task, but has that much documentation to wade through.

Gnupg is easy to use. Incredibly easy. All common use cases that new tools have are extremely straight forward.

There is a lot of features that you can get deep into the weeds with. But the common use cases are dirt simple.

Put another way, it would be easier to teach a grandparent how to use gnupg than it would be to teach something like age.

I think incredibly easy is a bit far. Look at how many commands and options there are in total: https://www.gnupg.org/documentation/manpage.html. Beyond that, the website isn't the easiest to navigate, and the guides they have linked are quite wordy. You simply cannot argue that it's user friendly overall.

However, I'll admit that my original wording was too harsh in the case of simple encryption. I also agree that GPG with that command is slightly easier than age, although the documentation for age could be better in my opinion. GUI applications will always be best for the average user.

The other point of new tools is to make changes to the file formats, cryptographic algorithms, etc and reduce the number of lines of code to make things more auditable.

When has "too much documentation" ever been a problem? That's like being mad that the money in your wallet takes too much time to count.

I'll take too much docs any day over not enough docs.

Many, many times is when it's been a problem.

Even your analogy is lame, because it's not like that. The "money" is what you're looking for. It's like being mad that your wallet is so stuffed with pointless expired gift cards that you can never find the money, that'd be a more accurate analogy.

So, your next monthly salary should be in the form of sacks of pennies?

The choice isn't "too much docs" Vs "not enough docs" it's "huge complicated thing" Vs "simple thing".

The C++ Programming Language (B. Stroustrup) is a far longer book than The C Programming Language (K&R) but C++ is not a better or simpler to use language by dint of having a larger book

Analogy fail. Twice. The second failure is a result of promoting a personal hobby horse. Yes, we all know you are biased about C++. No, that doesn't make your bias relevant to all topics. Or any topic.

Gpg for file encryption is easy to use.

The difficulty that people refer to is about key management that holds for any program, and email encryption, that involves setting up an email client, a plug-in, getting the other side to use encryption, etc. This didn’t scale well, because the average user wants a zero click solution.

The average user (and some times those familiar with technology) hasn’t heard of Thunderbird and doesn’t want to set that up. They have a short password and use web browsers.

Security-critical software is best when it's obvious how to use it, and how not to, which is easier with a focused tool. I feel like GPG has so many features that it's hard to look things up in a manual, or to make use of shell tab-completion, or to get a clear mental picture of its possible failure modes.

It's sort of obviously true that when something makes it harder to make mistakes, it's safer. But there's only so much a tool can do. It's not hard to use if you understand asymmetric cryptography, but if you don't, it's asymptotic to impossible. The model itself is pretty hard.

That's very true. Asymmetric cryptography is a lot less intuitive, and it's hard to come up with a decent GUI for that kind of functionality. Keybase and keys.pub have probably done the best job.

You can currently do the following with Kryptor:

$ kryptor -e test.jpg

The difference is that this uses your encryption private key. However, I will look into just supporting -p because that's a fair point, although that would be trickier to implement.

As for the unusable statement, I'm referring to the long list of other commands, which is more linked to digital signatures than encryption. For instance, there are entire guides and hour long YouTube videos on how to use GPG.

Edit: I've reworded my criticisms of GPG to clarify that it's not universally difficult to use.

This is all without any kind of key management? No web of trust, no certificate authority/repository?

Gpg is hardly perfect - but I'm not sure how useful public key signature and authenticated encryption modes are without key management?

Are there any kind of embedded timestamp for signatures and encrypted files (signed at/valid to etc)?

Ed: I gather the main focus of this project is to extend age with minisign - but I worry that what's really needed is a (new, not PGP) standard format - that allows authenticated encryption and signing - and possibly with date/validity for signatures (beyond merely an ad hoc use of minisign trusted comments - a standardized use of minisign comments might be fine?).

At any rate, I'm not too thrilled about the age projects stand on signatures:

https://github.com/FiloSottile/age/issues/51

I strongly believe one of the main uses of encryption is enabling trust - and that implies trusted keys, trusted content and trusted signatures - along with a notion of time.

They might be constructed out of primitives - but a user facing cli/gui should probably be strongly opinionated, and have good training wheels to make misuse and misunderstanding as difficult as possible..

That's correct. I've done something similar to Minisign. Handling that sort of problem is way beyond what one person can manage anyway. I'm only a student and not even a computer science student.

The recommended way of sharing keys is via social media, GitHub, your website, etc. Unfortunately, Keybase has now been abandoned and was acquired by Zoom, so that's not worth using anymore. However, I don't personally see how this method of sharing is that problematic. I think it does the job sufficiently.

There are no timestamps for signing or encryption, but as you mentioned, you could use the comment functionality to add a timestamp for signatures.

A new standard format would be ideal, but that's probably not going to happen for a long time. I'm also disappointed by the stance on signatures, although there are several other things that are wrong with age, which is why I decided to make my own tool, not that it's perfect by any means either. I like to think I did a much better job documenting things though.

> Unfortunately, Keybase has now been abandoned and was acquired by Zoom, so that's not worth using anymore. However, I don't personally see how this method of sharing is that problematic.

https://keys.pub has been trying to solve this too for some time.

Could you please provide evidence on Keybase "abandonment" by Zoom? I'm asking because I'm a heavy user and have always been concerned about a possible sunset for the product.

can you spot when they were bought in this graph? https://github.com/keybase/client/graphs/contributors

Wow. That is astonishing and disheartening. I had high hopes for Keybase.

Thanks for sharing the link, even though it gives me such a bad feeling. I really like Keybase. An important part of my workflow relies on it. So... oh shit.

I can understand the desire to shake off the burden of compatability with PGP - but maybe not if sticking to the same design, and just shifting encryption primitives somewhat?

If you want PGP - there's the sequoia project to consider as well:

https://sequoia-pgp.org/

The "stateless cli tool"[1] looks like it's mostly complete for sign/encrypt etc now?:

https://gitlab.com/sequoia-pgp/sequoia-sop

    sqop generate-key julia@example.org > julia.secret.pgp
    sqop extract-cert < julia.secret.pgp > julia.public.pgp

    echo "a message" | sqop encrypt julia.public.pgp > message.pgpo
    sqop decrypt julia.secret.pgp < message.pgp
    a message

[1] https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-...

Apparently expired? Was sop abandoned?

  % gpg -c hello
  gpg: problem with the agent: No pinentry
  gpg: error creating passphrase: Operation cancelled
  gpg: symmetric encryption of 'hello' failed: Operation cancelled

Reply on news.ycombinator.com