5 ms·

Show HN: Kryptor – A simple, modern, and secure encryption tool

78 points by samuel-lucas6 5y ago

upofadown 5y ago
The age utility is a bit ironic in that a utility intended to make malicious modification less of a problem doesn't do signatures. So an attacker doesn't have to go to the bother to modify the file, they can just create a whole new file. Kryptor is more complete. If you do public key encryption you also have to support signatures if modification is an issue. You can't just leave it to the user to figure out.
- 0xdeadb00f 5y ago
  I think this is a fair critisim of age. It's so obvious yet it's gone over my head.
- samuel-lucas6 5y ago
  Thank you for the kind words. That's why the key exchange in Kryptor is authenticated.
tyingq 5y ago
Looks interesting, but it looks like it might be hard to integrate with, or use in a batch fashion. Gpg has options like "--passphrase-fd", "--batch", "--yes", and so on to address these things. Not that you need to implement it that way, but some way to accommodate batch mode and integration.
- samuel-lucas6 5y ago
  That's a fair point. I previously supported -p|--password followed by a password, but I removed that functionality in a later version because strings are immutable in .NET and therefore cannot be zeroed out from memory. Furthermore, I think hiding the typed password characters is beneficial from a security perspective. Whilst that functionality could be added back in, I'm trying to keep the number of options as small as possible. Kryptor already has more options than age because it supports signatures. Having two password related options also adds confusion, and it would be slightly more tricky to support batch functionality for decrypting your private key.
  - tyingq 5y ago
    I think getting rid of providing the password as a plaintext command line parameter makes sense. Accepting it on a file handle or stdin seems like it would be popular though.
pavlovskyi 5y ago
Great job! Funny thing is that crypting/decrypting tools are riding on a hype train right now <trying to guess why is that happening>
- samuel-lucas6 5y ago
  Thanks! Yeah, they kind of are.
sigjuice 5y ago
I don't quite understand the details of file sharing (https://www.kryptor.co.uk/tutorial#using-a-private-and-public-key-file-sharing https://www.kryptor.co.uk/tutorial#using-a-private-and-publi...) If I want to send an encrypted file to someone, don't I just need the recipient's public key? What is the role of my private key here? Is my private key used for adding my signature?
- samuel-lucas6 5y ago
  Yes, you need the recipient's public key, and they need your public key. Your private key is used to perform a key exchange using X25519 (https://www.kryptor.co.uk/technical-details#private-and-public-keys https://www.kryptor.co.uk/technical-details#private-and-publ...). Unlike age, this key exchange is authenticated, meaning you can know who sent you the file. Unfortunately, due to that and the fact that the file format is fixed rather than variable in length, Kryptor currently only supports specifying one recipient at a time. Implementing multiple recipient support is a nice idea, but it's quite tricky to do and would require creating different files for different people.
upofadown 5y ago
>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"?
- raggi 5y ago
  % gpg -c hello gpg: problem with the agent: No pinentry gpg: error creating passphrase: Operation cancelled gpg: symmetric encryption of 'hello' failed: Operation cancelled
- samuel-lucas6 5y ago
  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 5y ago
    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 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..
sysadm1n 5y ago
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.
- samuel-lucas6 5y ago
  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.
- tkot 5y ago
  Would EncryptPad be enough for your needs? https://evpo.net/encryptpad/ https://evpo.net/encryptpad/
argvargc 5y ago
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 https://www.kryptor.co.uk/tutorial )
- samuel-lucas6 5y ago
  Thank you for the feedback! I'll go ahead and reword that.
Koshkin 5y ago
> simple... modern... secure... > I'm only a student and not even a computer science student. I am sold!
- samuel-lucas6 5y ago
  I know what it sounds like, but the 'don't roll your own crypto' mantra is completely overused. That advice really applies to creating custom cryptographic algorithms (e.g. a new cipher or hash function) without adequate academic experience. When it comes to implementing cryptography using libraries like libsodium, that mantra doesn't apply if you're willing to do enough research. Instead, it should be 'be careful rolling your own crypto'. If everyone took the 'don't roll your own crypto' motto literally, then we wouldn't have had libsodium or Monocypher. Everybody has to start somewhere. Education about how to implement things correctly, code peer review, and feedback on designs should be the norm, not 'don't roll your own crypto'. Unfortunately, some people aren't willing to do any of those things.
- dang 5y ago
  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/showhn.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

78 points by samuel-lucas6 5y ago

The age utility is a bit ironic in that a utility intended to make malicious modification less of a problem doesn't do signatures. So an attacker doesn't have to go to the bother to modify the file, they can just create a whole new file. Kryptor is more complete. If you do public key encryption you also have to support signatures if modification is an issue. You can't just leave it to the user to figure out.

0xdeadb00f 5y ago
I think this is a fair critisim of age. It's so obvious yet it's gone over my head.
samuel-lucas6 5y ago
Thank you for the kind words. That's why the key exchange in Kryptor is authenticated.

tyingq 5y ago

Looks interesting, but it looks like it might be hard to integrate with, or use in a batch fashion. Gpg has options like "--passphrase-fd", "--batch", "--yes", and so on to address these things. Not that you need to implement it that way, but some way to accommodate batch mode and integration.

samuel-lucas6 5y ago
That's a fair point. I previously supported -p|--password followed by a password, but I removed that functionality in a later version because strings are immutable in .NET and therefore cannot be zeroed out from memory. Furthermore, I think hiding the typed password characters is beneficial from a security perspective. Whilst that functionality could be added back in, I'm trying to keep the number of options as small as possible. Kryptor already has more options than age because it supports signatures. Having two password related options also adds confusion, and it would be slightly more tricky to support batch functionality for decrypting your private key.
- tyingq 5y ago
  I think getting rid of providing the password as a plaintext command line parameter makes sense. Accepting it on a file handle or stdin seems like it would be popular though.

pavlovskyi 5y ago

Great job! Funny thing is that crypting/decrypting tools are riding on a hype train right now <trying to guess why is that happening>

samuel-lucas6 5y ago
Thanks! Yeah, they kind of are.

sigjuice 5y ago

I don't quite understand the details of file sharing (https://www.kryptor.co.uk/tutorial#using-a-private-and-public-key-file-sharing https://www.kryptor.co.uk/tutorial#using-a-private-and-publi...) If I want to send an encrypted file to someone, don't I just need the recipient's public key? What is the role of my private key here? Is my private key used for adding my signature?

samuel-lucas6 5y ago
Yes, you need the recipient's public key, and they need your public key. Your private key is used to perform a key exchange using X25519 (https://www.kryptor.co.uk/technical-details#private-and-public-keys https://www.kryptor.co.uk/technical-details#private-and-publ...). Unlike age, this key exchange is authenticated, meaning you can know who sent you the file. Unfortunately, due to that and the fact that the file format is fixed rather than variable in length, Kryptor currently only supports specifying one recipient at a time. Implementing multiple recipient support is a nice idea, but it's quite tricky to do and would require creating different files for different people.

upofadown 5y ago

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

raggi 5y ago
% gpg -c hello gpg: problem with the agent: No pinentry gpg: error creating passphrase: Operation cancelled gpg: symmetric encryption of 'hello' failed: Operation cancelled
samuel-lucas6 5y ago
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 5y ago
  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 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..

sysadm1n 5y ago

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.

samuel-lucas6 5y ago
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.
tkot 5y ago
Would EncryptPad be enough for your needs? https://evpo.net/encryptpad/ https://evpo.net/encryptpad/

argvargc 5y ago

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 https://www.kryptor.co.uk/tutorial )

samuel-lucas6 5y ago
Thank you for the feedback! I'll go ahead and reword that.

Koshkin 5y ago

> simple... modern... secure... > I'm only a student and not even a computer science student. I am sold!

samuel-lucas6 5y ago
I know what it sounds like, but the 'don't roll your own crypto' mantra is completely overused. That advice really applies to creating custom cryptographic algorithms (e.g. a new cipher or hash function) without adequate academic experience. When it comes to implementing cryptography using libraries like libsodium, that mantra doesn't apply if you're willing to do enough research. Instead, it should be 'be careful rolling your own crypto'. If everyone took the 'don't roll your own crypto' motto literally, then we wouldn't have had libsodium or Monocypher. Everybody has to start somewhere. Education about how to implement things correctly, code peer review, and feedback on designs should be the norm, not 'don't roll your own crypto'. Unfortunately, some people aren't willing to do any of those things.
dang 5y ago
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/showhn.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html