Maybe I’m not understanding something here but don’t you still need to store the password securely? If you can store the password securely can you not then also store the private keys securely?
Actually, we store the passwords inside the PEM file itself, which is encrypted by TUF [0].
> If you can store the password securely can you not then also store the private keys securely?
You don't have to store the private keys securely. On the contrary, you can store your private keys publicly, if the decryption password strong enough.
If you want to decrypt keys in the pipeline, of course your decryption keys still need to be stored securely. Which is why I added some KMS providers in the use-case diagram. [1]
That's so cool! If I knew this, I could get some use-case scenario inspirations. But still, you are able to sign your content of diaries with the cocert.
This is interesting. As someone who's been reading literature related to WebAuthn and FIDO2, I was very much curiously looking at various vault designs that stored secrets away (either ed-dsa identity subkeys or 25519-dh encryption subkeys) other than in FIDO2-certified server-vaults or user-held FIDO2 keys.
From among the designs that looked decent to my untrained eye (not a cryptographer) were that of Apple's and Signal's [0]. The thing they had in common was they wanted to gatekeep attempts to brute-force (one half of the) the secret they stored on behalf of the user, via either binding them in HSMs or secure enclaves.
Keybase instead do what they call TripleSec [1], which seems like a cheaper solution compared to Apple's / Signal's, and relies on multi-cipher encryption scheme to thwart brute-force attempts.
One area that I've been increasingly looking at is OPRF (Oblivious Pseudo Random Functions) [2] and the use-cases it may enable, especially in replacing the HSMs or secure enclaves whilst retaining similar properties against brute-force attacks.
7 comments
[ 2.0 ms ] story [ 27.8 ms ] threadSeems like a neat project.
> If you can store the password securely can you not then also store the private keys securely?
You don't have to store the private keys securely. On the contrary, you can store your private keys publicly, if the decryption password strong enough.
If you want to decrypt keys in the pipeline, of course your decryption keys still need to be stored securely. Which is why I added some KMS providers in the use-case diagram. [1]
[0] https://github.com/theupdateframework/go-tuf/blob/master/enc... [1] https://raw.githubusercontent.com/Dentrax/cocert/main/.res/u...
https://ocsdtreasurehunt.netlify.app/
From among the designs that looked decent to my untrained eye (not a cryptographer) were that of Apple's and Signal's [0]. The thing they had in common was they wanted to gatekeep attempts to brute-force (one half of the) the secret they stored on behalf of the user, via either binding them in HSMs or secure enclaves.
Keybase instead do what they call TripleSec [1], which seems like a cheaper solution compared to Apple's / Signal's, and relies on multi-cipher encryption scheme to thwart brute-force attempts.
One area that I've been increasingly looking at is OPRF (Oblivious Pseudo Random Functions) [2] and the use-cases it may enable, especially in replacing the HSMs or secure enclaves whilst retaining similar properties against brute-force attacks.
[0] https://news.ycombinator.com/item?id=21838413
[1] https://keybase.io/triplesec
[2] https://blog.cloudflare.com/opaque-oblivious-passwords/