[HN Gopher] Show HN: Kryptor - A simple, modern, and secure encr...
___________________________________________________________________
Show HN: Kryptor - A simple, modern, and secure encryption tool
Author : samuel-lucas6
Score : 52 points
Date : 2021-08-24 16:45 UTC (6 hours ago)
(HTM) web link (www.kryptor.co.uk)
(TXT) w3m dump (www.kryptor.co.uk)
| Koshkin wrote:
| > _simple... modern... secure..._
|
| > _I 'm only a student and not even a computer science student._
|
| I am sold!
| dang wrote:
| Please don't be a jerk in HN comments and particularly not in
| Show HNs. Note these rules:
|
| _Don 't be snarky._
|
| _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._
|
| _Be respectful. Anyone sharing work is making a contribution,
| however modest._
|
| _Instead of "you're doing it wrong", suggest alternatives.
| When someone is learning, help them learn more._
|
| _When something isn 't good, you needn't pretend that it is,
| but don't be gratuitously negative._
|
| https://news.ycombinator.com/showhn.html
|
| https://news.ycombinator.com/newsguidelines.html
| upofadown wrote:
| >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"?
| an_ko wrote:
| 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.
| jerf wrote:
| 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.
| georgyo wrote:
| 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.
| samuel-lucas6 wrote:
| 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.
| e12e wrote:
| 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?
| samuel-lucas6 wrote:
| 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.
| e12e wrote:
| 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..
| samuel-lucas6 wrote:
| 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.
| zikduruqe wrote:
| > 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.
| rodolphoarruda wrote:
| 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.
| detaro wrote:
| can you spot when they were bought in this graph?
| https://github.com/keybase/client/graphs/contributors
| argvargc wrote:
| This is the first time I've seen a reasonably full-featured
| encryption suite that doesn't require hours of investment to make
| full use of it.
|
| I liked the considerate UI touches too, such as automated pass-
| phrase generation on hitting return.
|
| I wonder if there could be a sweet-spot of people with a bit of
| technical knowledge and a need for encryption beyond GUI apps,
| but not so much of either to make a big time investment that
| other command-line tools often require.
|
| Small criticism - and it might just be me, but the perspective
| alternation here had me reading this part three times:
|
| "You can use hybrid encryption to send an encrypted file to
| someone else. Note that this is one-way encryption. The sender
| cannot decrypt the file. This means that you should not overwrite
| the original file."
|
| Maybe change "the sender cannot..." to something like "You cannot
| decrypt the file, only the recipient can, using their private
| key."?
|
| (From: https://www.kryptor.co.uk/tutorial )
| sysadm1n wrote:
| I hope in the near future someone builds a GUI using this. Not
| that the command line is some scary thing I avoid, but with a
| GUI, you have the luxury of not having to fiddle too much. GUIs
| are intuitive and also a luxury few can afford to build, which is
| why I tend towards using them.
| tkot wrote:
| Would EncryptPad be enough for your needs?
|
| https://evpo.net/encryptpad/
| samuel-lucas6 wrote:
| Kryptor actually started out as a GUI application, but cross-
| platform GUI development is a lot harder than CLI development,
| especially in C#, I didn't want to work on both a GUI and CLI
| application, and designing a GUI for file signing and
| encryption with a password, keyfile, password and keyfile, and
| private key would be tricky. I also prefer GUIs when possible,
| but it made sense for me to make the switch.
___________________________________________________________________
(page generated 2021-08-24 23:01 UTC)