Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to create a TrueCrypt container which can be accessed by multiple people. The container itself can be stored anywhere, e.g. in a shared folder in Dropbox or Google Drive, ...

I would like to add each person's SSH public key to the container encryption mechanism, so that they can use their SSH private key and passphrase to access the container's content.

Is this possible? How?

share|improve this question

If the ssh keys are RSA keys then it should be possible to build such a system. Whether anyone has done so already I do not know. If the ssh keys are DSA or ECDSA then afaict you are out of luck.

What you would do is use everyone's RSA public keys to encrypt the shared secret that decrypts the container. openssh uses it's own format for public keys so you will most likely need to convert the public key first (certainly my version of openssl could not read a public key in ssh format). The private key format seems to be compatible between openssl and openssh.

You would then need some client code that dealt with decrypting the shared secret and unlocking the container.

To convert the public key you can use ssh-keygen but you need a recent version, I did it in a sid chroot.

ssh-keygen -f -e -m PKCS8 >

We can then use the public key to encrypt stuff and the private key to decrypt it using openssl.

plugwash@debian:~$ echo this is a test | openssl rsautl -inkey /chroots/sid/ -pubin -encrypt > temp.rsa
plugwash@debian:~$ openssl rsautl -inkey ~/.ssh/id_rsa -decrypt < temp.rsa
Enter pass phrase for /home/plugwash/.ssh/id_rsa:
this is a test

All that's left is to write a bit of plumbing to take the decrypted secret and feed it into truecrypt. From some googling for "truecrypt passphrase pipe" it looks like a simple pipe would suffice. Perhaps also some code to pick the right copy of the secret to decrypt based on whose key is being used to obtain access.

P.S. there are apparently some theoretical concerns about the security of using the same RSA key for both signing and encryption though many existing protocols do use it as part of their design.

share|improve this answer

The data itself can only be encrypted by a single key without having to encrypt the information multiple times (which also wouldn't allow for information to be shared between users). What you would want to do is have a master key which is then protected multiple times, once for each of the users. Each user could then access the key to access the container by using their own key.

I've not worked with TrueCrypt myself, so I'm not sure if it is viable to do this in an automated way or not. It's worth noting that this would also likely not provide a guarantee that any one user not masquerade as another. It would be far more complicated to pull something like this off as I would think it would require some kind of a versioning system where each revision was stored, signed by the user and then applied, but then changes would have to be replayed (either to get the current state of the data, or played in reverse to validate the revision history hasn't been tampered with).

share|improve this answer
I am not so much afraid of any changes. The container can sit in a versioned folder such as provided by Dropbox which allows to recover older versions. I agree it would be nice to have versioned contend but not a must. – JJD Feb 4 '13 at 15:20
@JJD - yeah, it was more a matter of if you wanted to guarantee attribution or have differing permissions within the container for each user. As long as it is just differing credentials, but all are acting like the same "user", then what I described should work. Hopefully someone with knowledge of TrueCrypt can comment on if it is possible to do what I described with built in functionality. – AJ Henderson Feb 4 '13 at 15:25
I have to admit what you suggest is what I am trying to avoid. I do not want a 2-step-authentification as you described with the master key. I would like to leave every user with its own passphrase - no more. – JJD Feb 4 '13 at 15:44
@JJD - yeah, it will have to do what I'm talking about behind the scenes since the need for a common key is a limitation of the encryption in use, but the client may be able to handle the key management I described. It's a pain to do manually, that's actually how a friend of mine and I do it with a shared KeePass DB. We each have a KeePass DB that is protected with our password and holds a copy of the password to the common KeePass DB. It's an annoying extra step to go through. I hope that TrueCrypt supports handling the key management for you and I'm also very interested in the answer. – AJ Henderson Feb 4 '13 at 16:27

SSH private keys (for users) are nominally meant to be used only for signatures and this is rather fundamental, especially for DSA keys. In a SSH connection, the actual key exchange uses Diffie-Hellman but the private DH keys are never stores. So you cannot encrypt some data which the owner of a given SSH private key could decrypt.

For such jobs, you want to use OpenPGP (in particular its Free/OpenSource instance GnuPG, which every decent Linux distribution already contains).

share|improve this answer
Good point about the SSH keys. I guess I kind of assumed that the user was talking about a key that could normally be used to decrypt the volume and was simply mislabeling them as SSH keys, but it is worth verifying if this was the case. – AJ Henderson Feb 4 '13 at 16:30
It is fundamental for DSA and ECDSA but for RSA (which is by far the most common type of key used for SSH in my experiance) there is nothing stopping you from extracting the key and using it to encrypt something. – Peter Green Dec 16 '15 at 12:52

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.