rnp still looks for keyrings when only using symmetric encryption

[jpo234]

Description

Trying to decrypt a gpg encrypted file with rnp fails and rnp is looking for keyrings even if the file doesn't use public key encryption

Steps to Reproduce

1. use gpg to encrypt a file: gpg -c plaintext.txt
2. check encrypted file: file plaintext.txt.gpg plaintext.txt.gpg: GPG symmetrically encrypted data (AES256 cipher)
3. try to decrypt with rnp: rnp --decrypt --output=decrypted.txt plaintext.txt.gpg [init_file_src() /home/jpo/src/rngpg/rnp-0.12.0/src/librepgp/stream-common.cpp:368] can't stat '/home/jpo/.rnp/pubring.gpg' [rnp_key_store_load_from_path() /home/jpo/src/rngpg/rnp-0.12.0/src/librekey/rnp_key_store.cpp:193] failed to read file /home/jpo/.rnp/pubring.gpg [rnp_key_store_load_keys() /home/jpo/src/rngpg/rnp-0.12.0/src/librekey/rnp_key_store.cpp:110] cannot read pub keyring fatal: failed to load keys

Expected Behavior

rnp should be able to decrypt a gpg encrypted file

Actual Behavior

rnp fails to decrypt and looks for unneeded keyrings

[jpo234]

We want to use the OpenPGP message format in an application where asymmetric encryption doesn't make sense. I have an implementation that uses gpgme, but since this will go into an embedded system, the LGPL is considered a sub-optimal solution. What is the current state of symmetric encryption with rnpgp?

[dewyatt]

The issue here is that rnp is exiting when there are no keys in the homedir. Try running rnpkeys --gen-key first (or rnp --homedir=<homedir-with-keys> --decrypt).

Either way it's a bug.

[ronaldtse]

@jpo234 thank you for reporting! Indeed this is a bug, we will get this fixed. @dewyatt could you help with this?

[jpo234]

@dewyatt and @ronaldtse Thanks for the response. After generating the key pair I could indeed decrypt the file. However, there is still something fishy going on: Trying to symmetrically encrypt a file contains an asymmetrically encrypted session key that is not present in an equivalent gpg encrypted file: I'm using: rnp --encrypt --output=ciphertext.rnp --passwords 1 --cipher=AES-256 xx This is what I get:

rnp --list-packets ciphertext.rnp 
:off 0: packet header 0xc1c04c (tag 1, len 268)
Public-key encrypted session key packet
    version: 3
    key id: 0x6a082ac5fdb576f5
    public key algorithm: 1 (RSA)
    encrypted material:
        rsa m: 2046 bits
:off 271: packet header 0xc32e (tag 3, len 46)
Symmetric-key encrypted session key packet
    version: 4
    symmetric algorithm: 9 (AES-256)
    s2k specifier: 3
    s2k hash algorithm: 8 (SHA256)
    s2k salt: 0x8c3b26838d738db0
    s2k iterations: 212 (10485760)
    encrypted key: 0x1f387a4205a4ee5cb2dbdd0c5577156202e3756f88bc29fb6c11ed1f46b0b18a51 (33 bytes)
:off 319: packet header 0xd259 (tag 18, len 89)
Symmetrically-encrypted integrity protected data packet

Funny thing is, I didn't even specify a recipient, so what public key did rnp actually pick for this part? The Public-key encrypted session key packet part is not present in a gpg encrypted file:

rnp --list-packets ciphertext.pgp 
:off 0: packet header 0x8c0d (tag 3, len 13)
Symmetric-key encrypted session key packet
    version: 4
    symmetric algorithm: 9 (AES-256)
    s2k specifier: 3
    s2k hash algorithm: 2 (SHA1)
    s2k salt: 0x61c6467450d6d559
    s2k iterations: 255 (65011712)
    encrypted key: 0x (0 bytes)
:off 15: packet header 0xd256 (tag 18, len 86)
Symmetrically-encrypted integrity protected data packet

[ni4]

@jpo234

Trying to symmetrically encrypt a file contains an asymmetrically encrypted session key that is not present in an equivalent gpg encrypted file

This is because you use --encrypt, which enables PK-encryption and picks the default key (while --passwords also adds password-based encryption). To do password-only encryption you should use -c or --symmetric.

[jpo234]

@ni4

To do password-only encryption you should use -c or --symmetric.

I'm using:

rnp --version
rnp 0.12.0
All bug reports, praise and chocolate, please, to:
Ribose Inc. <packaging@ribose.com>

There is neither a --symmetric nor a -c option:

rnp
rnp 0.12.0
All bug reports, praise and chocolate, please, to:
Ribose Inc. <packaging@ribose.com>
Usage: rnp --help OR
        --encrypt [--output=file] [options] files... OR
        --decrypt [--output=file] [options] files... OR
        --sign [--detach] [--hash=alg] [--output=file]
                [options] files... OR
        --verify [options] files... OR
        --cat [--output=file] [options] files... OR
        --clearsign [--output=file] [options] files... OR
        --list-packets [options] OR
        --dearmor [--output=file] file OR
        --enarmor=<msg|pubkey|seckey|sign> 
                [--output=file] file OR
        --version
where options are:
        [-r, --recipient] AND/OR
        [--passwords] AND/OR
        [--armor] AND/OR
        [--cipher=<ciphername>] AND/OR
        [--zip, --zlib, --bzip, -z 0..9] AND/OR
        [--aead[=EAX, OCB]] AND/OR
        [--aead-chunk-bits=0..56] AND/OR
        [--coredumps] AND/OR
        [--homedir=<homedir>] AND/OR
        [-f, --keyfile=<path to key] AND/OR
        [--keyring=<keyring>] AND/OR
        [--keystore-format=<format>] AND/OR
        [--numtries=<attempts>] AND/OR
        [-u, --userid=<userid>] AND/OR
        [--maxmemalloc=<number of bytes>] AND/OR
        [--verbose]

[ni4]

@jpo234 looks command just didn't get into the help message. Created PR #990. Thanks for noticing!

[rrrooommmaaa]

Funny thing is, I didn't even specify a recipient, so what public key did rnp actually pick for this part?

Looks like this bug isn't solved yet.

Repro steps:

rnp -c --password DUMMY --output test.enc test.txt
rnp --decrypt --password DUMMY --output test.dec test.enc

The first command always works. The second will work only if I add an option --homedir <any existing home dir>

@ni4 Should we give priority to this? I was planning to use this sample as a no-file example of Homebrew formula test

[ni4]

@rrrooommmaaa Feel free to take it. However, that would require some considerations since at the beginning we cannot say for sure whether keyring is needed or not. For instance, --password DUMMY may be password to the secret key, to which test.enc is encrypted. Also even if file is symmetrically-encrypted, it may have signatures inside. So I see the following possible solutions:

• load keyring(s) on demand or just do not fail prematurely if pubring or secring is not present
• add --disable-keyring option
• add some specific meaning to the --keyfile="" option.

As for me, --disable-keyring looks like a quick solution, while first option would be more universal.