Devel March 2024

devel@lists.sequoia-pgp.org

3 participants
2 discussions

Help with Sequoa-PGP implementation
by Abraham George 26 Mar '24

26 Mar '24

Hello, My name is Abe, and I'm one of the developers behind osvauld, an open-source credentials manager for developers (github <http://github.com/osvauld> || website <http://osvauld.com>). We're building our UI as a Chrome extension and utilizing WASM and Sequoia PGP for cryptographic operations (wasm repo <https://github.com/osvauld/crypto_primitives>). We'd greatly appreciate your expertise on a couple of key management challenges we're facing. Our current Setup: *Initial Key Generation:* When a user first logs in, they set up a passphrase. We use this passphrase to secure their certificate within the extension's local storage: ``` let (cert, _revocation) = CertBuilder::new() .add_userid("someone(a)example.org") .set_cipher_suite(CipherSuite::Cv25519) // This specifies ECC keys with Curve25519 .add_subkey(flags, None, None) .set_password(Some(passphrase)) .generate()?; ``` *Logging In:* Now when the user logs in the next time using the passphrase, passphrase and protected certificates are given to wasm it decrypts the secret key material and stores that in memory. ``` let cert = Cert::from_bytes(&private_key_bytes)?; let p = &StandardPolicy::new(); let keypair =cert.keys() .with_policy(p, None) .secret() .for_storage_encryption() .nth(0) .ok_or_else(|| "No suitable key found in Cert.")? .key() .clone() let password = Password::from(password); let decrypted_keypair = keypair.decrypt_secret(&password)?; ``` *Decryption: * When user requests for decryption ``` pub fn decrypt_message( p: &dyn Policy, sk: &Key<openpgp::packet::key::SecretParts, openpgp::packet::key::UnspecifiedRole>, ciphertext: &[u8], ) -> openpgp::Result<Vec<u8>> { let helper = Helper { secret: &sk, policy: p, }; let mut decryptor = DecryptorBuilder::from_bytes(ciphertext)?.with_policy(p, None, helper)?; let mut plaintext = Cursor::new(Vec::new()); std::io::copy(&mut decryptor, &mut plaintext)?; let plaintext = plaintext.into_inner(); Ok(plaintext) } struct Helper<'a> { secret: &'a Key<openpgp::packet::key::SecretParts, openpgp::packet::key::UnspecifiedRole>, policy: &'a dyn Policy, } impl<'a> openpgp::parse::stream::DecryptionHelper for Helper<'a> { fn decrypt<D>( &mut self, pkesks: &[openpgp::packet::PKESK], _skesks: &[openpgp::packet::SKESK], sym_algo: Option<openpgp::types::SymmetricAlgorithm>, mut decrypt: D, ) -> openpgp::Result<Option<openpgp::Fingerprint>> where D: FnMut(openpgp::types::SymmetricAlgorithm, &openpgp::crypto::SessionKey) -> bool, { // The secret key is already decrypted. let mut pair = KeyPair::from(self.secret.clone().into_keypair()?); pkesks[0] .decrypt(&mut pair, sym_algo) .map(|(algo, session_key)| decrypt(algo, &session_key)); Ok(None) } } ``` We need your advice on handling these scenarios: 1. Certificate Export: - We would like to provide users with the ability to export their unprotected certificate. Could you please advise us on how this can be achieved using the Sequoia PGP library? 2. Password Change: - In case a user needs to change their password, how can we implement this functionality within our current setup? - If directly changing the password is not feasible, would it be safe to use (KDF) to encrypt the unprotected certificate with the new password? 3. Session Key Management and Extension Constraints: Due to the limitations imposed by Chrome extension manifest v3, we are unable to securely store decrypted private keys in memory for extended periods. To address this, we are considering a hybrid approach: - Encrypt the decrypted certificate (secret key material) with a session key and store the encrypted version locally. - Store the session key securely on our server and fetch it using a user-specific token when needed. Our questions regarding this approach are: - Does the Sequoia PGP library provide any built-in functionality or provisions that can assist us in implementing this session key management scheme? - Could you offer any suggestions or best practices on how to securely implement this approach within the Sequoia framework? - Are there any alternative solutions or architectures you would recommend for managing session keys in our specific use case? Thank you for your time and for the tremendous work on Sequoia PGP! Sincerely, Abe

1 0

The state of PGP, and Sequoia's role
by Florian Berger 11 Mar '24

11 Mar '24

Hello everyone, I have a question about the general state of the PGP ecosystem, and Sequoia's role in it, and I hope this is the right place to ask. If not, apologies, and kindly direct me somewhere more fitting. I had been an avid user and advocate of PGP until some time in 2018/2018, when first Efail surfaced (with its infamous "Don't use HTML mails" workaround [1]), and then the keyserver attacks followed. [2] In summer 2019, Latacora's "The PGP Problem" was published [3], spurring a considerable level of agreement within the community [4], and even from GnuPG development [5]. Researching these, I stumbled across even earlier PGP rejections, such as by Matthew Green in 2014 [6] and by Filipo Valsorda in 2016 [7]. And then there is secushare's "15 reasons not to start using PGP" [8]. I know that some of the criticism is about PGP as a technology, and quite a few are about the GnuPG implementation. Nonetheless, I subsequently made a hard cut, abandoned PGP-encrypted email altogether, moved sensitive communication to Signal, and tried to bring the matter to the attention of colleagues, friends and family, with varying degrees of success. Then, for some years, I ignored everything around PGP, and basically waited for it to die. Not it's 2024, people still encrypt email using PGP, Thunderbird incorporated PGP in 2020, Sequoia goes in its 7th year with increasing adoption, and I, after a long break, am trying to find out what is actually going on. My question: Is PGP, as a technology, merely on life support, and should still be generally avoided – or has it, given younger implementations such as Sequoia, become viable again as a future-proof foundation for communication, authentication etc.? Back in the day, I was especially worried about the lack of forward secrecy, keys as long term secrets and impractical identity tokens, the public WoT, and the overall complexity of the system design. That of course is a broad and somewhat audacious question. I am merely looking looking for an overview of the state of affairs from a Sequoia perspective, or respective pointers/links, since even Wikipedia just seems to sum up the status quo as "PGP and OpenPGP have been criticized". [9] [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html [2] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f [3] https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ [4] https://news.ycombinator.com/item?id=20455780 [5] https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062384.html [6] https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ [7] https://words.filippo.io/giving-up-on-long-term-pgp/ [8] https://secushare.org/PGP [9] https://en.wikipedia.org/w/index.php?title=Pretty_Good_Privacy&oldid=120864… Thanks for your patience and effort, Florian

3 4

2024

2023

2022

2021

2020

2019

2018

Devel March 2024