Show HN: Cocert: split your private keys securely amongst untrusted network | Hacker News Reader

Show HN: Cocert: split your private keys securely amongst untrusted network

github.com

37 pointsDentrax7 comments

Horcrux is interesting. This is my take on it. I combined Horcrux with image steganography to make a mock online treasure hunt.

https://ocsdtreasurehunt.netlify.app/

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.

Yep, Cocert seems like a really smooth and elegant solution to that specific problem!

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?

Seems like a neat project.

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]

[0] https://github.com/theupdateframework/go-tuf/blob/master/enc... [1] https://raw.githubusercontent.com/Dentrax/cocert/main/.res/u...

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.

[0] https://news.ycombinator.com/item?id=21838413

[1] https://keybase.io/triplesec

[2] https://blog.cloudflare.com/opaque-oblivious-passwords/

Reply on news.ycombinator.com