[HN Gopher] Encrypting files with passkeys and age
       ___________________________________________________________________
        
       Encrypting files with passkeys and age
        
       Author : thadt
       Score  : 25 points
       Date   : 2025-07-14 16:31 UTC (1 days ago)
        
 (HTM) web link (words.filippo.io)
 (TXT) w3m dump (words.filippo.io)
        
       | thadt wrote:
       | > Note that there's no secure way to do asymmetric encryption: we
       | could use the PRF extension to encrypt a private key, but then an
       | attacker that observes that private key once can decrypt anything
       | encrypted to its public key in the future, without needing access
       | to the credential.
       | 
       | IMHO, it would move the world of privacy forward significantly if
       | someone took up championing a web API that securely pipes the
       | output of WebAuthn's PRF into the input seed of a WebCrypto ML-
       | KEM/X25519 implementation.
       | 
       | Sure, we'll still have the (unenviable) job of securing the
       | client side JS environment, but it would make it feasible to have
       | E2EE in the browser with passkey managed private keys exposed
       | only up to the point of the browser/OS.
        
       | defraudbah wrote:
       | I follow Filippo for years and he's doing amazing job for crypto
       | and golang communities. Excited to see your bikes adventures too.
       | If it wasn't for you who knows, maybe golang wasn't that popular
       | in the fields where cryptography matters.
       | 
       | keep up, Filippo!
        
       | andrewmcwatters wrote:
       | Say you wanted to share sign in details with someone and the only
       | way to sign in to a website or service was a magic email link
       | (tied to an IP address) or a passkey (tied to the physical user).
       | 
       | How do you do it without the service implementing guest sign in
       | as a feature? I'm asking as someone who has implemented auth.
        
         | lxgr wrote:
         | iOS allows sharing passkeys via Airdrop, I believe, and
         | presumably 1Password also allows storing them in shared vaults?
         | 
         | Regarding email, nothing prevents somebody wanting to share an
         | account from just forwarding the magic link to the intended
         | recipient without clicking on it, right?
        
         | perching_aix wrote:
         | Sounds like a rhetorical question? Maybe you could explain the
         | usage context instead?
        
       | mkw5053 wrote:
       | Very cool! Clever use of WebAuthn's PRF to reuse synced passkeys
       | for file encryption without the hassle of managing private keys
       | directly. The catch is credential revocation: leaked passkeys
       | mean full rotation and bulk re-encryption of files. That works
       | fine for casual backups, but production usage will need tooling
       | to handle automated rotation cleanly.
        
         | packetlost wrote:
         | I feel like only one extra layer of indirection (encrypt a
         | symmetric key with the age key) would enable rotation.
        
           | 9dev wrote:
           | Yeah, envelope encryption is the only sane solution. That
           | also allows decryption with multiple passkeys, for example.
        
         | lxgr wrote:
         | > Clever use of WebAuthn's PRF to reuse synced passkeys for
         | file encryption
         | 
         | Agreed on the clever part, but arguably that's exactly what PRF
         | was designed for :)
         | 
         | > The catch is credential revocation: leaked passkeys mean full
         | rotation and bulk re-encryption of files.
         | 
         | That's where the PRF input of key derivation comes in. The idea
         | is to have that input be rotate-able.
         | 
         | That's also why there is two of them: So you can "atomically"
         | (or at least using only one WebAuthN interaction) rotate the
         | derived keys.
        
       | dariosalvi78 wrote:
       | I was waiting for the prf to be implemented since a long time
       | exactly for this type of applications (e2e encryption), but , as
       | usual, Safari doesn't support it
       | 
       | https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
        
         | FiloSottile wrote:
         | Huh, iCloud Keychain supports the prf extension when used with
         | Chrome, so I had assumed they added support to Safari as well,
         | but I just tested it and sure enough, you're right.
         | 
         | Edit: well https://webauthn-passkeys-prf-
         | demo.explore.corbado.com/ works with an iCloud Keychain passkey
         | on Safari on macOS 15.5, but Typage doesn't work with a YubiKey
         | 5, so there is _some_ support (the MDN data is out of date) but
         | also something weird.
        
         | lxgr wrote:
         | I'm pretty sure Safari supports it since iOS 18! See for
         | example https://www.corbado.com/blog/ios-18-passkeys-automatic-
         | passk... and https://www.corbado.com/blog/passkeys-prf-
         | webauthn.
        
       | neutrinoq wrote:
       | For a simple web app that encrypts files with passkeys, check out
       | https://filekey.app
        
       | 9dev wrote:
       | This enables a few cool use cases, like uploading sensitive,
       | client-side encrypted documents, and storing them on behalf of
       | the user--without even being able to peek inside--all with the
       | convenience of passkeys!
        
         | megous wrote:
         | Nothing that the user can trust, though.
         | 
         | Only way to upload sensitive data is to encrypt it yourself,
         | while handling all the secret key material yourself, and then
         | upload the result. You can't trust the website, when it has
         | access to the secret key, regardless of whether it was derived
         | from FIDO2 HMAC or whatever.
        
           | lxgr wrote:
           | Trust isn't absolute.
           | 
           | Deploying a malicious version of a given webapp is still
           | harder (and much more visible) than just silently dumping a
           | backend database, so I'd trust an implementation that client-
           | side encrypts my data using PRF and passkeys significantly
           | more than one just uploading everything in plaintext.
        
           | 9dev wrote:
           | Huh? But that's the entire point. The website only knows your
           | public key. The encryption happens locally, within the secure
           | code of the authenticator, far away from the website.
        
             | skybrian wrote:
             | The decrypted data is stored in a JavaScript variable. The
             | JavaScript is under full control of the website owner.
             | Adding telemetry to a website is pretty easy.
             | 
             | It would simplify website operations and eliminate some
             | kinds of security bugs, though.
        
         | skybrian wrote:
         | This could simplify things a bit for website owners since they
         | don't need to protect a database where they store encryption
         | keys. Bugs or supply-chain attacks on client-side software are
         | still a vulnerability, though.
         | 
         | For the customer, they are unlikely to be able to audit the
         | client-side software and any updates to it, so it still
         | requires trust. The software could still have a lot of
         | telemetry baked in.
         | 
         | Maybe someday there will be something like certificate
         | transparency for software?
        
       | wkat4242 wrote:
       | I wonder if this can replace the PGP backend from "pass":
       | https://www.passwordstore.org/
       | 
       | I don't really _want_ to replace it. It works fine. But the
       | toolchain for other platforms is becoming difficult to manage. I
       | use pass with PGP Yubikeys as backing for each encrypted
       | password. But the developer of the Android version has stopped
       | supporting it and the person who took it over has removed yubikey
       | support because he doesn 't use it himself and doesn't care about
       | it.
       | 
       | Of course I need to access my passwords on Linux, Windows, Mac,
       | Android. Only iOS is not possible because Apple doesn't allow raw
       | APDU access to NFC tags so you can't do OpenPGP functions.
       | 
       | I also don't want to use a password manager with a single master
       | password like bitwarden. I want each password to be encrypted
       | individually with the public key from a number of hardware tags
       | (multiple, that's also a hard requirement). This way not my whole
       | password database is instantly leaked when my master password
       | gets compromised. Even when my endpoint gets completely
       | compromised, the only passwords they will have are the ones I
       | decrypted on it since it was compromised. Yubikeys require a
       | physical touch for every decryption so you also can't 'milk' them
       | for credentials when they're inserted and unlocked. Also, any
       | password manager I use must be self-hosted, I hate and don't
       | trust the big tech companies.
       | 
       | I wonder if this could be a new backend. And have support on all
       | platforms (though iOS I don't care about personally, but it would
       | be a nice to have).
        
         | megous wrote:
         | I think my dream password manager currently is a Pinephone with
         | a special custom UI that allows for managing and securing a
         | list of accounts/passwords that can type them out via USB HID
         | keyboard gadget when prompted.
         | 
         | No way to prompt it for data, or compromise it remotely.
         | 
         | No other features, no OS userspace, no wifi, no adb, no
         | nothing. Just a Linux kernel + a tiny single userspace static
         | binary based on lvgl for UI and libsodium for
         | encryption/storage. Normally powered off, boots in 2 seconds.
         | :)
        
           | bee_rider wrote:
           | Why a phone, though? The device doesn't need any connectivity
           | other than to act as a USB "keyboard," right? Maybe a
           | raspberry pi zero could do it.
        
           | lxgr wrote:
           | Tons of ways to compromise it between your computer's USB
           | port and the server's database, though. If you already have
           | dedicated hardware, FIDO authenticators make much more sense.
           | 
           | > Just a Linux kernel [...]
           | 
           | That's several orders of magnitude more lines of code than
           | any FIDO authenticator implementation.
           | 
           | > Normally powered off, boots in 2 seconds. :)
           | 
           | Yubikeys boot even faster!
        
             | wkat4242 wrote:
             | Yeah and also it's huge for just a password manager.
        
         | faeranne wrote:
         | Checkout passage: https://github.com/FiloSottile/passage which
         | has done part of this by using age instead of pgp. I used it
         | for a while, and last I checked there was sadly no android app
         | (the pass android app hardcoded too much PGP to be a useful
         | base, so I was told), but the work is def there.
        
           | wkat4242 wrote:
           | > Checkout passage: https://github.com/FiloSottile/passage
           | which has done part of this by using age instead of pgp.
           | 
           | Nice! But I can't really use it until it works on Android too
           | (with hardware keys). I'll definitely try it out though.
           | 
           | > the pass android app hardcoded too much PGP to be a useful
           | base
           | 
           | The original one did not. It leveraged the OpenKeyChain
           | external app which basically handles all the PGP stuff. So
           | there was no PGP code in the app. Similar to how it's done on
           | a PC with the gpg suite
           | 
           | But someone rewrote it with an internal library which also
           | removed Yubikey support.
        
       | phoronixrly wrote:
       | Now do one for signing Linux packages with <insert anything else
       | but GnuPG>...
        
         | FiloSottile wrote:
         | You'll never believe what I (and a bunch of folks) have been
         | working on for years :)
         | 
         | https://www.sigsum.org
         | 
         | https://github.com/FiloSottile/torchwood/tree/main/cmd/apt-t...
         | 
         | https://www.youtube.com/watch?v=SOfOe_z37jQ
         | 
         | https://c2sp.org/tlog-tiles
        
         | pluto_modadic wrote:
         | sigstore, lol
        
       | hoppp wrote:
       | What devices support the prf extension? Been waiting for it to
       | get support for years
        
       | sneak wrote:
       | What good timing. I am gearing up for a 1.0 release of a tool I
       | wrote that stores secrets on disk (sort of like a local hashicorp
       | vault/aws secrets manager) that uses age internally.
       | 
       | https://git.eeqj.de/sneak/secret
       | 
       | It has a tiered architecture where several different types of
       | "unlockers" can access the main vault key. I haven't added
       | passkey support yet but it does do gpg and macOS keychain, and
       | secure enclave support is planned (but delayed due to the fact
       | that you cannot use the secure enclave even on a local device you
       | own without a paid/doxxed Apple Developer Program membership for
       | the correct entitlements).
        
       ___________________________________________________________________
       (page generated 2025-07-15 23:00 UTC)