GnuPG usage for automatic remote decryption

[Peter Lebbing]

On 11/04/18 14:51, Mike Inman wrote:
> Encrypt the message with a symmetric algorithm, adding salt and a
> hash/checksum to ensure validity.

I'm not sure what you're salting exactly, but anyway, this is not the focal
point of my reply. By the way, there are many ways to do what you describe in
such a way that the hash is utterly pointless and not authentication. For a
sweet example, check the use of CRC inside a stream cipher in WEP, the original
encryption layer of wireless LANs :-). Stream cipher + CRC = major D'oh!

> When I studied cryptography at Uni in the 1980s, they taught that
> private/public key encryption was a more or less interchangeable affair -
> the only difference between a private key and a public key is the manner in
> which they are handled.

This is only true for some algorithms and not for others, and even then only to
some extent.

For example, with RSA, encryption is: encrypt message with random key,
RSA-encrypt this random key to the private key of the intended recipient.

RSA signatures is the opposite, where a hash matching the signed data is
RSA-"encrypted" to the public key. Only the private key can "encrypt" to the
public key, so when anybody uses the public key to "decrypt" it, they can verify
the hash matches and was produced by the holder of the private key.

So for encryption, you choose the number and send it to the private key.

In signing, you obtain the number by hashing and send it to the public key.

They are mathematically equivalent. But note that the public and private key are
not interchangeable. The public exponent usually has a very low Hamming weight
while the private exponent is derived after fixing the public exponent. Simply
exchanging public and private variables would not give an equivalent keypair,
although mathematically they'd still work.

> As such, I am a little disappointed in the GnuPGP
> implementation that doesn't allow encryption with the private key to serve
> as authentication and obscurity of the message - our 
> *** not private, but public *** key will be
> obscured, but obviously not secured since attackers may have control of the
> standard computer system it is contained in.

Obscurity can be obtained by many low-complexity methods and is not a goal of
OpenPGP. There is no O in PGP :-). (Oh, and the GnuPG implementation wouldn't
usually add such a major deviation from the OpenPGP standard.)

And how do you see this as authentication? The way you describe it, I'm thinking
you simply reverse the roles of the public and private key, and you are thus
encrypting the session key to the public key with your private key instead of
the other way around. What does this achieve? As you'd then be sharing the
symmetric encryption key with the world, anybody could re-encrypt their
malicious data to that symmetric key, tag the so-called "encrypted" asymmetric
algorithm output that only the private key can produce on and presto,
"authenticated" data. If this is what you meant, well, I've just explained it's
not authentication. If this is not what you meant, please elaborate.

Okay, that was a wall of words with way too long sentences. So let me combine it
with an example.

1 - We will use an RSA keypair with modulus n, public exponent e and private
exponent d

2 - Choose symmetric key: sk = 0x2dfe0af9eeb3352c390791f4710a63da

3 - Encrypt "Transfer $ 1000 to Mike" using AES and the symmetric key sk from 2.
Let's call this result "BONAFIDEDATA"

4 - Compute s = sk^d mod n
This is "encrypting" the symmetric key sk to the public key. It is equal to what
PKCS#1 would consider the signature primitive RSASP1, mathematically equivalent
to the decryption primitive RSADP.

5 - Send s + "BONAFIDEDATA" to recipient

6 - Recipient computes sk = s^e mod n
This is "decrypting" the symmetric key sk using the public key. It is equal to
what PKCS#1 would consider the verification primitive RSAVP1, mathematically
equivalent to the encryption primitive RSAEP.

7 - Recipient decrypts "BONAFIDEDATA" using the correct sk, yielding "Transfer $
1000 to Mike".

8 - Mike has spending money.

Now I come along.

1 - Intercept or observe on the network s + "BONAFIDEDATA". Preventing reception
is optional.

2 - I compute sk = s^e mod n
This is public data.

3 - Encrypt "Transfer $ 10,000 to Peter" using AES and sk, which we correctly
determined to be 0x2dfe0af9eeb3352c390791f4710a63da. Let's call the result
"FAKEDDATA"

4 - Send s + "FAKEDDATA" to recipient

5 - Recipient computes sk = s^e mod n
This is "decrypting" the symmetric key sk using the public key. It is equal to
what PKCS#1 would consider the verification primitive RSAVP1, mathematically
equivalent to the encryption primitive RSAEP.

6 - Recipient decrypts "FAKEDDATA" using the correct sk, yielding "Transfer
$ 10,000 to Peter".

7 - Peter has spending money, and then some.

> Unless I'm missing something?

If you were to use OpenPGP encryption instead of a shared symmetric key, key
management and access revocation becomes much simpler. Additionally, you'd be
encrypting much less data with the same symmetric key. So there are some more
gotcha's with a static symmetric key: don't choose a symmetric algorithm with a
64-bit block size, etcetera. That's the thing about inventing your own crypto,
even at such a high level. It seems much simpler to me to use a private key that
is stored in plaintext on your recipient machine. Or TLS with the same, which by
the way is an extremely common setup, much more so than a passphrase-less
OpenPGP private key, even though they are the same principle.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180411/beb7fc22/attachment-0001.sig>