A reminder for those who sit on the fence regarding whether “code is speech” — global access to strong cryptography would not be where it is today without a 1997 project to publish — as a book — the entire source code of PGP 5.0i in an OCR-friendly format, in such a way as to emphatically subvert the US Government export controls on cryptography by the power of the 1st Amendment:
Interesting history is documented in the links below; I’m particularly taken with an observation from Ian Grigg in the first link:
The story has a sad ending. In the last months of 1999, the US government released the controls on exporting free and open cryptography. Hailed by all as a defeat, it was really a tactical withdrawal from ground that wasn’t sustainable. The cypherpunks lost more: with the departure of their clear enemy, they dispersed over time, and emerging security and financial cryptography entrepreneurs lost our coolness factor and ready supply of cryptoplumbers. Lots of crypto projects migrated back to the US, where control was found by other means. The industry drifted back to insecure-practice-by-fiat. Buyers stopped being aware of security, and they were setup for the next failure and the next and the next… Strategic victory went to the US government, which still maintains a policy of keeping the Internet insecure by suppressing crypto where and when it can. […]
#e2ee is a goal, not a promise. As far back as I can remember, forums like those supporting #Enigmail and #gpg were staffed with volunteers from the privacy community who repeatedly insisted on answering questions, like, "Is <this> (whatever this might be) totally secure?" with stock questions like, "What is it that you consider 'totally secure?" or answers such as, "Secure is a relative term, nothing is completely secure, how secure do you need your mission's communications to be?"
Phrases such as, reasonably secure should be indicators of how ridiculous it is to assume that any secure platform isEVERcompletely, and totally secure.
That begs the question, "Exactly how secure do you require your communications to be?" The answer is always, ... relative.
Which means that you should always believe Ellen Ripley when she says, "Be afraid. Be very afraid!"
My experience is that state actors won't even try to decrypt your communications. That's old school - and a horribly inefficient use of resources. They'll come after you with a keylogger or manufactured legal nightmares or torture - to either or both sides of the communication; depending on the perceived value of your secret.
It all comes down to 4 fundamental questions:
What is the value of your secret to you
What resources do you have available to protect it
What is the perceived value of your secret to your adversary
What resources do they have available to divulge it
oct-git focuses exclusively on ergonomic use with OpenPGP card-based signing keys
It is designed to be easy to set up, standalone (no long running processes), and entirely hands-off to use (no repeated PIN entry required, by default). It comes with desktop notifications for touch confirmation (if required)
I just released version 0.3.1 of https://crates.io/crates/rsop, a stateless #OpenPGP ("sop") card tool based on #rPGP.
rsop natively supports OpenPGP card (hardware cryptography) devices
rsop is featured in the "OpenPGP interoperability test suite" at https://tests.sequoia-pgp.org/ (under "rpgpie", which is rsop's high level OpenPGP library).
This release adds the "oct admin signing-pin-validity" subcommand, to configure if a card requires User PIN presentation for each signature operation, or if User PIN presentation is valid for the full duration of a connection to the card.
FWIW, I am skeptical of the usefulness of "per-signature PIN presentation" on modern OpenPGP card devices.
This mode made sense with actual Smart Cards, when used in a reader with a physical pin pad.
However, with modern USB devices, I'd say that "touch confirmation" serves a similar goal, but is more fit for purpose.
Mechanisms that move authorization for signing operations outside the host computer add some defense in depth. Repeated PIN presentation from the host computer, less so.
Sequoia PGP's paid development is financed by @sovtechfund (❤️ ). In addition to writing code, they also support our standardization work, and community outreach. In this blog post, I discuss some of our community engagement (presentations and collaborations with sett, @securedrop, and @fedora) that have happened over the past few months.
Proton Mail automatically encrypts/decrypts messages between Proton Mail accounts via OpenPGP/PGP.
Proton Mail supports automatically encrypting/decrypting messages between Proton Mail accounts and external email accounts that support OpenPGP/PGP or GnuPG/GPG.
@protonprivacy@blueghost (can be) true, buuut, theres one thing wich mess people up - many takes writing from/to proton mail users as something wich will be encrypted "by default" without any knowledge of how pgp keys works + it just about trust that proton does not read messages when storing secret key themselves...
@iuvi@blueghost Note that Proton Mail servers don't hold your private master key directly — it is always stored encrypted with your account password. And we don't have access to your account password.
I moved to a Thinkpad w541 with coreboot so I needed to set up my email encryption on Thunderbird again.
It took me more time to reconfigure it again - as usual - so I decided to take notes this time and create a blog post about it. As this might be useful for somebody else … or me in the future :-)
@adamsdesk For the fsf europe fellowship card I don't know. I got my card 8 year ago from floss-shop.de. (I live in Europe/Belgium BTW ) You can check with them if they ship to Canada.
But the setup should work with any GPG compatible smartcard. I'm also looking at #nitrokey Not sure if nitrokey is available on your side of the ocean 🙂
Considering to change my #backup solution from #duplicity to #restic (Not sure yet, I like having #pgp keys for encryption, but it's not like a long password stored in #PasswordStore wouldn't cut it). Since restic supports Windows I might try moving a couple relatives onto it; Makes helping them easier if I know the software. For them however, a #GUI is likely a MUST, but what I've found so far is not too encouraging: restatic (dead), npbackup ("metrics" and other assorted niggles), resticguigx (Electron), backrest (browser-based, which makes my skin crawl for security tooling)... Does anyone know other options I missed? Or has some compelling arguments for those I mentioned?
@lpwaterhouse The reason why I did this switch is that Duplicity does not support large backups. The ticket is open for over a decade and still not solved.
@ascherbaum Yeah. My main issue is that duplicity feels very hacky in an "old unix grognard" kind of way (Not that I ain't one of those, but still). Been hearing good things about restic for a while now (out of the CCC universe), but looking at things like https://github.com/restic/restic/issues/187 (asymmetric encryption) being open since 2015, with quotes like "restic currently requires delete privileges for normal backup operation" (in 2021) make me somewhat hesitant... Especially given the claim that it "does backups right". The biggest draw for me really is not having to fiddle with some arcane Windows-only solution when asked for help...
Last year, the @sovtechfund fund invited us, the Sequoia PGP Project, to join their new Bug Resilience Program.
Today, I'm pleased to announce that we are publicly launching our bug bounty program with rewards of up to €10,000 for novel, security-relevant issues in Sequoia applications, libraries, or specifications. #pgp
@sequoiapgp@sovtechfund tip for STF: the IBB bug-bounty (which #curl is part of) gives 20% of the bounty to the project and 80% to the reporter - which I think is nice because there is certainly work to be done from the project's part as well to deal with the issues ...
We're trying to polish sq, Sequoia #PGP's CLI, in preparation for our 1.0 release this summer. One place we could use some help is with the CLI's UX: are the subcommands and options sane, and consistent? Also, we want to provide guidance so that user's don't need to memorize workflows, but are nudged along. See for instance: https://gitlab.com/sequoia-pgp/sequoia-sq/-/issues/221 If you are interested in helping, please reach out!
@hko@wiktor I could help with the Windows installer. I've almost 25 years experience with Windows Installer and was previously the Visual Studio architect on the new installer, and worked on WiX (the original) for many years. I also wrote and maintain installers for PowerShell, OpenSSH for Windows, etc. al. I've also helped publish those to winget, chocolatey, and scoop.
Does the agent run as a service using the Service Control Manager on Windows, or just a loose exe with no recovery? Systray?
This version comes with substantial updates to the openpgp-card-state dependency (which handles User PIN storage for OpenPGP card devices, see https://codeberg.org/openpgp-card/state).
It now supports selecting different PIN storage backends, including one to store the User PIN directly in the config file.
PIN verification error cases are now handled more defensively
A card can be configured to use "direct" PIN storage in the config file by editing its configuration (in ~/.config/openpgp-card-state/config.toml on a typical linux setup) to read like this:
[[cards]]
ident = "0000:01234567"
[cards.pin_storage]
Direct = "123456"
(... if the card's identity is "0000:01234567" and the User PIN is "123456")