18 ms·

Rpgp: Pure Rust implementation of OpenPGP

167 points by bpierre 3y ago

wiktor-k 3y ago
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/ https://tests.sequoia-pgp.org/
- dralley 3y ago
  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 3y ago
    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.
- deleted 3y ago
  [deleted]
dignifiedquire 3y ago
hey, author here, happy to answer questions, and would love to hear from anyone using the library :)
- LtWorf 3y ago
  Does it support smart cards and such devices?
  - dignifiedquire 3y ago
    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 3y ago
      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 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 https://github.com/wiktor-k/monkeybagel (excuse the silly name ;).
      - rendaw 3y ago
        How does it interface with the cards? IIRC the rust pcsc library used by Sequoia needed C libraries. I've been doing some NFC stuff too and was looking for a pure-rust solution if there was one.
        wiktor-k 3y ago
        It uses this crate: https://crates.io/crates/pcsc https://crates.io/crates/pcsc On Windows and Mac it binds to system libraries. On Linux it works with pcsclite. Btw I'm not aware of any tooling that's used by Sequoia, rather wrappers that use Sequoia and pcsc crate.
- Mortak 3y ago
  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-github-com/ https://github.blog/2017-03-20-sha-1-collision-detection-on-...). What's your plan to deal with the issue?
  - dignifiedquire 3y ago
    I just finished implementing sha1collision detection, and it will be integrated into rpgp soon https://github.com/rpgp/rpgp/issues/293 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.
  - upofadown 3y ago
    I am not aware of any outstanding SHA-1 issues that would require a change in the current RFC4880 OpenPGP standard. There was an obscure attack that involved generating two keypairs with colliding SHA-1 signatures and getting a third party to sign one of them but you can just use a different hash (say SHA256). The SHA-1 used in the MDC portion of the authenticated encryption mode doesn't and is very unlikely to ever represent any security weakness (the hash used there doesn't require any particular cryptographic properties). SHA-1 is used for the key fingerprint, but the use of a hash with collision resistance is not required in general for key fingerprints. An attacker could in theory create two different keys with the same fingerprint, but then they would just own two keys that would be hard for to distinguish from one another. You don't sign the fingerprints, you sign the actual public key. In general, it would be a bad idea to specify that the hash used for a key fingerprint required collision resistance as that would mean that the fingerprint would have to be something like an unusable 256 bits long to prevent birthday attacks.
dale_glass 3y ago
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 3y ago
  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/ https://pypi.org/project/pysequoia/) and personally I think it yields more readable, faster and secure code.
  - im3w1l 3y ago
    > Funny part is that even the library of gpg (gpgme) is internally calling the binary. Sounds like a great way to transition things in a saner direction. You know it will be bug-for-bug compatible with calling the gpg-binary. Having one blessed text-parser with a lot of eyes on it is much better than everyone rolling their own. Getting people used to depending on a library instead of shelling out also means it becomes possible to move the library to independent implementations.
woodruffw 3y ago
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/8e67756ebce780c91b8c2ffc7db1f6230f8a9419/src/crypto/rsa.rs#L172-L178 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/ https://blog.cryptographyengineering.com/euf-cma-and-suf-cma...
- dignifiedquire 3y ago
  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 3y ago
    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 3y ago
      This was allowed in the rust-rsa crate directly before, which is why it was introduced in that commit.
      - woodruffw 3y ago
        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 https://github.com/RustCrypto/RSA/issues/272
perlgeek 3y ago
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 3y ago
  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 3y ago
  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-encrypted/ https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
karma_pharmer 3y ago
This uses a flawed RSA implementation which is vulnerable to timing attacks: https://deps.rs/repo/github/rpgp/rpgp#vulnerabilities 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 3y ago
  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..
  - karma_pharmer 3y ago
    unless you’re stating crypto primitives should only be written in assembly Yes, that's exactly what I'm stating. Have a look at openssl, boringssl, nspr, etc. They all implement the core modular arithmetic for RSA and the s-box table for AES using assembly language. There is no reliable way to prevent a C compiler from "optimizing" your constant-time code into non-constant-time code. another rust TLS implementation rustls uses assembler (from boringssl) for these routines. It is not 100% rust, and that's a good thing.
    - deleted 3y ago
      [deleted]
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- karma_pharmer 3y ago
  Genuinely curious, why the downvotes?
upofadown 3y ago
GnuPG has by default started emitting keypairs with a preference for the LibrePGP version of the OCB block cipher mode. That mode is not compatible with what the other faction is doing and is not generally supported in any case. Arch[1] and other distributions have apparently patched this default out. Is Rpgp emitting any new block cipher modes or generating keys that might cause such emission in the future? The risk here is a sort of incompatibility nightmare where decryption becomes a crap shoot. My article on this mess: https://articles.59.ca/doku.php?id=pgpfan:schism https://articles.59.ca/doku.php?id=pgpfan:schism [1] https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_A...
- deleted 3y ago
  [deleted]
- wiktor-k 3y ago
  Yep, the schism is really bad for the end users and based on my "insider" knowledge it doesn't seem like the resolution is near. The tl;dr is that GnuPG basically forked OpenPGP into https://librepgp.org/ https://librepgp.org/
- dignifiedquire 3y ago
  While rpgp is slowly gaining support for this format (the aid users to be able to talk to anyone they want) it will keep emitting the broadest compatible format for a while by default, until the whole ecosystem has upgraded. The aggressive stance from gnupg is really hurting people and removes one of the biggest benefits of pgp, broad interop with compliant implementations.
  - upofadown 3y ago
    Each faction has a seemingly legitimate position. My understanding is that there are no cryptographic weaknesses in the existing block cipher mode (SEIP) so there are no downsides to just doing that indefinitely.
different_base 3y ago
[flagged]
fanf2 3y ago
How does rpgp compare with Sequoia? https://sequoia-pgp.org/ https://sequoia-pgp.org/
- wiktor-k 3y ago
  Sequoia aims to be a "complete gnupg replacement" but in many ways it's still the same mindset as gnupg (core devs are former developers of gnupg). Sequoia also got support from VCs and just recently received significant funding from the STF which gives them resources to polish the documentation etc. Rpgp is much smaller but also very flexible. It's easy to adjust to more specific needs. It's also associated with RustCrypto project and with Rust in general. For example to add rpgp to your project you just do "cargo add pgp". To use Sequoia "properly" you need this multiline setup which depends on whether your crate is a "leaf" crate or not: https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?ref_type=heads#how-to-select-crypto-backends-in-crates https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?r... Another example: Sequoia is against rustfmt. This makes it harder to contribute. On the other side rpgp is much more barebones and instead of docs you need to read the source (which is rather readable). Both of them would benefit from a high level API, so that the users wouldn't have to work with types such as ValidUserAttributeAmalgamationIter (https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/amalgamation/type.ValidUserAttributeAmalgamationIter.html https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/...). Full disclaimer: I've worked 3 years on core Sequoia and I'm kind of involved in the OpenPGP protocol: https://github.com/wiktor-k https://github.com/wiktor-k
  - fanf2 3y ago
    Thanks, super informative!

167 points by bpierre 3y ago

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/ https://tests.sequoia-pgp.org/

dralley 3y ago
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 3y ago
  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.
deleted 3y ago
[deleted]

dignifiedquire 3y ago

hey, author here, happy to answer questions, and would love to hear from anyone using the library :)

LtWorf 3y ago
Does it support smart cards and such devices?
- dignifiedquire 3y ago
  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 3y ago
    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 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 https://github.com/wiktor-k/monkeybagel (excuse the silly name ;).
    - rendaw 3y ago
      How does it interface with the cards? IIRC the rust pcsc library used by Sequoia needed C libraries. I've been doing some NFC stuff too and was looking for a pure-rust solution if there was one.
      - wiktor-k 3y ago
        It uses this crate: https://crates.io/crates/pcsc https://crates.io/crates/pcsc On Windows and Mac it binds to system libraries. On Linux it works with pcsclite. Btw I'm not aware of any tooling that's used by Sequoia, rather wrappers that use Sequoia and pcsc crate.
Mortak 3y ago
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-github-com/ https://github.blog/2017-03-20-sha-1-collision-detection-on-...). What's your plan to deal with the issue?
- dignifiedquire 3y ago
  I just finished implementing sha1collision detection, and it will be integrated into rpgp soon https://github.com/rpgp/rpgp/issues/293 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.
- upofadown 3y ago
  I am not aware of any outstanding SHA-1 issues that would require a change in the current RFC4880 OpenPGP standard. There was an obscure attack that involved generating two keypairs with colliding SHA-1 signatures and getting a third party to sign one of them but you can just use a different hash (say SHA256). The SHA-1 used in the MDC portion of the authenticated encryption mode doesn't and is very unlikely to ever represent any security weakness (the hash used there doesn't require any particular cryptographic properties). SHA-1 is used for the key fingerprint, but the use of a hash with collision resistance is not required in general for key fingerprints. An attacker could in theory create two different keys with the same fingerprint, but then they would just own two keys that would be hard for to distinguish from one another. You don't sign the fingerprints, you sign the actual public key. In general, it would be a bad idea to specify that the hash used for a key fingerprint required collision resistance as that would mean that the fingerprint would have to be something like an unusable 256 bits long to prevent birthday attacks.

dale_glass 3y ago

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 3y ago
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/ https://pypi.org/project/pysequoia/) and personally I think it yields more readable, faster and secure code.
- im3w1l 3y ago
  > Funny part is that even the library of gpg (gpgme) is internally calling the binary. Sounds like a great way to transition things in a saner direction. You know it will be bug-for-bug compatible with calling the gpg-binary. Having one blessed text-parser with a lot of eyes on it is much better than everyone rolling their own. Getting people used to depending on a library instead of shelling out also means it becomes possible to move the library to independent implementations.

woodruffw 3y ago

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/8e67756ebce780c91b8c2ffc7db1f6230f8a9419/src/crypto/rsa.rs#L172-L178 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/ https://blog.cryptographyengineering.com/euf-cma-and-suf-cma...

dignifiedquire 3y ago
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 3y ago
  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 3y ago
    This was allowed in the rust-rsa crate directly before, which is why it was introduced in that commit.
    - woodruffw 3y ago
      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 https://github.com/RustCrypto/RSA/issues/272

perlgeek 3y ago

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 3y ago
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 3y ago
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-encrypted/ https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...

karma_pharmer 3y ago

This uses a flawed RSA implementation which is vulnerable to timing attacks: https://deps.rs/repo/github/rpgp/rpgp#vulnerabilities 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 3y ago
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..
- karma_pharmer 3y ago
  unless you’re stating crypto primitives should only be written in assembly Yes, that's exactly what I'm stating. Have a look at openssl, boringssl, nspr, etc. They all implement the core modular arithmetic for RSA and the s-box table for AES using assembly language. There is no reliable way to prevent a C compiler from "optimizing" your constant-time code into non-constant-time code. another rust TLS implementation rustls uses assembler (from boringssl) for these routines. It is not 100% rust, and that's a good thing.
  - deleted 3y ago
    [deleted]
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
karma_pharmer 3y ago
Genuinely curious, why the downvotes?

upofadown 3y ago

GnuPG has by default started emitting keypairs with a preference for the LibrePGP version of the OCB block cipher mode. That mode is not compatible with what the other faction is doing and is not generally supported in any case. Arch[1] and other distributions have apparently patched this default out. Is Rpgp emitting any new block cipher modes or generating keys that might cause such emission in the future? The risk here is a sort of incompatibility nightmare where decryption becomes a crap shoot. My article on this mess: https://articles.59.ca/doku.php?id=pgpfan:schism https://articles.59.ca/doku.php?id=pgpfan:schism [1] https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_AEAD_mechanism https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_A...

deleted 3y ago
[deleted]
wiktor-k 3y ago
Yep, the schism is really bad for the end users and based on my "insider" knowledge it doesn't seem like the resolution is near. The tl;dr is that GnuPG basically forked OpenPGP into https://librepgp.org/ https://librepgp.org/
dignifiedquire 3y ago
While rpgp is slowly gaining support for this format (the aid users to be able to talk to anyone they want) it will keep emitting the broadest compatible format for a while by default, until the whole ecosystem has upgraded. The aggressive stance from gnupg is really hurting people and removes one of the biggest benefits of pgp, broad interop with compliant implementations.
- upofadown 3y ago
  Each faction has a seemingly legitimate position. My understanding is that there are no cryptographic weaknesses in the existing block cipher mode (SEIP) so there are no downsides to just doing that indefinitely.

different_base 3y ago

[flagged]

fanf2 3y ago

How does rpgp compare with Sequoia? https://sequoia-pgp.org/ https://sequoia-pgp.org/

wiktor-k 3y ago
Sequoia aims to be a "complete gnupg replacement" but in many ways it's still the same mindset as gnupg (core devs are former developers of gnupg). Sequoia also got support from VCs and just recently received significant funding from the STF which gives them resources to polish the documentation etc. Rpgp is much smaller but also very flexible. It's easy to adjust to more specific needs. It's also associated with RustCrypto project and with Rust in general. For example to add rpgp to your project you just do "cargo add pgp". To use Sequoia "properly" you need this multiline setup which depends on whether your crate is a "leaf" crate or not: https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?ref_type=heads#how-to-select-crypto-backends-in-crates https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?r... Another example: Sequoia is against rustfmt. This makes it harder to contribute. On the other side rpgp is much more barebones and instead of docs you need to read the source (which is rather readable). Both of them would benefit from a high level API, so that the users wouldn't have to work with types such as ValidUserAttributeAmalgamationIter (https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/amalgamation/type.ValidUserAttributeAmalgamationIter.html https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/...). Full disclaimer: I've worked 3 years on core Sequoia and I'm kind of involved in the OpenPGP protocol: https://github.com/wiktor-k https://github.com/wiktor-k
- fanf2 3y ago
  Thanks, super informative!