search

devingfx / cryptsh

Create crypted self-executable bash scripts.
GNU General Public License v3.0
3 stars 4 forks source link

could it use ed25519 crypto #1

Open zicmama opened 4 years ago

zicmama commented 4 years ago

Like natools... https://git.duniter.org/tools/little-tools/-/tree/master/tools

devingfx commented 4 years ago

Could you be more explicit for our readers? What is ed25519 algorithm? What are the benefit this change will bring? What are the implication for the user or simplicity?

zicmama commented 4 years ago

Could you be more explicit for our readers? What is ed25519 algorithm?

ed25519 is the crypto tool used by many. Cesium, Gchange, ScuttleButt, IPFS...

What are the benefit this change will bring?

it allows private messages. https://ssbc.github.io/scuttlebutt-protocol-guide/#private-messages https://git.p2p.legal/axiom-team/cesium-messaging

What are the implication for the user or simplicity?

I am not sure. If a password is asked. It must be transmitted Being able to use a private key to decrypt and run bash would allow cryptsh integration with Astroport as ZenTag "contract.sh" between ipfs/gchange identities.

devingfx commented 4 years ago

I am not sure. If a password is asked. It must be transmitted Being able to use a private key to decrypt and run bash

The private key must be transmitted also ...

The goal of this (small) script was to be able to execute scripts on non-trusted endpoint, where you may not have already private keys accessible in file system. It is why a password encryption was chosen... _(exemple: I rent a brand new hosted server, on my first login into a fresh new debian I can wget a crypted script (from a public accessible untrusted place) and execute it to install my passwords and ssh authorisedkeys and install dependencies)

I'm not sure to see the point of having protected scripts standing on trusted endpoint where the security access must have been done system wide, and so sensible scripts should already been protected on execution (chmod og-wx script.sh).

This said, I'm not closed to your idea...

Please make a PR I'll see if the user experience is not affected (if it's still easy to use with password and private key is an opt-in option) and maybe merge this feature.

Advise: to modify the way encryption is made you have to modify this line: https://github.com/devingfx/cryptsh/blob/175ec05ae7a953805f2756b70df015ae78aa5b7f/cryptsh#L11 and to modify the way decryption is made it's this line: https://github.com/devingfx/cryptsh/blob/175ec05ae7a953805f2756b70df015ae78aa5b7f/cryptsh#L5 and also in decryptsh : https://github.com/devingfx/cryptsh/blob/175ec05ae7a953805f2756b70df015ae78aa5b7f/decryptsh#L6

devingfx commented 4 years ago

PS: the content of auto_exec line is hashed using obfuscate that was made rapidly, so the resulting obfuscated code may not work if the original bash is too complicated... Avoid structures (if for case ...) avoid paths, avoid complicated substitutions ...

zicmama commented 3 years ago

i must think about your arguments... could you make a "howto use it" with A <-> B (or others) parties involve and help me understand the usability?