Convert binary encrypted message to ascii armored

[joernheissler]

Hi,
I receive an encryptes message in binary form.
Can pysequoia convert this to the ascii armored form?
I.e. starting with -----BEGIN PGP MESSAGE----- and including the legacy check sum.

[wiktor-k]

Currently no, but this could be implemented by introducing a Message object (just like we have Sig now and for signatures I think it's possible).

Just curious, why do you need to convert them? The decrypt function should happily take binary too, without conversion.

[joernheissler]

I receive encrypted messages from Hashicorp Vault's sys/init function. Those are either in hex or base64. I need to pass the messages to the users for them to decrypt.
I could pass them in binary form to them, but I think it's easier to handle them if they're ascii armored.

[wiktor-k]

I could pass them in binary form to them, but I think it's easier to handle them if they're ascii armored.

Indeed. But you can do so by basically doing (pseudocode) "-----BEGIN PGP MESSAGE-----\n\n" + base64(binary) + "\n-----END PGP MESSAGE-----".

(I just tested it, created binary message via gpg -er wiktor@metacode.biz < statement.txt > statement.txt.pgp then base64 < statement.txt.pgp > statement.txt.enc.asc and inserted markers manually in the editor, gpg -d statement.txt.enc.asc worked fine).

The checksum is not needed and even discouraged in newer versions of the spec.

The only advantage of having a specialized pysequoia function would be validation of this really is a valid PGP message (but even gpg allows armoring/dearmoring anything via --enarmor/--dearmor).

[joernheissler]

The checksum is not needed and even discouraged in newer versions of the spec.

Maybe in the newer spec. But on Debian 12, gnupg 2.2.40 complains if the message's base64 encoding contains no = (i.e. divisible by 3 bytes) and misses the checksum.

I don't know how other software handles it.

[wiktor-k]

Maybe in the newer spec. But on Debian 12, gnupg 2.2.40 complains if the message's base64 encoding contains no = (i.e. divisible by 3 bytes) and misses the checksum.

Right, I guess this is a quirk of that version. I just tried using ==== (four equals signs) instead of the real checksum and gpg did not complain. I've noticed that GnuPG by default wraps at 64 chars (base64 -w 64).