> > The impact on supervision will be particularly severe. Financial > institutions are required by law to store communications of certain employees > (including broker/dealers) in a form that ensures that they can be retrieved > and read in case an investigation into improper behavior is initiated. The > regulations which require retention of supervised employee communications > initially focused on physical and electronic mail, but now extend to many > other forms of communication including instant message, social media, and > collaboration applications. All of these communications channels are > protected using TLS. > > In the past ten years, we have seen botnets, root kit trojans, root kit DRM, NSA TAO implants, OpenSSL heartbleed, heartbleed-style attack against Cisco routers, cold boot attacks against expanded subkeys from a linear key schedule, etc, etc...
I do not think encryption to be an obstacle of any kind. Just use a forward proxy and move encryption from the browser to a dedicated appliance? https://github.com/joshdick/miniProxy <- just from Googling "php proxy" And I think the only way to protect against heartbleed is require private keys larger than than the MTU. But private keys are kind of pointless nowadays when google has their private keys on thousands of machines around the world. Although DH depends on both parties generating a high entropy secret. Personally I think the observation by an NTRU employee on NTRU-KE is better than DH: https://github.com/NTRUOpenSourceProject/NTRUEncrypt/issues/7 "We probably won't implement this exact idea -- this is basically each side encrypts a secret, sends to the other, and puts the result through a KDF, but with the slightly artificial choice that the encrypted secret is also the private key and the KDF involves multiplication. Currently you can get the properties that NTRU-KE gives (i.e. that both sides contribute secret randomness) simply by using standard NTRU in each direction to send two secrets and it's not clear what advantages NTRU-KE would have over that. There may be room for a custom key exchange scheme in the future, but we'd want to make sure it had advantages over the obvious way of doing it. This shouldn't be a problem, but in the internet of things, DH is actually less secure than normal public key exchange. Servers are more likely to have entropy than embedded devices. Ultimately, the world is insane.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
