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)
»8 Ways Your #Email Account Is Vulnerable to #Hack'ers«
It would help a little to use #OpenPGP signatures, but this alone irritates many because they "can't read" the attached file. Why do they call themselves #security-conscious #IT professionals and users? Implementing something like this in a company is really not too much effort. In my opinion, this alone would increase the sender's confidence considerably.
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.
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.
Can anymany tell me how I'm "supposed" to use end-to-end encryption with XMPP?
As far as I can tell there are three totally different ways to do E2EE:
a)OTR : "[https://xmpp.org/extensions/xep-0364.html](Not intended to be a current standard), or technical specification, as better (albeit, newer and less well tested) methods of end-to-end encryption exist for XMPP. "
b)OpenPGP: There are at least two different XEPs about it. XEP-0027 is obsolete, while XEP-0373 is "experimental" but hasn't been updated in almost three years.
c)OMEMO: "Experimental" and hasn't been updated in over two years.
Is there a way to do E2EE in XMPP which is neither deprecated nor experimental? What's the "Current stable" way to do it?
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
Sie rufen von deinem e-Perso den Namen ab, du lädst deinen Public Key hoch, wählst eine der User-IDs des Keys aus (wenn du mehrere hast), und wenn der Name der UID mit dem Namen auf dem Perso übereinstimmt, bekommst du an die Mailadresse in der UID eine Signatur von 0xA4BF43D7 "Governikus OpenPGP Signaturservice (Neuer Personalausweis)".
This release shows more output for error cases, both in the log output, and with GUI notifications.
I also published an updated version 0.0.3 of https://crates.io/crates/openpgp-card-state, which contains a low-level CLI tool to help with debugging/development. This version gives more debugging output for error cases.
This release should fix build issues (the previous version didn't build on mac).
However, we're still exploring how secret storage works on non-Linux platforms. Expect a bumpy ride if you try it.
(If you do delve into debugging on mac or windows, we'd love to hear from you!)
It contains exciting UX changes: after one-time initial setup, no user interaction is required.
The User PIN for cards is persisted in platform-specific secret storage. For all users whose threat model allows persisting PINs on the host (presumably most), this removes pin entry.
Required touch confirmation on the card (if enabled) is signaled with desktop notifications.
News from the machine room: the pure #rust end-to-end encryption engine, "rpgp", saw quite some work and a new release in recent weeks and now @hko released a higher level "rpgpie" interface for application developers ( see https://fosstodon.org/@hko/111997998005869515 ) which also powers running the IETF #OpenPGP#interoperability test suite quite successfully .... Delta Chat's security-audited encryption engine is in fact used from several other projects and in other contexts these days and we are happy about it!
Relatedly, I also released rpgpie 🦀️🔐🥧 v0.0.1 (https://crates.io/crates/rpgpie), an experimental high level OpenPGP API based on rpgp (rsop is built on top of rpgpie).
I think it's telling that #GitHub, #GitLab, and even #Forgejo all don't have a workflow for "renew an #OpenPGP key", i.e. extend its validity before (or after) expiry. On all of them, you have to delete and re-add the key. It's as if nobody is following OpenPGP best practices and everyone is using keys without an expiry date.
This crate paves the way for convenient handling of #OpenPGP card User PINs, for users whose threat model allows persisting the PIN locally on the host computer.
If a User PIN is stored, applications can obtain it via this crate, and perform cryptographic operations without prompting the user for PIN entry.
Currently org.freedesktop.Secret is supported for storage.
This SSH agent explores an absolutely streamlined UX for doing ssh backed by OpenPGP card-based key material.
After persisting the User PIN once, like this: "$ openpgp-card-state put --user-pin 123456 0000:01234567", the ssh agent can be used without any user interaction.