I have a pair of RSA keys where the private key is encrypted with a passphrase. Would it be a security risk if the public and private keys are committed to version control without any further encryption (like via using Ansible Vault)?

NB: The passphrase, however, is encrypted with Ansible Vault.


  1. Why do you want to commit the keys to git?
    The keys are committed to git because they're used to setup an automation user on a data warehouse. The repo contains the SQL migrations run on the warehouse and part of it is a "create user" statement. To keep everything in one place, the keys are in git.

  2. Is the repo public?
    No, the repo is private on Github.

  3. How many people get to clone/fork the repo?
    A team of 8 people get to clone the repo.

For now, all the private keys and passphrases are encrypted with Ansible Vault. I asked this question to see whether encrypting an encrypted RSA key was redundant.


1 Answer 1


Can one? Yes, of course. Should one? No, that's generally a bad idea.

The password-based encryption used on most private keys is not great. The specifics depend on a bunch of things, including what tool is parsing the key data, but generally it uses an acceptable-but-outdated cipher (which isn't really the problem) and a wholly insufficient key derivation function (which is). This makes it very easy indeed to brute-force the password, given a decently fast and highly-parallel computer (commonly known as a graphics processing unit or GPU).

Now, of course, if the "password" is actually very high entropy, then you're fine. Brute-forcing the encryption itself is almost certainly impractical, unless it's very old and using single-DES or similar. But the vast majority of passwords are going to be perhaps 40 bits of entropy at most, which means they'll be in the first trillion candidates tried. That might sound like a lot but when you can hash tens of billions of password candidates per second, as high-end GPUs can, it might literally take less than a minute to try a trillion candidates (in practice it'll take longer given that brute-forcing the encryption password isn't literally as simple a single round of SHA-256, but not by more than a few times).

In any case, the purpose of the encryption on the private key isn't take make it safe to distribute the key or store it somewhere shared. It's so that, in the event you have reason to suspect somebody might have gained access to the key, you have a shot at immediately revoking it and swapping it out for a new one. If you begin that process the moment after you type git push then you will in fact probably beat anybody else, but it seems kind of like a giant waste of effort.

  • It depends on the encryption scheme, I guess. If I'm not mistaken, PKCS #8 allows the private key to be encrypted with a key that is derived from the password using PBKDF2. This sounds pretty secure for stor[ing] it somewhere shared to me. Correct me if I'm wrong.
    – zypA13510
    Feb 19, 2022 at 11:25
  • IF the work factor is high enough, and the password good enough, then maybe. But in general, no. The reason for slow password hashing is fundamentally pretty similar to the reason for encrypting private keys: it's so that, if their storage (typically a DB) is breached, you have some margin of time to notify people and change passwords before they get cracked. Putting the key out in the open where multiple people can see it - as opposed to securely inside a user-private directory - means starting that timer immediately.
    – CBHacking
    Feb 19, 2022 at 15:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .