[HN Gopher] Rpgp: Pure Rust implementation of OpenPGP
___________________________________________________________________
Rpgp: Pure Rust implementation of OpenPGP
Author : bpierre
Score : 81 points
Date : 2024-04-07 16:50 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| wiktor-k wrote:
| Rpgp is great (we're currently using it for a better git signer
| with smartcards) but I wonder why is it trending right now at HN?
| Maybe because it's currently #1 in the test suite?
| https://tests.sequoia-pgp.org/
| dralley wrote:
| I wish seqouia would use MPL-2 or something over LGPL. It's
| only a little weaker in licensing terms but vastly more
| convenient to use.
| wiktor-k wrote:
| Indeed. There were some discussions over choosing MPL but the
| parent foundation was more aligned with GPL and after it
| collapsed it seemed th3 idea of relicensing to MPL was
| dropped.
|
| Do note that sequoia and rpgp are different in many aspects
| so the licensing is just one thing.
| dignifiedquire wrote:
| hey, author here, happy to answer questions, and would love to
| hear from anyone using the library :)
| LtWorf wrote:
| Does it support smart cards and such devices?
| dignifiedquire wrote:
| it's not builtin, but possible to integrate with
|
| @wiktor-k is working on a tool to use rpgp to provide a
| simple solution to work with smartcards
| wiktor-k wrote:
| Yep. We've got it working with OpenPGP Card devices
| (Yubikeys, Nitorkeys, etc.). The signing part was actually
| pretty easy and the decryption required a bit more work but
| the maintainer was _super_ responsive
| (https://github.com/rpgp/rpgp/pull/315).
|
| Overall I'm pretty happy with the codebase.
|
| The PoC for using cards in git is in
| https://github.com/wiktor-k/monkeybagel (excuse the silly
| name ;).
| Mortak wrote:
| It seems OpenPGP is still riddled with SHA-1. Git kind of
| avoided the problem
| (https://github.blog/2017-03-20-sha-1-collision-detection-
| on-...). What's your plan to deal with the issue?
| dignifiedquire wrote:
| I just finished implementing sha1collision detection, and it
| will be integrated into rpgp soon
| https://github.com/rpgp/rpgp/issues/293
|
| This is the same algorithm used by git.
|
| There are higher level implementations that use the dates on
| signatures to straight out reject sha1 material, but that
| gives only a limited protection.
| dale_glass wrote:
| Ah, if only this was a thing a decade or two ago.
|
| IMO, the way GPG was done killed what could have been a decent
| ecosystem. It's a combination of two factors:
|
| 1. Don't roll your own crypto.
|
| 2. The available code (gpg) is a colossal pain to use.
|
| So for instance, how does something like KMail deal with gpg?
| There's no libgpg originally. There's just the gpg tool, so
| you've got to call it as a sub-process, and it really sucks:
|
| 1. You have to deal with process management, multiple
| filehandles, text parsing, non-trivial interactions, etc.
|
| 2. It's slow. You pay startup costs every single time. This is a
| huge problem on something interactive like a mail client, and
| it's dependent on things like the amount of keys in the gpg
| store.
|
| 3. gpg has very specific ideas about how it wants to be used, and
| not everything fits.
|
| Say that you oh, want to do some stats on GPG keys. There's no
| libgpg to just read an .asc file and get the list of signatures
| from that, no. You have to call gpg, feed it the key, parse the
| result. For some things you might actually have to have gpg
| import the key first. Manage a fake home dir for GPG. Deal with
| the horrible performance as the keystore grows. A million keys at
| a gpg invocation per second is going to be around 2 weeks.
|
| Unfortunately it's only now that gpg is effectively dead that the
| problem started to get fixed.
|
| Also, at this point GPG is effectively a legacy technology
| anyway. Modern cryptographic thought considers GPG to be a
| terrible idea for a whole bunch of reasons that are deeply built
| into it, so the only solution for that is throwing it out.
| wiktor-k wrote:
| I agree that gpg did not age well. If we compare it to a
| different project with similar history: curl, it's apparent
| that gpg chose wrong on several fronts. It should be a library
| first instead of a cli tool. Funny part is that even the
| library of gpg (gpgme) is internally calling the binary.
|
| I've played around with designing a higher level library to
| OpenPGP once (https://pypi.org/project/pysequoia/) and
| personally I think it yields more readable, faster and secure
| code.
| ognarb wrote:
| Disclaimer: I work on GPG and I am one of the KMail core
| developer.
|
| The standard way to use GPG is via the gpgme librairie which
| then communicate with the Assuan protocol to the gpg deamon.
| Gpgme has official bindings to C++, Qt and python. In KMail we
| use the Qt bindings and it works fine.
| dale_glass wrote:
| > Disclaimer: I work on GPG and I am one of the KMail core
| developer.
|
| Nice work :) Looking forward to seeing further improvements
| to it, it's still got a few rough edges, but otherwise I
| really like it.
|
| > The standard way to use GPG is via the gpgme librairie
| which then communicate with the Assuan protocol to the gpg
| deamon.
|
| Yeah, but all GPGme does is calling the gpg binary and
| presenting a more palatable interface to applications.
|
| That solves the problem as far as the API goes, but
| performance is still terrible for some uses, and it's still
| liable to run into all kinds of weird problems in edge cases.
| But at least for something like mail clients it seems to work
| well enough.
| curt15 wrote:
| Doesn't git use GPG to sign commits?
| dale_glass wrote:
| Yes, why?
|
| And I believe these days you can use SSH keys for signing
| commits as well.
| Zizizizz wrote:
| You can use SSH keys as well.
| dheera wrote:
| Just use an ssh key for authentication and there is no need
| to sign commits.
| rmwaite wrote:
| How does SSH authentication provide the same guarantees as
| signing commits?
| Lammy wrote:
| > Don't roll your own crypto.
|
| This is exactly the meme I would try to propagate if I had
| backdoored every popular crypto implementation. More people
| should roll their own crypto so they can stumble and learn and
| eventually get good at it.
| woodruffw wrote:
| This assumes that implementation diversity stymies an
| attacker, which isn't really true in cryptography.
| Cryptographic errors have well-understood "shapes,"
| frequently present even when the raw algebra of the
| implementation is correct; adversaries are _delighted_ when
| they discover yet another hand-rolled RSA implementation that
| 's susceptible to BB'98 or BB'06.
| woodruffw wrote:
| Edit: The comment below is incorrect. I'm leaving it for
| transparency, but I misread where the padding is being applied.
|
| I could be missing something here, but I think this is vulnerable
| to DO'1985, a/k/a Desmedt-Odlyzko:
|
| https://github.com/rpgp/rpgp/blob/8e67756ebce780c91b8c2ffc7d...
|
| In particular, in the presence of an insufficiently wide hash,
| the absence of padding here means that RSA signature validation
| is not secure under EUF-CMA. Matt Green has a great post on why
| and when EUF-CMA matters[1].
|
| (This isn't necessarily this implementation's fault, since PGP
| seemingly (!) encourages the stripping of padding from
| signatures. But I can't find another source for whether this is
| actually encouraged by OpenPGP, or whether implementations just
| widely allow it.)
|
| [1]: https://blog.cryptographyengineering.com/euf-cma-and-suf-
| cma...
| dignifiedquire wrote:
| I am not sure if this is an actual issue, all auditors that
| looked at this so far haven't mentioned this being a problem.
| But I will have to investigate what the exact state is.
| woodruffw wrote:
| According to `git blame`, this was introduced June 2023, i.e.
| after your audit in 2019. But maybe it was moved from an
| older piece of the codebase, I didn't dig too deep.
|
| (Looks like the IncludeSec folks did a decent job in 2019. Hi
| Eric!)
| dignifiedquire wrote:
| This was allowed in the rust-rsa crate directly before,
| which is why it was introduced in that commit.
| woodruffw wrote:
| Yep, I saw the upstream[1].
|
| However, I misread this: I thought the padding was being
| done on the cleartext signing side, but this is padding
| of the signature itself. So there's some malleability
| here, but it isn't susceptible to DO'1985. I'll update my
| top-level comment.
|
| [1]: https://github.com/RustCrypto/RSA/issues/272
| dignifiedquire wrote:
| Thanks, appreciate the careful check!
| junon wrote:
| Glad people care to look, that's what matters.
| perlgeek wrote:
| Given how much of a huge pain it was to use PGP / gpg back in the
| days (for email encryption/signatures, to be precise), it's
| amazing how easy end-to-end encryption on Signal and Whatsapp is.
| And how it lacks that drama that somehow always surrounded GPG.
|
| Is it really because trust on first use is good enough for most
| cases? Or is email somehow so much different than chat? Or was
| PGP the proof-of-concept, and current e2e encrypted platforms are
| the v1.0? Or all of the above? Did I miss anything important?
| OJFord wrote:
| If Gmail had decided to care about it, the experience in email
| might be nice too (or at least for Gmail users). But instead it
| wants to be able to read it to suggest calendar events etc.
|
| i.e. WhatsApp and Signal care about UX and mainstream adoption.
| Nothing like that for email has tried to do PGP.
| woodruffw wrote:
| PGP as an ecosystem has always suffered from toolbox-itis: when
| a tool ( _especially_ a cryptographic tool) tries to be
| everything, it ends up doing nothing particularly well. This
| got ossified in the form of OpenPGP, and has basically remained
| the status quo for the last ~25 years.
|
| More generally, the OpenPGP world is in a bit of a double-bind:
| they can either fix things by breaking compatibility (at which
| point someone can reasonably observe that there's no good
| reason not to ditch OpenPGP entirely), or retain compatibility
| and accept that OpenPGP will never get much better than RFC
| 4880 and whatever smattering of drafts the GnuPG maintainers
| agree to implement. One way essentially results in an entirely
| different tool/standard that happens to be wearing PGP's skin;
| the other means keeping around misuse-prone and outright broken
| cryptographic primitives (and bad formats to boot).
|
| (To answer your actual question: email is just a bad substrate
| for attempting E2EE messaging. Latacora has a great explainer
| post on why[1]. TOFU is a mostly adjacent concern;
| trust/identity negotiation is hard, but the thing that makes
| WhatsApp, Signal, etc. actually _work_ is that they eliminate
| manual key management and make cryptographic right choices for
| the user, rather than expecting the user to hold the tool
| correctly. In other words: they 're misuse-resistant, where PGP
| as an ecosystem has historically not been.)
|
| [1]: https://www.latacora.com/blog/2020/02/19/stop-using-
| encrypte...
| pvg wrote:
| Email being different from chat is a big factor and another one
| is that the entire system in Signal is designed and engineered
| specifically for the purpose, from the protocol on up.
| Retrofitting privacy, confidentiality, etc onto email is one of
| those noble 90's cryptography dreams that turned out to be
| unrealistic and impractical.
| barfbagginus wrote:
| Signal and WhatsApp are no good against state actors
|
| And that is where they get their usability
| karma_pharmer wrote:
| This uses a flawed RSA implementation which is vulnerable to
| timing attacks:
|
| https://deps.rs/repo/github/rpgp/rpgp#vulnerabilities
|
| There is a reason why crypto primitives handling key material --
| especially RSA and AES -- are not written in higher-level
| languages.
| mcspiff wrote:
| I'm not sure you can really categorize rust as a high level
| language, unless you're stating crypto primitives should only
| be written in assembly.
|
| EDIT: Given this attack was also applied to OpenSSL, amongst
| many others this high level language comment seems doubly
| odd/dubious
|
| EDIT2: another rust TLS implementation was among only 3 that
| was initially verified to be not vulnerable as well..
___________________________________________________________________
(page generated 2024-04-07 23:00 UTC)