Search code examples
javascriptnode.jsencryptionelliptic-curve

How to securely encrypt files with a shorter private key than RSA?

For improved security we need to store files encrypted, with individual keys for users needing access. I already learned that I should use a symmetric key with aes-256-cbc for the file. Then I can use an asymmetric key for each user. I tried standard RSA with modulusLength: 2048.

My issue is, that the private key is too long to be placed on a QR-code (or the dedicated reader can't handle the size) - which is required.

Then I started to look into elliptic curve cryptography. Various AI bots suggested secp256k1 and x25519. Nice short keys. With various AI hallucinations, trial & error I now understand that a shared secret is required, opposed to when using RSA, then use aes-256-cbc for the symmetric key. But that means that I need to hand over both public and private key with the QR code, instead of just the secret key as with RSA.

I am wondering, if this makes sense? When I hand over both keys at the same time to re-create the shared secret, is there any advantage over just creating any kind of byte-key with the same length?

Furthermore I have the IV for the symmetric encryption. Can that be public for every file? I read it should be individual for every file. AI bots say they can be public. When getting all encrypted files with a list of all IVs, isn't that easing potential attacks?

Any kind of tips how to handle this is welcome.

Update due to some comments: the files will be stored encrypted on a generic device. The user will be given a QR code to access the device and decrypt files. There is no prior key exchange with the user.

# example keys to compare length
{
    "rsa": {
        "publicKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm4O9jblPksKoHQkR6OSr\n2UI4VrQPg4Yj5CTRicCjVg6Iijy51WCiN94NY+pOA5RCw5c47+lrnnmFyJaZqrGy\nMwHYGGd1mim61JT6/lR4YbaVC9SHubQCNQd4FJ0q7l/z8FKOSIj7F1qgT7zD0R6Y\ngnWKOIYEBcsvZhU8GPFf25R/YImbTnr4Upub07O1ZUtCaFNni09SLwbnubbLL9Mw\n3Ec66oxq26SQFqRigA4WzzrA+2Es1sU39wLKJc5JImhP3CEYGtLIRYN9PjqV2p9E\nIk+jzS/jDlvZJ/3ZI8ihxV7vu87N0UDKGdtVzpimXG4GEbTlfUEkPivEPgugi/K6\nHwIDAQAB",
        "privateKey": "MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCbg72NuU+Swqgd\nCRHo5KvZQjhWtA+DhiPkJNGJwKNWDoiKPLnVYKI33g1j6k4DlELDlzjv6WueeYXI\nlpmqsbIzAdgYZ3WaKbrUlPr+VHhhtpUL1Ie5tAI1B3gUnSruX/PwUo5IiPsXWqBP\nvMPRHpiCdYo4hgQFyy9mFTwY8V/blH9giZtOevhSm5vTs7VlS0JoU2eLT1IvBue5\ntssv0zDcRzrqjGrbpJAWpGKADhbPOsD7YSzWxTf3AsolzkkiaE/cIRga0shFg30+\nOpXan0QiT6PNL+MOW9kn/dkjyKHFXu+7zs3RQMoZ21XOmKZcbgYRtOV9QSQ+K8Q+\nC6CL8rofAgMBAAECggEAEeVvYbOtcRL+kVd9sffoFiM/5Cu/d0rEru3/wQ2j8594\n3gj5TRFcSaKU7DvGnjR9xGVkKNO1+Jw9JZATKf4Ipu8I5QdkP16bAKNjs53ukTbC\nNdok2Qgv6CtZCcJBHQJ6H4dYlrH7dzy3eHBIITTB/I1ginr9qS8F4DEEY/hu/WU4\n9dgo9ZaGCgAexXD/EShwSfetkYi6oDe7DIg7aGtdnhFkouIFR4Sn01mzwe0F8a7n\n/LFGBUSaY94viVd6YCS+dR1UUSvkTWnQDZrROuncZM3JEhVm2yAUGXLVluy4y9ug\nbTnD0bky9pA1YlhYOhsH+mcRqTVzhbcXMPfpwLUI9QKBgQDJV6707h4qsdjnTUzB\ndAFu5ZC08tn4C3AxGHL6Wg9NX4Ccgod8KZBHBpIIxmQj/eIZzmVs9E8aNebh/iy1\nov1nnsVrlTiP/t5b+x65MIyoOZeDcN2TMcyjOdsGCsT33Jm/YqM6SiI68liYO7Yd\n6mWImYUwwf+uwa1IDjLwO1+3wwKBgQDFuz4il3uEq5D6s793ng1FnG9EiUZ8quOD\nkyycha0lF5O9uLuXRBAzUNdv4AFhoGjoC4XSI7Egz25JWj8wEOLfiD16NhCFbn8+\ncJewi9kevZk/ThaviwoaWv8nYKXxRhikT8uQbB3Fq7pjSVwuILeauFsbXPBAWkZS\ngG0Ld59qdQKBgCIWznB5wHHKGsdOtygp0/RKue1pEK6GgUBOu2jXxq968/OLxhSn\nlN3xptgFfv75BUcJQvLnil0Ns0GgH0HBjtX0c8h7Q1Bd/pfkNJd2ONpipdyDR4Cc\ndeFM8mBbgm3U09MriCdeVd1VGtrrgTIfdYFjPMG8luWntQb2IHm8E8CxAoGAI9ZJ\n7q8R3fvSbP3DCAUHVsSBjiRrOBEo5yH3he7ccMqTJmGi7kmRvhs60LYCyhTuro/Y\nEzwQ0GeID5dhuG53EBh7O/ksiWJ7gW+aro7KLT4j1ktq5SoIDLrNX++uY8pWkQE9\nXdGam8cCIxiasmmPnWUobg8sJB24fR91pAxsQjkCgYEAyMhE36eZf5QhvYhggBnD\n1GF6WKRVyXCFAVx3DO1FgRbw+KVuFLa0IRJ2JfiwKx9YDuKjwAw06rStCtU2ItVT\ns5QUYre+ojne4NbZqUwLA1LunMlQUeKJvYAIvUQmpUmP9G9lG4xfTHyEIt6Ez8u5\nIXflUi4ssrTEhS9EdVNQ6nE=",
        "type": "rsa"
    },
    "ecc": {
        "publicKey": "MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAEvcegDDQnifb4SJKn7P75caFkXKrXtdldJz7bvOzcjpao8iCqvgA/kDhHaNRquHWuZXKsuxGY4bLGOloxEBl2Ig==",
        "privateKey": "MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgsceHVsfG7CSW2izfCcsD3NSqiu01WWHOcjPbz2UkS3WhRANCAAS9x6AMNCeJ9vhIkqfs/vlxoWRcqte12V0nPtu87NyOlqjyIKq+AD+QOEdo1Gq4da5lcqy7EZjhssY6WjEQGXYi",
        "type": "secp256k1"
    },
    "ecx": {
        "publicKey": "MCowBQYDK2VuAyEA6CVjrWVhoPgmS724cWTMUv+nQB6ke6Yuq1DQljYjmX8=",
        "privateKey": "MC4CAQAwBQYDK2VuBCIEIFC+z5tefBAqS8YdTswdqPL7mVkbo1wTnbqmtkQiFxJp",
        "type": "x25519"
    }
}
Solution

  • First of all, you never send the private key. Instead the public key needs to be transported from the receiver to the sender. The sender needs to trust that public key to be from the intended receiver, or an adversary could substitute that public key with one of his own.

    The AI is probably suggesting ECIES. In that case you basically employ ECDH to create an encryption scheme.

    The reason why you are confused is that ECIES has two key pairs, a static key pair and an ephemeral one. The static key pair is owned by the receiver and the public key of that needs to be known & trusted by the sender; the private key is - as always - kept secure by the receiver. In principle an ECDH public key (part) may just be transmitted as two coordinates, which for ECDH with a key size of 256 bits means 512 bits minimum overhead. However, that doesn't include any data required to setup the trust; usually the public key is part of an (X.509) certificate or certificate chain.

    The ephemeral key pair is a newly generated, single use key pair generated by the sender, using the same domain parameters. The ephemeral private key and the public key (part) of the receiver are used in key agreement (usually followed by a key derivation function) to derive a secret key such as an AES key. This key can be used to encrypt a message after which the ephemeral private key and secret key can be destroyed at the sender. The sender then sends their ephemeral public key as well as the ciphertext message to the receiver.

    Now comes the trick: due to Diffie-Hellman key agreement the receiver can use the ephemeral public key and their static private key to derive the same secret key. This secret key is then used to decrypt the ciphertext, after which the ephemeral public may be discarded.

    As for the IV: as the secret key is always newly generated for this scheme you may leave the IV to all zero on both sides (or derive it afresh together with the key). You might say that this scheme has a disadvantage over RSA encryption but please remind you that RSA encryption or key wrapping also has significant overhead due to the required padding.

    All in all, the AI is not wrong, but assessing the answer requires quite a good understanding of cryptography.

    Note with regard to terminology: in my mind you don't share private information. You may share secret information. A private key is part of an (asymmetric) public / private key pair and a secret key is used for symmetric cryptography. There are unfortunately textbooks out there that confuse private & secret keys. Fortunately most text uses the same terminology that I do.