Gustaf Räntilä wrote:

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.

Picking off technical inaccuracies that taken together suggest that designing one's own protocol is indeed tricky, and error-prone (as someone's hinted, read about SSHv1 and SSLv2. Both were, and unfortunately are, widely used.):

(1) DH doesn't imply PFS. It is neither necessary nor sufficient. Your sketches of a possible protocol elucidate essentially nothing, though, so I can't usefully comment more.

(2) Different traffic patterns might betray the nature of encrypted DC traffic despite all other masking - but, for example, forcing ISPs into doing such analysis opens them up to false positives detrimental to business, among other risks.

(3) Disliking certificates is fine. One should not, however, refuse to recognize their possible utility, and claim to be designing good crypto. (The details of this are currently unimportant, though they should be discussed.)

(4) Blowfish was never submitted as an AES candidate. Twofish was. The rest of the section strikes me dubiously too: Schneier is an open source hacker only able with difficulty to mathematically prove the concept? Read http://www.schneier.com/twofish.html ; while depending on the rigor one's looking for, they don't prove that there may never in the future be a break in an algorithm, they show that most existing techniques don't work.

-cologic