4 ms·

I just looked through the website and I’m struggling to understand exactly how it works - how do you have signing / verification without the risk of key comprom

I just looked through the website and I’m struggling to understand exactly how it works - how do you have signing / verification without the risk of key compromise?

dwheeler 4y ago
I may be misunderstanding your question, but here is the answer if I understand you correctly. This is all based on public key cryptography. In public key cryptography, there are actually 2 keys, a public key and a private key. Sites like get hub and the repose can store the public keys, while into while individual users keep their private key's secret. Anyone with the public key can verify a signature, but only an individual with the private key can create the equivalent signature. The trick is to determine if a given public key corresponds to an individual. There are various methods to try to address that. I hope that helps!
Foxboron 4y ago
The same way LetsEncrypt makes compromised TLS certificates (almost) useless; short-lived certificats. What the sigstore project does is having an oauth portal which can authenticate one of your online identities. It uses this to sign a temporary certificate for you with it's root CA. This certificate is what you use to sign commits and artifacts with.
- wlynch 4y ago
  +1 to this! https://docs.sigstore.dev/fulcio/certificate-issuing-overview https://docs.sigstore.dev/fulcio/certificate-issuing-overvie... has a good overview of how the certificate issuing works. With Gitsign, by default a new keypair is generated per signing event (i.e. per commit) and never hits disk. The cert in the commit signature holds the public key, which we can check against Rekor (https://docs.sigstore.dev/rekor/overview https://docs.sigstore.dev/rekor/overview) to verify it was valid at the time of signing. If you have the time, https://www.youtube.com/watch?v=PVhRQFS9Njg https://www.youtube.com/watch?v=PVhRQFS9Njg is a great deep dive into how Sigstore works in general!
- deleted 4y ago
  [deleted]

I just looked through the website and I’m struggling to understand exactly how it works - how do you have signing / verification without the risk of key compromise?

dwheeler 4y ago

I may be misunderstanding your question, but here is the answer if I understand you correctly. This is all based on public key cryptography. In public key cryptography, there are actually 2 keys, a public key and a private key. Sites like get hub and the repose can store the public keys, while into while individual users keep their private key's secret. Anyone with the public key can verify a signature, but only an individual with the private key can create the equivalent signature. The trick is to determine if a given public key corresponds to an individual. There are various methods to try to address that. I hope that helps!

Foxboron 4y ago

The same way LetsEncrypt makes compromised TLS certificates (almost) useless; short-lived certificats. What the sigstore project does is having an oauth portal which can authenticate one of your online identities. It uses this to sign a temporary certificate for you with it's root CA. This certificate is what you use to sign commits and artifacts with.

wlynch 4y ago
+1 to this! https://docs.sigstore.dev/fulcio/certificate-issuing-overview https://docs.sigstore.dev/fulcio/certificate-issuing-overvie... has a good overview of how the certificate issuing works. With Gitsign, by default a new keypair is generated per signing event (i.e. per commit) and never hits disk. The cert in the commit signature holds the public key, which we can check against Rekor (https://docs.sigstore.dev/rekor/overview https://docs.sigstore.dev/rekor/overview) to verify it was valid at the time of signing. If you have the time, https://www.youtube.com/watch?v=PVhRQFS9Njg https://www.youtube.com/watch?v=PVhRQFS9Njg is a great deep dive into how Sigstore works in general!
deleted 4y ago
[deleted]