6 ms·

Sq, Sequoia PGP's CLI, Released

112 points by upofadown 6y ago

colineartheta 6y ago
I could be mistaken, but it looks like the only thing they are missing (and acknowledge - kudos) is the ability to create multiple sub-keys i.e. a "master" public and private key that only you know, with subsequent signing and certificate sub-keys that can be revoked that are used for actual use-cases. Considering this is the recommended arrangement of your personal keyring (per the Debian docs, anyway), this seems like a rather large oversight. Holding out hope it will be implemented in future releases, it'd be great to have another alternative to GnuPG. (And please, I get it - PGP needs replaced, it has flaws, blah blah blah. That's not what Sequoia is trying to do.) Edit: I was wrong - if you read below, this is clarified.
- nwalfield 6y ago
  I think you've misunderstood something. sq has no problem generating certificates with subkeys. Here's the default structure. Notice that we actually include a separate signing subkey by default. This makes it harder to use a data signature where e.g. a self signature is expected and vice verse. This can help protect against some collision attacks, among others. $ sq key generate -u '<alice@example.org>' --export /tmp/alice.pgp; sq inspect /tmp/alice.pgp /tmp/alice.pgp: Transferable Secret Key. Fingerprint: 99E2 68B5 F5A2 45E9 4A9F A1FB F10A BDD2 C1BC 2478 Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm Public-key size: 256 bits Secret key: Unencrypted Creation time: 2021-02-15 21:34:45 UTC Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S) Key flags: certification Subkey: E54F CB2B 4619 FDB9 680A 974C 94D7 9D77 395B 8A7C Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm Public-key size: 256 bits Secret key: Unencrypted Creation time: 2021-02-15 21:34:45 UTC Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S) Key flags: signing Subkey: 62BF 9E6B C022 D3FB 681F 5279 2B09 341C EDFE 0AF9 Public-key algo: ECDH public key algorithm Public-key size: 256 bits Secret key: Unencrypted Creation time: 2021-02-15 21:34:45 UTC Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S) Key flags: transport encryption, data-at-rest encryption UserID: <alice@example.org>
  - colineartheta 6y ago
    I wondered if I was misunderstanding something, thank you for the response and correction. It was, “For instance, it is not currently possible to add new subkeys to a certificate”, that I thought was acknowledging this, but looking closer it seems to just be different terminology [0] than I’m familiar with. Looking forward to giving this a try! [0]https://wiki.debian.org/Subkeys https://wiki.debian.org/Subkeys
    - nwalfield 6y ago
      Right. The sq cli does not have an subcommand to add new subkeys to an existing certificate. But it can use such certificates, and when it generates a certificate, it, by default, generates a certificate with subkeys. This functionality will, of course, be added to sq (it is possible to do this using the library). We just haven't gotten to it yet. It's not that the functionality is hard to implement. But, we want to have a clean CLI, and there are many possible options. We want to expose them in a sensible way that does not overwhelm the user.
adkadskhj 6y ago
Any idea when the high level crate will have parity with the CLI? Or perhaps, UX parity? I ask because the CLI looks fairly understandable (to a crypto-dunce like me), but the high level API in readme says: > Please note that as of this writing the high-level API is very incomplete. I'm also not sure what crate they refer to, because there is no `sequoia` crate on docs.rs, and their link points to the root of the repo which is a workspace without a crate. Perhaps they mean sequoia-openpgp[1], but so far that interface does not look similarly high level to that of the CLI. Anyway, just asking because i often write apps that use signing/encryption/etc for data at rest, and Sq looks neat. [1]: https://docs.rs/sequoia-openpgp/1.0.0/sequoia_openpgp/index.html https://docs.rs/sequoia-openpgp/1.0.0/sequoia_openpgp/index....
- nwalfield 6y ago
  Sequoia consists of a number of components. There is the low-level crate. We released version 1.0 of that in Dec. 2020. There is sq, the CLI tool. We released that a few weeks ago. We've barely started work on the high-level interface. Just because we plan to write a high-level tool, doesn't mean the low-level crate is hard to use. On the contrary, our experience is that it is pretty easy to use and actually does a good job hiding a lot of the low level details that don't need to be tweaked. For instance, I ported the pep engine from gpgme (GnuPG's high-level interface) to Sequoia's low-level interface. The initial port required about half as many lines of code.
nitsky 6y ago
Does the sequoia CLI have support for smartcards like yubikeys? I checked the issue tracker and didn't see any information.
- darkr 6y ago
  The library didn't, last time I looked
- glsdfgkjsklfj 6y ago
  aren't those only to fetch/store certs? can't you just pipe the proprietary(?) utility?
  - upofadown 6y ago
    They can just be used for key storage. But for OpenPGP the device is normally used as a sort of an air gapped system. The secret key information is kept on the device and the operations requiring that information are done directly on the device. It is possible and normal for even the owner to have no access to the secret key information. An advantage of a open and well documented offline cryptography standard. You can do stuff like that.
    - glsdfgkjsklfj 6y ago
      isn't a closed implementation adversarial to those benefits? I mean any implementation can handle the signing etc, as the operations are an open standard. But running the actual pgp implementation on a system you have no access to sources, can't really see the advantage of just using an old laptop to have truly airgapped system (plugging your proprietary device on a connected computer doesn't look that airgapped to me)
      - upofadown 6y ago
        Some do claim that the software on the key is open source. I have not looked that deeply into those claims. Random example: * https://github.com/trustcrypto https://github.com/trustcrypto
bugmen0t 6y ago
Is there a guide for switching from gpg on the cli to sq? Specifically, I'm not sure how to move keys from my gpg keyring to sq.
- nwalfield 6y ago
  Sequoia does not (yet) have feature parity with GnuPG. Several important components are missing including a public key store. In GnuPG, the public key store is mandatory. In our discussions with application developers, in particular, developers working on server software, this requirement was more of a hindrance than a help. Thus, in Sequoia we decided it needs to be as easy to bring your own key store (e.g., an existing database) as to use ours. That said, on the desktop, it is quite useful to have a shared key store--you don't want to import keys into each of your OpenPGP-using applications. We hope to finish our [public key store](https://docs.sequoia-pgp.org/sequoia_store/index.html https://docs.sequoia-pgp.org/sequoia_store/index.html) this year along with other features that end users need and expect.

112 points by upofadown 6y ago

I could be mistaken, but it looks like the only thing they are missing (and acknowledge - kudos) is the ability to create multiple sub-keys i.e. a "master" public and private key that only you know, with subsequent signing and certificate sub-keys that can be revoked that are used for actual use-cases. Considering this is the recommended arrangement of your personal keyring (per the Debian docs, anyway), this seems like a rather large oversight. Holding out hope it will be implemented in future releases, it'd be great to have another alternative to GnuPG. (And please, I get it - PGP needs replaced, it has flaws, blah blah blah. That's not what Sequoia is trying to do.) Edit: I was wrong - if you read below, this is clarified.

nwalfield 6y ago
I think you've misunderstood something. sq has no problem generating certificates with subkeys. Here's the default structure. Notice that we actually include a separate signing subkey by default. This makes it harder to use a data signature where e.g. a self signature is expected and vice verse. This can help protect against some collision attacks, among others. $ sq key generate -u '<alice@example.org>' --export /tmp/alice.pgp; sq inspect /tmp/alice.pgp /tmp/alice.pgp: Transferable Secret Key. Fingerprint: 99E2 68B5 F5A2 45E9 4A9F A1FB F10A BDD2 C1BC 2478 Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm Public-key size: 256 bits Secret key: Unencrypted Creation time: 2021-02-15 21:34:45 UTC Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S) Key flags: certification Subkey: E54F CB2B 4619 FDB9 680A 974C 94D7 9D77 395B 8A7C Public-key algo: EdDSA Edwards-curve Digital Signature Algorithm Public-key size: 256 bits Secret key: Unencrypted Creation time: 2021-02-15 21:34:45 UTC Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S) Key flags: signing Subkey: 62BF 9E6B C022 D3FB 681F 5279 2B09 341C EDFE 0AF9 Public-key algo: ECDH public key algorithm Public-key size: 256 bits Secret key: Unencrypted Creation time: 2021-02-15 21:34:45 UTC Expiration time: 2024-02-16 15:01:06 UTC (creation time + P1095DT62781S) Key flags: transport encryption, data-at-rest encryption UserID: <alice@example.org>
- colineartheta 6y ago
  I wondered if I was misunderstanding something, thank you for the response and correction. It was, “For instance, it is not currently possible to add new subkeys to a certificate”, that I thought was acknowledging this, but looking closer it seems to just be different terminology [0] than I’m familiar with. Looking forward to giving this a try! [0]https://wiki.debian.org/Subkeys https://wiki.debian.org/Subkeys
  - nwalfield 6y ago
    Right. The sq cli does not have an subcommand to add new subkeys to an existing certificate. But it can use such certificates, and when it generates a certificate, it, by default, generates a certificate with subkeys. This functionality will, of course, be added to sq (it is possible to do this using the library). We just haven't gotten to it yet. It's not that the functionality is hard to implement. But, we want to have a clean CLI, and there are many possible options. We want to expose them in a sensible way that does not overwhelm the user.

adkadskhj 6y ago

Any idea when the high level crate will have parity with the CLI? Or perhaps, UX parity? I ask because the CLI looks fairly understandable (to a crypto-dunce like me), but the high level API in readme says: > Please note that as of this writing the high-level API is very incomplete. I'm also not sure what crate they refer to, because there is no `sequoia` crate on docs.rs, and their link points to the root of the repo which is a workspace without a crate. Perhaps they mean sequoia-openpgp[1], but so far that interface does not look similarly high level to that of the CLI. Anyway, just asking because i often write apps that use signing/encryption/etc for data at rest, and Sq looks neat. [1]: https://docs.rs/sequoia-openpgp/1.0.0/sequoia_openpgp/index.html https://docs.rs/sequoia-openpgp/1.0.0/sequoia_openpgp/index....

nwalfield 6y ago
Sequoia consists of a number of components. There is the low-level crate. We released version 1.0 of that in Dec. 2020. There is sq, the CLI tool. We released that a few weeks ago. We've barely started work on the high-level interface. Just because we plan to write a high-level tool, doesn't mean the low-level crate is hard to use. On the contrary, our experience is that it is pretty easy to use and actually does a good job hiding a lot of the low level details that don't need to be tweaked. For instance, I ported the pep engine from gpgme (GnuPG's high-level interface) to Sequoia's low-level interface. The initial port required about half as many lines of code.

nitsky 6y ago

Does the sequoia CLI have support for smartcards like yubikeys? I checked the issue tracker and didn't see any information.

darkr 6y ago
The library didn't, last time I looked
glsdfgkjsklfj 6y ago
aren't those only to fetch/store certs? can't you just pipe the proprietary(?) utility?
- upofadown 6y ago
  They can just be used for key storage. But for OpenPGP the device is normally used as a sort of an air gapped system. The secret key information is kept on the device and the operations requiring that information are done directly on the device. It is possible and normal for even the owner to have no access to the secret key information. An advantage of a open and well documented offline cryptography standard. You can do stuff like that.
  - glsdfgkjsklfj 6y ago
    isn't a closed implementation adversarial to those benefits? I mean any implementation can handle the signing etc, as the operations are an open standard. But running the actual pgp implementation on a system you have no access to sources, can't really see the advantage of just using an old laptop to have truly airgapped system (plugging your proprietary device on a connected computer doesn't look that airgapped to me)
    - upofadown 6y ago
      Some do claim that the software on the key is open source. I have not looked that deeply into those claims. Random example: * https://github.com/trustcrypto https://github.com/trustcrypto

bugmen0t 6y ago

Is there a guide for switching from gpg on the cli to sq? Specifically, I'm not sure how to move keys from my gpg keyring to sq.

nwalfield 6y ago
Sequoia does not (yet) have feature parity with GnuPG. Several important components are missing including a public key store. In GnuPG, the public key store is mandatory. In our discussions with application developers, in particular, developers working on server software, this requirement was more of a hindrance than a help. Thus, in Sequoia we decided it needs to be as easy to bring your own key store (e.g., an existing database) as to use ours. That said, on the desktop, it is quite useful to have a shared key store--you don't want to import keys into each of your OpenPGP-using applications. We hope to finish our [public key store](https://docs.sequoia-pgp.org/sequoia_store/index.html https://docs.sequoia-pgp.org/sequoia_store/index.html) this year along with other features that end users need and expect.