Hi Bill, I am sorry, but I do not understand what you are proposing. Do you think you could try restating the computation you have in mind, perhaps by providing an equation that explains the construct?
Thanks, -Ekr On Mon, Nov 30, 2015 at 6:07 PM, Bill Cox <[email protected]> wrote: > I don't think even I agree with this idea, but I'll put it out there > anyway. > > We're seeing some new secure computing modes in ARM and Intel processors. > Arm has TEE, and Intel has SGX. Both modes basically run at the same speed > as the CPU... in theory. > > There are potential benefits to securing the read/write session keys in > these modes. For example, if malware is doing evil things over your > connections, when you remove the malware or close your laptop, the > encryption keys are out of reach, and the connections go dead. Otherwise, > malware might export the keys where they could be used to resume a session, > for example, enabling an attacker to continue doing evil. This is possible > today over TLS 1.2, even when using Client Certificates. > > However, there are overhead costs for moving data in/out of these > execution zones, and overhead when switching back and forth. Execution > speed is a little slower in these modes for various reasons. For maximum > speed, I might want a separate HMAC/HKDF key besides the read/write keys. > That way, I keep just the HMAC/HKDF key in a secure execution zone, and > only have to do one small operation with it per AEAD call per TLS record. > > This is just a dumb efficiency hack. I hate leaving either speed or > security on the table if I can have both :) However, complexity harms > security, so even I don't really think this is a good idea. Is there > anyone who feels even more strongly about speed than me? > > Bill > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
