Hi Benjamin: It sounds to me like you'd probably have better luck adding to the TLS protocol by taking this discussion to the IETF TLS working group.
While there are a number of protocol experts on this list, I think that your idea would get more of a workout on the list where the people that standardized the protocol hang out. One thing that I would suggest to you - before you send the question to the IETF mailing list, figure out your step 5 - And remember, there is MUCH more to the exchange of certificates in an SSL conversation than just the crypto. Actually, upon a bit more reflection, what you may, in fact be asking, is to replace the asymmetric public key in a Certificate with a symmetric key, since you want to keep all of the ID stuff in the protocol. Your problem is going to be that what SSL is meant to do is to allow two parties that have no prior knowledge of each other to identify and trust each other - symmetric cryptography has, as it's basis, an assumption of a "shared secret"... in the standard case, it happens as a second order "session key", a shared secret that is negotiated once the asymmetric key "stuff" (including ID validation through the use of certificates) happens. If I were you, I would start by reading all of the RFC documentation on the TLS protocol (and cryptographic protocols in general), and then, if you still think that you can propose a complete and workable solution, write up a proposal and send it to the IEFT TLS working group. Have fun. Patrick Patterson Chief PKI Architect Carillon Information Security Inc. Benjamin Gittins wrote: > Hi, > > I am new to the TLS/SSL protocol. > > I am exploring the idea of extending OpenSSL to perform authenticated > key exchanges using symmetric techniques running from smart cards and > falling back to asymmetric key exchanges in the normal way if the smart > cards are not present or do not recognise each other. > > The motivation is that authenticated key exchanges based on AES-256 and > SHA-512 are considered secure against quantum computing attacks (Shor's > and Grover's quantum algorithms) where algorithms such as RSA and ECC > are widely considered insecure. > > The proposal in its simplest form: > 1) Two smart cards each have a randomly selected ID (256-bit random > number) and share a 256-bit symmetric key mapped to the pair of ID's > 2) One of the smart cards is installed on the server, the other on a > client machine > 3) The SSL server connects with its smart card, the client does the same > 4) The SSL client establishes a connection with the SSL server > 5) Somehow the smart cards announce their identities via the modified > SSL protocol without interfering with the normal ID process. > 6) If the smart cards recognise each others ID the smart cards perform > an authenticated key exchange using their shared secret to generate the > sessions keys for encryption and message authentication. If this step > fails the protocol stops. > 7) If the smart cards do not recognise the other's ID the protocol > continues using unmodified asymmetric techniques. > 8) In some applications the software calling the SSL may make a decision > to stop if the smart card key exchange failed. > > I'm interested to find out if anyone has attempted something similar and > for general feedback from people intimately familiar with the SSL/TLS > protocols. > > It is clearly important that the modified version of the SSL protocol > remains interoperable with unmodified SSL/TLS implementations and that > the modified protocol does not interfere with the stability of the > established SSL/TLS user base. > > Thanks and best regards, > > Benjamin Gittins > > Chief Technology Officer > Synaptic Laboratories Limited > > W: http://synaptic-labs.com > W: http://vestciphers.com > W: http://hardware-ciphers.com > > E: [email protected] > T: +356 9944 9390 (mobile) > TZ: CET (UTC+1) > > This email and its zero or more attachments contains confidential material. > If you receive this email in error, please contact me immediately. > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
