Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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

2 Answers 2

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

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.