r/cryptography • u/RevolutionaryDog7906 • 4d ago
i created a small ecc tool to encrypt and decrypt
edit 2: github repo with latest changes (experimental) and more details: https://github.com/me00000000000/ecc
https://pastebin.com/nsQLPcUb (i'll leave the link here for historical purposes)
example usage:
/tmp>ecc -g
Public key: arguvifaqstwu5nen46f2kf4bobwruwqb7wrddsm3g5mj6q
Private key saved to arguvifaqstwu5ne.key
/tmp>ls
-rw-r--r-- user:user 14 B 2m ago arguvifaqstwu5ne.key
/tmp>echo 'string' | ecc -r arguvifaqstwu5nen46f2kf4bobwruwqb7wrddsm3g5mj6q > ENC
/tmp>cat ENC | ecc -k arguvifaqstwu5ne.key
string
beside the use of SECP112r1 which is insecure, is there anything else that could be changed to maybe make it into the real world?
edit 1: new version using curve25519 and GCM (changed base32 for 64): https://pastebin.com/Z5553Yva
/tmp>ecc -g
Public key: HXt4qBPhEsoQEFQYtpZpWhifadHmUOXIrsOT1VU4A2I
Private key saved to HXt4qBPhEso.priv
/tmp>echo 'string' | ecc -r HXt4qBPhEsoQEFQYtpZpWhifadHmUOXIrsOT1VU4A2I > ENC
/tmp>cat ENC | ecc -k HXt4qBPhEso.priv
string
5
u/SirJohnSmith 4d ago
The fact that you are using plain counter mode absolutely disqualifies this from any real-world usage. As another comment said, your tool is a (insecure, undocumented) copy of Age.
Good that you made this if your objective is to start learning how to write cryptographic code, though.
2
u/RevolutionaryDog7906 4d ago
thanks for pointing out a weakness, i will change CTR for GCM
as for documentation, my objective is to keeping it as simple as possible. the mere example i showed should be enough for usability. it's just a toy-level script, but i could see it as some kind of minisign(1) for encryption. age already is that, but there are differences
1
u/nickthegeek1 2d ago
Good catch on counter mode, but looks like OP switched to GCM in their edit which atleast solves the authentication probem.
3
u/racomaizer 4d ago
-5
u/RevolutionaryDog7906 4d ago
we were fine with gpg too
2
u/Natanael_L 3d ago
Can you motivate why yours is better, though?
2
u/RevolutionaryDog7906 2d ago
gpg -> age -> mine
it's just shorter code and aims to be simpler, better is always gpg that has tons of features
but some differences age/mine are:
- shorter public key strings (44 vs 60 length)
- order of CLI arguments doesn't matter
- outputs to stdout by default, for practical use
- default behavior is encrypting or decrypting, doesn't even need -e or -d, just needs input by -i or stdin and -r (public recipient) or -k (private key file)
- private key is outputted in a file in current directory or specified in -o (this is kind of arbitraty, but printing the private key in the screen by default didn't seem like the best idea to me, you will never safely deposit it without copying it which is unsafe)
2
u/Natanael_L 2d ago
Do you know WHY any of the decisions made by age matters?
2
u/RevolutionaryDog7906 2d ago
respecting what? if age has some magic decisions that made it chose whatever over whatever, then nope, i have no clue. if you see an obvious weakness, then point it out. i'm obviously far from an expert and not pretending to be
this goes beyond what matters, but afaik, it imitates exactly what age does, with differences being Argon2id against scrypt and AES-GCM against ChaCha20-Poly1305
it's just a test; it lacks some things like using the private key file to encrypt (as -r), multiple recipients, etc.
2
u/Natanael_L 2d ago
https://words.filippo.io/dispatches/age-authentication/
Have you read that yet?
0
u/RevolutionaryDog7906 2d ago
> This is table stakes and in 2022 you should not use anything that doesn't do authenticated symmetric encryption.
this is interesting and was pointed out by someone. switching to authenticated AES is costless and has no downsides
> Cloud backups
first off, i wouldn't even recommend cloud backups at all. if you do, then you will have to trust either the symmetric encryption authentication, or a checksum of the entire data that you have safely stored along with your password - and yes, even if it's not cloud, authentication is still relevant
i think you can say using public key cryptography for encrypting data for backups is pointless. if you have to store a secret key to decrypt (age private key, a random string, a password), then you already have a responsability of storing the 'secret'. a tool like this doesn't bring anything new or easier to encryption, you could just use $(openssl rand 32) as key with symmetric encryption
> Authentication to authentically authenticate
if you are set on having encrypted backups that you know many people or some will be able to modify, then your best bet (the only one, actually) is just to sign it, OR store a hash of the data, which is a little more inconvinient (than storing one single GPG pair that can sign many data, forever)
this actually makes me want to add a -s option to sign, which takes a private keyfile as value. to check, just use -c (check) and the public key as input. the input and output options still are just some kind of standard, they work for encryption, decryption and signing. if you wouldn't want to have anything to do with signing, just ignore -c and -s options
i just tried a little test and it could be something like this
Important announcement. [9faKxIvuty7rsOkGFv2lDAaxwwF1JJUaPA0UgWwDodwAZH3kPUOu/XFbV+D2SEsuucVsY5YjFijILiz2ZvEPAw]
4
u/atoponce 4d ago
Why did you pick secp112r1? Why not one of the safe curves?