Ämne:Re: [dcdev] Encrypting ADC - a second approach
Till:Direct Connect developers
Oh, so _that's_ what the 30 year old Diffie-Hellman algo is for... Well, it sure sounds reasonable. So then, what about RSA -> Diffie-Hellman -> AES(or other negotiated symmetric key)? Or simply skip the RSA part? I don't have any experience with RSA in OpenSSL, I'm not sure it'll generate everything for you (d, e, n etc), and this would be very nice not to have to do yourself.
And as I said, the private keys can easily be protected anyway. AES them with a password for instance. But maybe this is only reasonable on hubs that rarely restart.
Well, to make it totally transparent as to just being unrecognizable traffic is impossible. Even if the hand-shake is extremely like HTTPS the continuous traffic is still the same. Trying too much to make it unrecognizable isn't worth it I think.
Hmm, well yeah. Using the fields they way we feel is pleasing, well... Is it okey if I still just don't like certificates at all? ;)
And btw Df_Offset, ciphers like blowfish might be fast but comes with a draw-back in my opinion. It's by far too complex. In the competition for being _the_ AES algorithm, most people didn't understand blowfish, they simply didn't get the code, and the authors being open source 'hackers' had problems mathematically proving its concept. The same applies for any 'difficult' algorithm, even Rijndael being very algebraic. The more difficult it gets to understand the more dangerous it is for future flaws found by geniuses that actually understand it thoroughly.