[HN Gopher] Sq, Sequoia PGP's CLI, Released
___________________________________________________________________
Sq, Sequoia PGP's CLI, Released
Author : upofadown
Score : 106 points
Date : 2021-02-15 12:13 UTC (1 days ago)
(HTM) web link (sequoia-pgp.org)
(TXT) w3m dump (sequoia-pgp.org)
| adkadskhj wrote:
| 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....
| nwalfield wrote:
| 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.
| colineartheta wrote:
| 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 wrote:
| 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 wrote:
| 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
| nwalfield wrote:
| 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.
| bugmen0t wrote:
| 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 wrote:
| 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)
| this year along with other features that end users need and
| expect.
| nitsky wrote:
| Does the sequoia CLI have support for smartcards like yubikeys? I
| checked the issue tracker and didn't see any information.
| nwalfield wrote:
| Not yet, but it is on the road map!
| glsdfgkjsklfj wrote:
| aren't those only to fetch/store certs? can't you just pipe the
| proprietary(?) utility?
| upofadown wrote:
| 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 wrote:
| 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)
| darkr wrote:
| The library didn't, last time I looked
___________________________________________________________________
(page generated 2021-02-16 23:02 UTC)