bugDistributed Privacy Guard - Bugs: bug #57098, Keyrings must be armored

 
 

bug #57098: Keyrings must be armored

Submitted by:  Justus Winter <teythoon>
Submitted on:  Tue 22 Oct 2019 10:35:25 AM UTC  
 
Category:  Source Code Severity:  2 - Minor
Item Group:  Feature Request Status:  Ready For Test
Privacy:  Public Assigned to:  Heiko Stamer <stamer>
Open/Closed:  Open

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Tue 19 Nov 2019 12:24:53 PM UTC, comment #11: 

I can confirm that I can now use unarmored public keys and messages.

I'd prefer to also have the autodetection for secret keys.  Why is it useful to return an error instead?

Justus Winter <teythoon>
Sun 17 Nov 2019 03:16:55 PM UTC, comment #10: 

I've adapted the change to all other programs of DKGPG, however, only for inputs and keyrings (i.e. not for private keys).

Heiko Stamer <stamer>
Project AdministratorIn charge of this item.
Mon 04 Nov 2019 09:17:59 PM UTC, comment #9: 

I've added a stupid simple auto-detect mechanism in dkg-encrypt by commit cfd4d3b63946fb3504124fa89239d78f5fe33e17. Option -b is now used for setting the output format only.

@teythoon Please, can you check whether this works for you?

Heiko Stamer <stamer>
Project AdministratorIn charge of this item.
Wed 30 Oct 2019 08:47:08 PM UTC, comment #8: 

Yes, indeed. It was a design criterion that any input/ouput of DKGPG should be armored, because the included checksum is a weak indicator for the integrity of data. Later the option "-b" has been added, basically to support fuzzing with zzuf.

I will implement an auto-detect feature for input, if there is some time left between holidays.

Heiko Stamer <stamer>
Project AdministratorIn charge of this item.
Mon 28 Oct 2019 10:14:33 PM UTC, comment #7: 

> Do you have applied the option "-b" for binary output and non-armored keyring input?


Ah, I didn't read your message carefully enough to realize that I need to use -b to use non-armored keyrings.  Furthermore, this clashes with my mental model and my expectations.  I expect -b to toggle armoring the output, and expect the implementation to detect the input format.

I expect armor to be applied to OpenPGP data in motion, while I expect my keyring to sit on my disk somewhere.

In the end, this is of course a policy or design decision, but to avoid people like me tripping over this, I'd suggest to align dkgpg's behavior with the other implementations, which are happy to consume unarmored keyrings independent of the selected output format.

Justus Winter <teythoon>
Mon 28 Oct 2019 06:21:00 PM UTC, comment #6: 

comment #2:

> Works for dkg-encrypt, though the same restriction applies to dkg-decrypt's '-y' option.


Let's see first, whether it is fixed for dkg-encrypt. Then I can apply the changes to all other programs.

Heiko Stamer <stamer>
Project AdministratorIn charge of this item.
Mon 28 Oct 2019 06:18:18 PM UTC, comment #5: 

comment #3:

> I'm sorry, I don't think it is fixed for dkg-encrypt either.


Do you have applied the option "-b" for binary output and non-armored keyring input?

Heiko Stamer <stamer>
Project AdministratorIn charge of this item.
Mon 28 Oct 2019 04:33:27 PM UTC, comment #4: 

Same with dkg-sign, dkg-verify.

Justus Winter <teythoon>
Mon 28 Oct 2019 11:16:43 AM UTC, comment #3: 

I'm sorry, I don't think it is fixed for dkg-encrypt either.  If I drop my workaround armoring the keyring, I get:

Unspecified engine error.  Status: exit code: 255, stderr:
INFO: using LibTMCG version 1.4.0
WARNING: cannot use the given keyring
ERROR: encryption key not found in keyring

Justus Winter <teythoon>
Mon 28 Oct 2019 10:08:15 AM UTC, comment #2: 

Works for dkg-encrypt, though the same restriction applies to dkg-decrypt's '-y' option.

Justus Winter <teythoon>
Sun 27 Oct 2019 08:12:56 AM UTC, comment #1: 

For dkg-encrypt this issue has been fixed by commit 4754e7e0ac5a7658c6908b8267a59c80d741d021. The existing option "-b" now covers non-armored keyrings.

@teythoon Please, can you confirm that it is solved?

Heiko Stamer <stamer>
Project AdministratorIn charge of this item.
Tue 22 Oct 2019 10:35:25 AM UTC, original submission:  

Using keyrings that are not armored does not seem to work:

% file alice*
alice:         data
alice.armored: PGP public key block Secret-Key
% sq inspect alice
alice: Transferable Public Key.

    Fingerprint: EB85 BB5F A33A 75E1 5E94  4E63 F231 550C 4F47 E38E
Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm
Public-key size: 256 bits
  Creation time: 2019-01-22T11:56
       Keyflags: certification, signing

         Subkey: EA02 B24F FD4C 1B96 616D  3DF2 4766 F6B9 D5F2 1EB6
Public-key algo: ECDH public key algorithm
Public-key size: 256 bits
  Creation time: 2019-01-22T11:56
       Keyflags: transport encryption, data-at-rest encryption

         UserID: Alice Lovelace <alice@openpgp.example>

% dkg-encrypt --verbose -k alice -r EB85BB5FA33A75E15E944E63F231550C4F47E38E -i foo
INFO: using LibTMCG version 1.4.0
WARNING: cannot use the given keyring
ERROR: encryption key not found in keyring
% dkg-encrypt --verbose -k alice.armored -r EB85BB5FA33A75E15E944E63F231550C4F47E38E -i foo
INFO: using LibTMCG version 1.4.0
WARNING: recipient does not state support for AEAD Encrypted Data Packet; AEAD disabled
WARNING: selected algorithm is none of the preferred AEAD algorithms
-----BEGIN PGP MESSAGE-----

wV4DR2b2udXyHrYSAQdARrEhxnpRvpwoeNcEJXOew0Otg1EMdOXyCMrapjfCgFUw
k8RUc/HVuIkXTr87PKcyYCRpx9A4LX8qebaipNbVu604J0wDBYWl0CmjGJ5c+DzE
0sB2AXVmVvMpX345E0ASPs1kunc1+c+cpUJ/q0EuRK7YIX8ecqAC2M5wRtT0uGHV
arSr43IuUXBUpC9ssaDxrEnUrPDWnYfM7iskG/H3hGSDA684zokER+v/uwZpWdGX
lyMTqf6OHITYqQ9OBmzZRgWWcvmTy9Y+zs1cPvgmdDEyj3Nkd0h8yuU8u1LUb4Zd
zy2fS/bics/k+jqI+B0z5bKRKm1h19I7zBYcytxm9BpkKolYubTIFZff5cSvOi3k
i2Vo7IKrgUmaTaGFZANBNo8uXurOh38yS88fgvsghxAEOw8WhRomqko/GyBYWOMI
J11zL0q2TU720If+q8hbssgM34dm+BaLWGinW/nIGw6vLuQ1lGCQL03uQ9ecRSpU
FKfV6s1Telrsu4l6DX2C1RXuobf0LwJaxA==
=+7Xc
-----END PGP MESSAGE-----

Justus Winter <teythoon>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by teythoon (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-04 stamer StatusIn Progress => Ready For Test
    2019-10-30 stamer Severity3 - Normal => 2 - Minor
    2019-10-28 stamer StatusReady For Test => In Progress
    2019-10-27 stamer StatusIn Progress => Ready For Test
    2019-10-26 stamer CategoryNone => Source Code
        Item GroupNone => Feature Request
    2019-10-26 stamer StatusNone => In Progress
    2019-10-25 stamer Assigned toNone => stamer

    Back to the top


    Powered by Savane 3.5