I am fairly new to PGP encryption. I generated a new key pair last week on a Yubikey, while previously I had only used a private key that I generated on my machine. I use thunderbird enigmail for key management. This is probably a stupid question but I don't actually understand how to encrypt an email using the private key stored on my Yubikey. I can decrypt just fine but can't figure out how to compose an encrypted email from the new key. Using my old key pair, it's automatic - how do I actually encrypt using the right private key? At what point do I enter the Yubikey and pin? (I'm not all that technical and I use encryption for one specific project, so I appreciate dumbing down something that is probably very obvious.)
Using keys generated on a Yubikey is a practically identical process to using your old keys, with one extra step of set up.
To use keys stored on a Yubikey, you need "key stubs" registered on your PGP system. Basically, these are references that tell your PGP software "This private key is located on smartcard number #123456." Once you have the stubs to the keys you need, Enigmail should treat the Yubikey-stored keys like any other PGP key.
I'm only familiar with GnuPG, so specifics may vary, but using GPG you need to
Have a copy of the public key imported to your system from a key server or the like.
Import key stubs from your smart card (in this case, your Yubikey) using:
gpg --card-status
After that, checking your private keyring should reflect that you have stubs pointing to private keys stored on a smart card (denoted by the > after sub). I.E.
gpg --list-secret-keys
----------------------------------------------------
sec# rsa2048 2018-01-02 [C] [expires: 2020-01-02]
ABCDEF123456789ABCDEF123456789ABCDEF1234
uid [ ultimate] My Name (My PGP key) <anAddress#somesite.com>
ssb> rsa2048 2018-01-02 [S] [expires: 2018-12-31]
ssb> rsa2048 2018-01-02 [E] [expires: 2018-12-31]
ssb> rsa2048 2018-01-02 [A] [expires: 2018-12-31]
At this point you can use sub keys of CDEF1234 as if there were on your system. Your PGP software ought to handle checking the card is inserted and dealing with PIN entry.
Related
I've been doing some searching and still do not know if this is possible. What I want is for a message to by encrypted by our system and decrypted by a "master key" and also a 3rd party.
This encrypted message needs to be decrypted by 2 entities
-A 3rd party (which we want the control to shut off their ability to decrypt)
-Our system (which we want to always be able to decrypt no matter what, master key?)
From some research I was doing there is a concept of master key and derived keys
Does this following system exist?:
Master Key - can decrypt anything encrypted by derived keys
DerivedKey1 -> Encrypt data with this key and be able to decrypt with Master Key OR DerivedKey1
DerivedKey2 -> Encrypt data with this key and be able to decrypt with Master Key OR DerivedKey2 but NOT derivedKey1
Any terminology I should be using to search for answers would be helpful, also any crypto systems that do this already would be great to know.
Yes, I mean deny any new messages sent from our system to be decrypted
You can encrypt the content with a random key (data key).
Then you can encrypt the data key for each intended recipient (master key and any 3rd party) using its shared or public key.
Hi Crypto experts out there, are there any best practices around distributing an ecnrypted package to multiple end user systems, specially if the end system are offline ones? in context of assymetric crypto.
is it must to create unique pub/pvt key sets [ per end user system] and encrypt the same package many times uniquely with the pub keys, resulting in a specific package per end user system? how will this scale?
will it be a good practice to sign the original private key[ corresponding to pub keys used to encrypt the package] with senders private keys and then enrypt using end user systems pub keys and share it directly with end user? through trusted communication.
or, encrypt the pvt key with end user systems public key, sign with senders private key and re-encrypt[symmetric] this with the hash of certain string uniquely identifying a end user system? This hash should be programtically reproducible using system unique identifiers later during decryption processes. This way, to retreive the original private key to decrypt the package, it will require both a corresponding pub key[end user clients] as well as end user machine [the hash of string to be generated at runtime on end user system.] and senders public key to manage the authenticity?
Thank you for any feedback!
I am not an expert, but as I understand asymmetric encryption, you can generate a key pair in the distribution center.
The private key stays secret in the distribution center.
To each offline client you provide the public key (as a file).
Each client generates a secure password for symmetric encryption, and encrypts it using the public key.
The encrypted symmetric key is sent to the distribution center.
The distribution center should associate the encrypted symmetric password to the client that sent it.
At the time of encrypting the package for the specific client, the distribution center will decrypt the symmetric password using the private key, and use it to encrypt the package.
Then the package can be sent to the client, who will use it's own password to decrypt the package.
I am trying to decrypt a set of files with GnuPG, for which I already have the username and password. However, I cannot seem to be able to do so, even though I have generated a new key with the given credentials. When trying to run
gpg --output result.sc --decrypt myFile.sc.xz.gpg
I get:
gpg: encrypted with RSA key, ID 3662FD5E
gpg: decryption failed: No secret key
I am wondering, which are the steps in decrypting with GnuPG? I followed the instructions here http://linoxide.com/security/gpg-comand-linux-how-to-encrypt-and-decrypt-file/, but still did not get it to work. I have no other key given except for these credentials.
You're missing the private key with 3662FD5E.
I have no other key given except for these credentials.
Without this key, you cannot decrypt the file. The password you have might protect the private key, but without the private key, there's definitely no way to decrypt the file (unless in future, a way is found to crack the encryption, but as of now, pretty much all relevant and actually used algorithms in OpenPGP are believed to be secure).
even though I have generated a new key with the given credentials
Keys are generated from random numbers, you cannot generate the same key again, also when using the same user ID and password.
According to wikipedia (and other sources), asymmetric encryption always works like this:
Party A has a public and private key
Party B encrypts stuff with A's public key
Party A decrypts stuff with their private key
However, I don't want party A to be able to encrypt their own data and only want to them to be able to decrypt it. Using the asymmetric logic this would result in:
Party A has a private key
Party B has a private key (which is party A's public key)
Party B encrypts stuff with their private key
Party A decrypts stuff with their private key
We will be using this for some sort of license generation/checking. Our clients may not generate a license, but the license file must be readable on the client side.
Is this still asymmetric encryption or should I be looking at different methods?
Party A being able to encrypt messages using the public key is absolutely no problem.
Only you could decrypt them (with your private key) and since you have no reason to do so encrypting something with the public key embedded in your application would cause no harm - just a bunch of useless data the user has since he cannot decrypt it.
For the licensing you simply encrypt (or sign - that's enough and then people will be able to read the restrictions etc in the license file but not modidy them) your license file using your private key. The application then decrypts the file using the embedded public key (or validates the signature).
A user extracting the public key and signing a custom license file with it could not use it since it would only work if your private key was embedded in the application (since that's the key necessary to decrypt something encrypted with the public key).
However, he could very well replace your public key with a custom one (where he has the private key, too) and then sign/encrypt his own license file using his private key. That's not a cryptographical issue though - you simply need to add some anti-cracking/modification measures to make it harder to replace the embedded public key. You could do some checksum validations for example.
You have your private key in the safe, and publish your public key. When you create a license you encrypt it with your private key. The client can only decrypt it with your public key.
If you want to restrict your license to a client, ask the client to generate their keypair, and send their public key to you. You then encrypt the license with their public key, then sign it (or encrypt it again) with your private key.
When the client receives the license they will have to
1. verify the signature of (or decrypt) the license you sent them
2. decrypt the verified data using their own private key.
This ensures that 1. only you can send them the license and 2. only they can decrypt it.
What you'd generally do is generate you license on your side, and encrypt it with your private key. Then your client can read it using your public key. This is (very broadly speaking) how certificate schemes (such as used in secure online browsing with HTTPS) work. And yes, that still absolutely counts as asymmetric encryption.
Based on what you're saying, asymmetric encryption is still what you want, it just needs to be done in a different way than you're used to thinking about it.
Let's say you generate a key pair for A. You send A one half of the pair: it doesn't really matter but we'll call it the private half. You encrypt using the public half and send it on to A. Then A can decrypt it. But A won't be able to encrypt a message that appears to come from the A public key since they only have the private half of the key and you can't figure out the other half of the key if you only have half of it, no matter which half you have. So A could only encrypt messages that could be decrypted by the public key that you have kept as a secret.
Of course, as other posters have already said, there are better ways to set up this protocol. Just trying to explain why this is not really an issue once you understand the details of asymmetric encryption and look past what we like to call the key halves and how we usually use them.
You could have a look at Rhino licensing : http://hibernatingrhinos.com/open-source/rhino-licensing/introduction
The other answers already said how to do it ... here just a note that (at least with RSA) the scheme you described in your question is not secure, if it depends on B's key staying secret.
For RSA, the public and private keys are really asymmetric, and you can't simply swap them and expect the same security properties.
If your party B (Bob) encrypts multiple messages with the same public key, an attacker which reads these (ciphertext) messages can with little effort get your public key. The attacker does not get the plaintexts or the private key, but the public key will always become really "public".
For A (Alice), it is even possible to create the public key from the private one, without any message being encrypted with the public one.
I suppose similar caveats are there for other asymmetric cryptosystems - always use them only like they are specified, and proven.
In this case, you would combine two key pairs: B's one to sign/verify the message (to make sure the message was sent by B), and A's one to encrypt/decrypt the message (to make sure only A can read it).
Yes. You can do it with RSA - to do a Diffie-Hellman-like exchange, because not only do the keys from 1 associated pair commute, but keys from different keypairs can commute as well.
alice -> bob: alice.pub
bob -> alice: bob.pub
alice: r = random.secret()
alice -> bob: ( r * (alice.priv * bob.pub) )
bob: r = ( (r * (alice.priv * bob.pub)) * (bob.priv * alice.pub) )
Notice that we did something odd here. We mixed RSA operations from different keypairs in one operation. The objects in parenthesis are effectively a new virtual RSA key, and neither one of these keys is public. Had we tried to create that RSA key directly, either alice or bob would know both keys of the pair. This keypair is effectively a secret key where you write to one end and only the other side can decrypt it, yet you cant decrypt what you wrote yourself, and nobody else can encrypt messages to the other side.
I have never seen anyone mix keypairs like this, but I tested this by writing the code. I had to do something unusual though because normally, applying the private key to the message is for 'signing'. But signing usually hashes the secret and applies the private key to a hash of it; something we do not want. So in my code, once I had the RSA components (D,E,N) extracted into arbitrary precision numbers... ie: decrypt,encrypt,modulus ... I just did:
wormholeSend(me,you,msg) =
(((me ^ {me_D}) \% me_N) ^ {you_E}) \% you_N
The thing that makes it a little tricky is that E (encrypt exponent) is actually a predictable value, but the modulus N is in the public key (E,N). D is private to each party. We need to be careful here, because you and I have a different modulus N.
I did this because I wanted a system where a program is authorized to encrypt keys that can be decrypted by users. Doing this, the user cannot encrypt keys, and the program cannot decrypt them.
Is it possible to encrypt data, such that it can be decrypted with several different keys?
Example:
I've encrypted data with key1, but I want to be able to decrypt with keys 2, 3, and 4.
Is this possible?
GnuPG does multi-key encryption in standard.
The following command will encrypt doc.txt using the public key for Alice and the public key for Bob. Alice can decrypt using her private key. Bob can also decrypt using his private key.
gpg --encrypt --recipient alice#example.com \
--recipient bob#example.com doc.txt
This feature is detailed in the user guide section entitled "Encrypting and decrypting documents"
Yes it's possible
Yes encryption for multiple recipients is possible. Also it seems logical when you think that you might want to be able to read what you've sent to someone and to do so you need to be in the recipients list.
Command line
Here is how to do it through gpg command line (as described in David Segonds' answer):
gpg --encrypt \
--recipient alice#example.com \
--recipient bob#example.com \
clear-message.txt
GUI client
Your GUI must provide a way to encrypt for several people
Mechanism
There is a question on Information Security, GPG File size with multiple recipients?, that explain the encryption mechanism:
GPG encrypts the file once with a symmetric key, then places a header
identifying the target keypair and an encrypted version of the
symmetric key.
[...] When encrypted to multiple recipients, this
header is placed multiple times providing a uniquely encrypted version
of the same symmetric key for each recipient.
GnuPG and PGP clients in general usually encrypt the actual data with a symmetric key called a "session key". The session key is then encrypted with each "recipient key" (i.e. the ones you specify with -r/--recipient). This is sometimes referred to as a hybrid cipher. Right now, I believe GnuPG by default uses an 256 bit session keys and AES to encrypt the plaintext data to that AES-256 session key, and your recipient keys are your RSA/DSA/ECDSA/etc. assymetric key in this case.
One reason for doing it this way is that symmetric cryptographic algorithms like AES are generally a lot faster than asymmetric ones like RSA. GnuPG thus only has to encrypt ~256 bits (the session key) with RSA, and can use AES to encrypt the data (as large as you want it to be!) with that session key. Intel machines even have a built in instruction, AES-NI, to do some steps of the algorithm in hardware, which makes GnuPG extra snappy at encrypting/decrypting data.
Another reason for doing it this way is that it allows PGP-encrypted documents to be encrypted to multiple parties without having to double the size of the document. Notice that when you specify multiple recipients for an encrypted document (e.g. gpg -ea -r Alice -r Bob -o ciphertext.asc), the encrypted document that gets stored (ciphertext.asc) is not 2x as large as if you had just encrypted it to Alice.
See also the --show-session-key parameter in the gpg man page to be able to decrypt just the session key, for example to allow a third party to decrypt a document that is encrypted to you without having to transfer to them your private key or the plaintext data.
Yes, it's possible. Google "multiparty encryption" for a start.
AFAIK, there are no drop 'em in and use 'em packages for it though.
-- MarkusQ
P.S. For a sketch of how it could be done, consider this. The encrypted message consists of:
the payload, encrypted with a one-time pad
the one time pad, encrypted with key1
the one time pad, encrypted with key2
...
the one time pad, encrypted with keyN
The recipient who hold key i just decrypts their copy of the pad with their key, and then decrypts the payload.
However, this is just a proof that it could be done and would suck as an actual implementation. If at all possible, you should avoid rolling your own encryption. If you don't understand why, you should definitely avoid rolling your own encryption.
-----Edit ------------
If I'm wrong and the Gnu tools do that, use them. But I can't seem to find any information on how to do it.
Multiple (more than two) key RSA is maybe like this - well i'm not a mathematician, so this algorithm is not necessarily secure, i just want to give an idea with it.
m=p*q*r; p,q,r are big prime numbers
fi(m)=(p-1)(q-1)(r-1)
d==(e1*e2*e3*...*ei)^(-1) (mod fi(m)); e1...ei are arbitrary numbers, d is calculated to fulfill the equation
y1==x^e1 (mod m)
y2==y1^e2 (mod m)
y3==y2^e3 (mod m)
...
x==yi^d (mod m)
This algorithm could be used for example to increase the speed of The Onion Router.