[HN Gopher] Show HN: Cocert: split your private keys securely am...
___________________________________________________________________
Show HN: Cocert: split your private keys securely amongst untrusted
network
Author : Dentrax
Score : 30 points
Date : 2021-05-25 11:34 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| mikeiz404 wrote:
| 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 wrote:
| 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...
| rozab wrote:
| See also https://github.com/jesseduffield/horcrux
| Dentrax wrote:
| 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 wrote:
| Yep, Cocert seems like a really smooth and elegant solution
| to that specific problem!
| joe_g_young wrote:
| 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/
| ignoramous wrote:
| 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/
___________________________________________________________________
(page generated 2021-05-26 23:02 UTC)