4 ms·

Domain name/identity and key pinning has always been the only useful use of NFTs that I can think of. Today, to encrypt your communications with people, you us

by baby 6y ago

Domain name/identity and key pinning has always been the only useful use of NFTs that I can think of. Today, to encrypt your communications with people, you use something like PGP or Signal which rely on "trust on first use (TOFU) but verify", in practice people don't really verify so it's more like TOFU. This means that if someone compromised the session at the moment where it was created (or re-created), then your communication are being snooped on. Today, to encrypt your communication to websites, you use HTTPS which rely on a vast network of certificate authorities. Any of these actors misbehaving leads to potential attacks. Because of that, the Certificate Transparency project was created to _potentially_ catch bad actors, that is if you check for your own domains regularly. Using a consensus-based registry, you can prevent (better than detect) attacks in both of these scenarios. Let people register their identity or domain name, and associate a public key to it that can be used to encrypt communications with the identity/domain, as long as the number of dishonest actors remain under a threshold no attacks are possible. The only (albeit not small) downside is that by taking middle men out of the picture, the naive approach prevents account recovery from happening. So to be practical, you need to find the right middle ground.

cracker_jacks 6y ago
> no attacks are possible I think this just shifts the responsibility and point of attack onto the owner (which is true for all decentralized crypto). An attack is still possible and worse yet, it is completely irreversible. That said, the option of taking personal custody and responsibility is important and I think it should always be an option.
- mrnobody_67 6y ago
  Honeypot is much smaller. Any centralized source of data is very attractive and worth spending a lot of time & effort on and inevitable gets hacked: https://en.wikipedia.org/wiki/List_of_data_breaches https://en.wikipedia.org/wiki/List_of_data_breaches
- baby 6y ago
  > I think this just shifts the responsibility and point of attack onto the owner The owner is always a target, it doesn't change that, it just removes a bunch of single points of failure and middle men. > An attack is still possible and worse yet, it is completely irreversible Attacks are always possible, but depending on your threat model you do end up eliminating a number of them. As I said, with a naive implementation you make an attack irreversible, but it's not impossible to imagine an optional, committee base KYC-based account recovery mechanism.
hadcomplained 6y ago
> Today, to encrypt your communication to websites, you use HTTPS which rely on a vast network of certificate authorities. This fact has been irritating me for a long time. Because no one should believe that every single certificate authority is tolerant to any attempts to steal the private keys. But that is exactly the underlying assumption behind HTTPS being the only way to use HTTP in a more secure manner than exchanging in plaintext. Let's think about this scenario: Suppose that I built a web service for my personal use and hosted it in public cloud. I don't trust any certificate authorities, so I created my own TLS certificate without using them. I installed my own certificates on the machine from which to connect to my web service. Now the server for my web service is serving in HTTPS using my own certificate. Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM. The problem of being forced to trust certificate authorities can be solved by adding the feature to embed a public key in a url. For example, it would be wonderful to have a url like httpsecure://rsa:PUBLICKEY/example.com/ to make sure example.com always responds using the key PUBLICKEY. IIRC, the Tor onion services is an instance of this -- the .onion domains include public keys.
- judge2020 6y ago
  > Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM. You're probably more safe than you'd think. Certificate Transparency is now required for Chrome, Firefox, or Safari or you'll get an error message during the TLS connection, before any private data is sent to the (potentially MITM'd) site. Given that all certificates are logged, site operators can use some of the many CT alert websites to let them know if and when a new certificate is issued for their domain, so if some random authority they haven't heard of before issues a cert or it's done at a time they know they didn't need to renew their certs, it'd be time to raise major alarms about the occurrence and thus would mean instant loss of all business for that authority; plus, shockwaves would be sent across the internet as this would be a huge event, especially if it's against a company worth burning a CT for (eg. Google which houses so many fortune 500 companies' secrets). > the .onion domains include public keys. The .onion domain is, in itself, a public key. The side effects of your proposed solution are: A) it would mean you HAVE to trust whoever sent you a link A) 1) for web-based referrals, this would mean you trust your (possibly state-sponsored) search engine to never MITM you (this is currently mitigated by CT which would expose Google's GTS issuing a random domain's cert) A) 2) for IRL events, this would mean you have to trust that the business themselves put up a certain QR code with the public key and not some malicious actor B) This would mean site.com could never rotate their private key without changing all of their backlinks to one with the correct public key. These are all problems Tor already faces - you have no idea if the onion site you're linked to is actually the site it says it is if it perfectly mimics it and/or reverse proxies the real site. You're currently always advised to get URLs from a trusted source once then only use bookmarks to access them to prevent reverse engineering. And you can't rotate your private key without doing this domain change.

by baby 6y ago

cracker_jacks 6y ago

> no attacks are possible I think this just shifts the responsibility and point of attack onto the owner (which is true for all decentralized crypto). An attack is still possible and worse yet, it is completely irreversible. That said, the option of taking personal custody and responsibility is important and I think it should always be an option.

mrnobody_67 6y ago
Honeypot is much smaller. Any centralized source of data is very attractive and worth spending a lot of time & effort on and inevitable gets hacked: https://en.wikipedia.org/wiki/List_of_data_breaches https://en.wikipedia.org/wiki/List_of_data_breaches
baby 6y ago
> I think this just shifts the responsibility and point of attack onto the owner The owner is always a target, it doesn't change that, it just removes a bunch of single points of failure and middle men. > An attack is still possible and worse yet, it is completely irreversible Attacks are always possible, but depending on your threat model you do end up eliminating a number of them. As I said, with a naive implementation you make an attack irreversible, but it's not impossible to imagine an optional, committee base KYC-based account recovery mechanism.

hadcomplained 6y ago

> Today, to encrypt your communication to websites, you use HTTPS which rely on a vast network of certificate authorities. This fact has been irritating me for a long time. Because no one should believe that every single certificate authority is tolerant to any attempts to steal the private keys. But that is exactly the underlying assumption behind HTTPS being the only way to use HTTP in a more secure manner than exchanging in plaintext. Let's think about this scenario: Suppose that I built a web service for my personal use and hosted it in public cloud. I don't trust any certificate authorities, so I created my own TLS certificate without using them. I installed my own certificates on the machine from which to connect to my web service. Now the server for my web service is serving in HTTPS using my own certificate. Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM. The problem of being forced to trust certificate authorities can be solved by adding the feature to embed a public key in a url. For example, it would be wonderful to have a url like httpsecure://rsa:PUBLICKEY/example.com/ to make sure example.com always responds using the key PUBLICKEY. IIRC, the Tor onion services is an instance of this -- the .onion domains include public keys.

judge2020 6y ago
> Am I safe? No. Because any entity with access to the private key of any of the certificate authorities trusted by my machine, is capable of intercepting the communication between my machine and my server, simply by MITM. You're probably more safe than you'd think. Certificate Transparency is now required for Chrome, Firefox, or Safari or you'll get an error message during the TLS connection, before any private data is sent to the (potentially MITM'd) site. Given that all certificates are logged, site operators can use some of the many CT alert websites to let them know if and when a new certificate is issued for their domain, so if some random authority they haven't heard of before issues a cert or it's done at a time they know they didn't need to renew their certs, it'd be time to raise major alarms about the occurrence and thus would mean instant loss of all business for that authority; plus, shockwaves would be sent across the internet as this would be a huge event, especially if it's against a company worth burning a CT for (eg. Google which houses so many fortune 500 companies' secrets). > the .onion domains include public keys. The .onion domain is, in itself, a public key. The side effects of your proposed solution are: A) it would mean you HAVE to trust whoever sent you a link A) 1) for web-based referrals, this would mean you trust your (possibly state-sponsored) search engine to never MITM you (this is currently mitigated by CT which would expose Google's GTS issuing a random domain's cert) A) 2) for IRL events, this would mean you have to trust that the business themselves put up a certain QR code with the public key and not some malicious actor B) This would mean site.com could never rotate their private key without changing all of their backlinks to one with the correct public key. These are all problems Tor already faces - you have no idea if the onion site you're linked to is actually the site it says it is if it perfectly mimics it and/or reverse proxies the real site. You're currently always advised to get URLs from a trusted source once then only use bookmarks to access them to prevent reverse engineering. And you can't rotate your private key without doing this domain change.