Using Standard Tools or coding custom ones

[ahnedeee]

I wanted to know how can I achieve the same level of symmetric encryption security in Kryptor using GPG or OpenSSL?
How can I achieve authenticated encryption using them?
Or better, are there tutorials on how to implement authenticated symmetric encryption like kryptor online?

[samuel-lucas6]

I'm afraid this is rather out of scope as you're asking about other tools. A lot of detail is also missing as it's unclear whether you're talking about encrypting with a password, private key, to someone else's public key, etc. The algorithms used in Kryptor are listed here, and I strongly suspect you cannot do something equivalent with either tool, although I've never used OpenSSL.

The most comparable tool is probably age/rage. However, Kryptor has some design changes to address limitations with those. There's also Covert, which inspired/informed some of the v4 design.

In terms of replicating Kryptor, the specification is on the website. Age and Covert also have some.

[ahnedeee]

I’m talking about symmetric encryption using a secret key.
I also thought it might be the case that I can’t reproduce kryptor’s security using other tools.
So, how can I code the symmetric encryption using libsodium?
Are there any tutorials online?
I’m new to cryptography

[samuel-lucas6]

There aren't really any tutorials I can recommend. Starting out in cryptography is quite tricky and requires a lot of reading. It's best to read the libsodium documentation, the documentation for your libsodium binding, best/recommend practice type of guides like this and this, read the RFCs/Internet-Drafts for algorithms you're using like this, read up on existing protocols like the specifications I already linked, read some cryptography books, and read relevant questions on Cryptography Stack Exchange and r/crypto.

Some other file encryption tools to look at are Encpipe and Eureka. The safest approach in libsodium is to use the secretstream API, but not every binding supports that, and you could technically still misuse that.

[ahnedeee]

Thanks for the help

[ahnedeee]

I wanted to ask if this CLI i quickly made has any security vulnerabilities, what are some things that make it less secure:

import os
import sys
import pysodium
import tempfile
import shutil

KEY_FILE = "pass.key"

def generate_key():
    return pysodium.randombytes(pysodium.crypto_aead_xchacha20poly1305_ietf_KEYBYTES)

def save_key_to_file(key):
    with open(KEY_FILE, 'wb') as key_file:
        key_file.write(key)

def load_key_from_file():
    try:
        with open(KEY_FILE, 'rb') as key_file:
            return key_file.read()
    except FileNotFoundError:
        return None

def encrypt_file(input_file, output_file, key):
    nonce = pysodium.randombytes(pysodium.crypto_aead_xchacha20poly1305_ietf_NPUBBYTES)
    with open(input_file, 'rb') as f_in, open(output_file, 'wb') as f_out:
        data = f_in.read()
        encrypted_data = pysodium.crypto_aead_xchacha20poly1305_ietf_encrypt(data, None, nonce, key)
        f_out.write(nonce + encrypted_data)

def decrypt_file(input_file, output_file, key):
    with open(input_file, 'rb') as f_in:
        data = f_in.read()
        nonce = data[:pysodium.crypto_aead_xchacha20poly1305_ietf_NPUBBYTES]
        encrypted_data = data[pysodium.crypto_aead_xchacha20poly1305_ietf_NPUBBYTES:]

        # Create a temporary file to store the decrypted data
        with tempfile.NamedTemporaryFile(delete=False) as tmp_file:
            try:
                decrypted_data = pysodium.crypto_aead_xchacha20poly1305_ietf_decrypt(encrypted_data, None, nonce, key)
                tmp_file.write(decrypted_data)
            except Exception as e:
                print(f"Decryption failed: {str(e)}")
                # If decryption fails, remove the temporary file
                os.remove(tmp_file.name)
                return

        # If decryption was successful, move the temporary file to the specified output file
        shutil.move(tmp_file.name, output_file)

def main():
    if len(sys.argv) < 4:
        print("Usage: python cli.py [encrypt/decrypt] input_file output_file")
        sys.exit(1)

    mode = sys.argv[1]
    input_file = sys.argv[2]
    output_file = sys.argv[3]

    key = load_key_from_file()

    if key is None:
        if mode == 'encrypt':
            print("No key found. Generating a new key.")
            key = generate_key()
            save_key_to_file(key)
            print(f"Encryption Key saved to {KEY_FILE}")
            # Set file permissions to 444
            os.chmod(KEY_FILE, 0o444)
        else:
            print("No key found. Unable to decrypt.")
            sys.exit(1)

    if mode == 'encrypt':
        encrypt_file(input_file, output_file, key)
        print(f"File {input_file} encrypted to {output_file}")
    elif mode == 'decrypt':
        decrypt_file(input_file, output_file, key)
        print(f"File {input_file} decrypted to {output_file}")
    else:
        print("Invalid mode. Use 'encrypt' or 'decrypt'.")
        sys.exit(1)


if __name__ == "__main__":
    main()

[ahnedeee]

And I also wanted to know the difference between chacha with padding fix and xchacha
what is the key commitment for?

[samuel-lucas6]

And I also wanted to know the difference between chacha with padding fix and xchacha
what is the key commitment for?

ChaCha20-Poly1305 with the padding fix has the same nonce size as regular ChaCha20-Poly1305, whereas XChaCha20/XChaCha20-Poly1305 has a larger nonce, making it more suitable for random generation. However, it's technically fine to randomly generate the nonce with ChaCha20-Poly1305 as long as you rotate the key frequently (e.g. every file). The padding fix is just for key commitment.

You would intuitively expect an AEAD scheme to be context/fully committing (it commits to the key, nonce, associated data, and message - all four inputs). They should really be by design. However, popular AEADs like AES-GCM and (X)ChaCha20-Poly1305 are non-committing (they commit to none of the inputs). This means tag verification can pass despite a different key being used for decryption, for example. Long story short, this causes vulnerabilities in some protocols, like with password-based encryption, if the attacker can choose parameters. There's actually a student project on age about this.

[ahnedeee]

And I also wanted to know the difference between chacha with padding fix and xchacha
what is the key commitment for?

ChaCha20-Poly1305 with the padding fix has the same nonce size as regular ChaCha20-Poly1305, whereas XChaCha20/XChaCha20-Poly1305 has a larger nonce, making it more suitable for random generation. However, it's technically fine to randomly generate the nonce with ChaCha20-Poly1305 as long as you rotate the key frequently (e.g. every file). The padding fix is just for key commitment.

You would intuitively expect an AEAD scheme to be context/fully committing (it commits to the key, nonce, associated data, and message - all four inputs). They should really be by design. However, popular AEADs like AES-GCM and (X)ChaCha20-Poly1305 are non-committing (they commit to none of the inputs). This means tag verification can pass despite a different key being used for decryption, for example. Long story short, this causes vulnerabilities in some protocols, like with password-based encryption, if the attacker can choose parameters. There's actually a student project on age about this.

so is using the algoithm in the code I provided above safe?

[samuel-lucas6]

I'm afraid I can't keep peer reviewing your code, especially since I don't program in those languages. As to your question, secretstream isn't committing because it uses (X)ChaCha20-Poly1305. However, if you're only ever using your tool offline on your machine, you should be fine.

[ahnedeee]

In terms of peer reviewing my code, don't worry.
In terms of committing, when should it be necessary?

[samuel-lucas6]

All future AEAD schemes should be fully committing ideally because that's what you'd intuitively expect and to prevent potential vulnerabilities. The vulnerabilities require attacker control over inputs, meaning it's an online concern, like if there's a server that knows the encryption key derived from a password and performs decryption for you (an oracle). Another example would be sending an encrypted file to someone and it decrypting to different plaintexts for different recipients.

[ahnedeee]

By the way, does kryptor "encrypt then mac" or no?
And if it doesn't, is it fully committing?

[samuel-lucas6]

This is the last question I'll answer in this thread. It used to, but I switched to ChaCha20-Poly1305 for better efficiency on ARM, although that's technically Encrypt-then-MAC internally. The padding fix only provides key commitment. In the next file format or another tool, I will use another AEAD or a generic composition AEAD.