3 ms·
> but the problem seems to be reduced to a problem of safely distributing keys, That's just a standard problem for asymmetric cryptography. Each person at the
by nullc 7y ago
> but the problem seems to be reduced to a problem of safely distributing keys,
That's just a standard problem for asymmetric cryptography.
Each person at the table announces a public key. Each party can now derive a shared secret with each other party using diffie-hellman. The shared secret can be used to produce a pseudorandom stream using a CSPRNG or stream cipher.
- tearex 7y agoYes, and this is now a question if you can trust that the other person is not the adversary so we introduce trusted third parties and certificates.
- nullc 7y agoOne doesn't need to use trusted third parties to use public keys. In fact, the most popular existing TTP public key infrastructure provides extremely limited security (someone who can intercept http near an IP where your domain name resolves can easily obtain an SSL cert with your domain name on it).
- stonedartist 7y ago>someone who can intercept http near an IP where your domain name resolves can easily obtain an SSL cert with your domain name on it Sorry to hijack this thread, can you please give me a keyword or link as to what this type of attack is called? I have plans to host a domain, so wanted to know what this threat is called. Thanks!
- nullc 7y agoI'm not sure what you'd call it other than man-in-the-middle. The issue is that CA's (for various defensible reasons-- including that there isn't much better possible within their framework, it's not like they know you personally...) will issue a cert for your domain to any party that can throw a file up on it that their automation fetches via http. In practice this means a MITM near your server (or, technically, anywhere between any CA that will issue certs for your domain and your server), or between your CA and the DNS results can get certs for your name and there isn't much you can do about it.