Dear sequoia team,
I see that the default parameter for encryption is pad.
I assume that the pad function adds some random chars to the final message, prior encryption.
I would like to ask, if it makes sense to you, if it would be possible to have an additional integer parameter for pad like --compression pad 1024, or say 2048 etc., which users can use, so that they always can choose an integer value they like, depending on their message size, to always have equal message(s) in size?
A use case for that would be the Usenet group alt.anonymous.messages, were users could then post public key encrypted messages, done with a pub key, without a UID, which then would have always the same size.
Best regards Stefan
Hi Stefan,
Thanks for the suggestion.
On Wed, 13 May 2020 18:25:04 +0200, Stefan Claas wrote:
I see that the default parameter for encryption is pad.
I assume that the pad function adds some random chars to the final message, prior encryption.
I would like to ask, if it makes sense to you, if it would be possible to have an additional integer parameter for pad like --compression pad 1024, or say 2048 etc., which users can use, so that they always can choose an integer value they like, depending on their message size, to always have equal message(s) in size?
A use case for that would be the Usenet group alt.anonymous.messages, were users could then post public key encrypted messages, done with a pub key, without a UID, which then would have always the same size.
I opened issue #508:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/508
Two issues come to mind:
- The sender can't really force the recipient to use a User ID-less key. So, you'll need to somehow establish that convention.
- You'll probably want to make sure the recipients are anonymized.
Normally the Key ID is stored in the PKESK packet [1] so that the recipient knows if the message is intended for them, and what key they should use to decrypt it. In gpg you can use `--throw-keyids` to "hide" the recipient. This sets the key id field to 0. Then, to decrypt a message, you'd do trial encryption.
Hiding Key IDs in this way doesn't completely hide the recipient. In particular, the size of the PKESK's payload reveals the size of the public key. That is, a 4k RSA key has a different sized PKESK from a 2k RSA key, and from an ECC key.
Neal
[1] https://tools.ietf.org/html/rfc4880#section-5.1
The body of this packet consists of:
...
- An eight-octet number that gives the Key ID of the public key to which the session key is encrypted. If the session key is encrypted to a subkey, then the Key ID of this subkey is used here instead of the Key ID of the primary key.
Neal H. Walfield wrote:
Hi Neal,
I opened issue #508:
Thanks for considering this feature, much appreciated!
Two issues come to mind:
- The sender can't really force the recipient to use a User ID-less key. So, you'll need to somehow establish that convention.
Correct, people usually tell each other, before doing so.
You'll probably want to make sure the recipients are anonymized.
Normally the Key ID is stored in the PKESK packet [1] so that the recipient knows if the message is intended for them, and what key they should use to decrypt it. In gpg you can use `--throw-keyids` to "hide" the recipient. This sets the key id field to 0. Then, to decrypt a message, you'd do trial encryption.
Hiding Key IDs in this way doesn't completely hide the recipient. In particular, the size of the PKESK's payload reveals the size of the public key. That is, a 4k RSA key has a different sized PKESK from a 2k RSA key, and from an ECC key.
I did not thought about the key-id, my thought was only as long as no 3rd party has access to someones key ring it would be sufficient.
People also use sometimes additionally symmetric encryption on top of that, so that the pub keys data is hidden as well.
Best regards Stefan
-
Neal H. Walfield -
Stefan Claas