5 ms·

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

37 points by Dentrax 5y ago

mikeiz404 5y ago
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.
- Dentrax 5y ago
  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/encrypted/encrypted.go https://github.com/theupdateframework/go-tuf/blob/master/enc... [1] https://raw.githubusercontent.com/Dentrax/cocert/main/.res/use-case.png https://raw.githubusercontent.com/Dentrax/cocert/main/.res/u...
rozab 5y ago
See also https://github.com/jesseduffield/horcrux https://github.com/jesseduffield/horcrux
- joe_g_young 5y ago
  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/ https://ocsdtreasurehunt.netlify.app/
- Dentrax 5y ago
  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.
  - rozab 5y ago
    Yep, Cocert seems like a really smooth and elegant solution to that specific problem!
ignoramous 5y ago
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 https://news.ycombinator.com/item?id=21838413 [1] https://keybase.io/triplesec https://keybase.io/triplesec [2] https://blog.cloudflare.com/opaque-oblivious-passwords/ https://blog.cloudflare.com/opaque-oblivious-passwords/

37 points by Dentrax 5y ago

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.

Dentrax 5y ago
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/encrypted/encrypted.go https://github.com/theupdateframework/go-tuf/blob/master/enc... [1] https://raw.githubusercontent.com/Dentrax/cocert/main/.res/use-case.png https://raw.githubusercontent.com/Dentrax/cocert/main/.res/u...

rozab 5y ago

See also https://github.com/jesseduffield/horcrux https://github.com/jesseduffield/horcrux

joe_g_young 5y ago
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/ https://ocsdtreasurehunt.netlify.app/
Dentrax 5y ago
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.
- rozab 5y ago
  Yep, Cocert seems like a really smooth and elegant solution to that specific problem!

ignoramous 5y ago

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 https://news.ycombinator.com/item?id=21838413 [1] https://keybase.io/triplesec https://keybase.io/triplesec [2] https://blog.cloudflare.com/opaque-oblivious-passwords/ https://blog.cloudflare.com/opaque-oblivious-passwords/