<p dir="ltr"> <br>
Den 25 feb 2015 20:18 skrev "Chris Tonkinson" <<a href="mailto:chris@tonkinson.com">chris@tonkinson.com</a>>:<br>
[...] <br>
> What if we were to take a leaf out of TORs book, and layer "reverse" PKI<br>
> (with e.g. PGP) inside of TLS for HTTPS?<br>
><br>
> Suppose my UA has access to a locally generated keypair. Could be a<br>
> pre-generated and [relatively] long-lived keypair, or it could be<br>
> transient, surviving a single request-response cycle - doesn't matter.<br>
> Upon completion of the TLS handshake, the first request from my UA to<br>
> the server would include the public key for this pair. The response,<br>
> then, would be encrypted to this public key.</p>
<p dir="ltr">Yes you could, but in every place I can think of where you could add functional support for an encryption layer on top of TLS would be better served by dropping TLS and using the second encryption scheme alone. You'd need every application to support it natively. </p>
<p dir="ltr">By the way, both Tor and I2P already works on Android (Orbot and the I2P client on F-Droid). Both support public key based addresses (hidden services / eepsites) for use inside the encrypted networks. The address itself becomes the certificate. Both support access via local proxies on the device, so most standard software supports it transparently if you can tell it to connect over HTTP via that proxy to those domains (the Tor and I2P clients will resolve the domain, encrypt and direct the traffic appropriately). </p>
<p dir="ltr">There's also CJDNS as a similar option for secure routing, but without the anonymization (intended for secure mesh networking rather than being an overlay anonymization network). So far only available for standard Unix-y operating systems. </p>