> On 26 May 2015, at 23:42, Kasper Dupont <kasperd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > On 26/05/15 15.50, Daniel Kahn Gillmor wrote: >> The argument that the DNS lookup leaks this metadata is a bad argument: >> if we followed this line of reasoning, then every problem that has >> multiple contributors could never be solved (A says "but my fixing >> things is useless if B does nothing", while B says "but my fixing things As a practical suggestion - we ran for a while with a hack where we abuse the version human readable string with a base64 string of a _salted_ hash of the server we where trying to get to. Sharing both salt and hash. This let the server figure out the right key to present without too much ado; but without leaking all that much*. The idea was to make it a tiny bit more costly to get a decent selector really early in a connection. However - as keeping a few 10’s of packets in state is no longer that costly; key init and exchange always start at a packet; And the DH modulus (identical but for its last for bytes) in the DH group exchange (31) and what not follow soon thereafter; it seems all a bit superfluous. Dw. *; Except of course - the fairly unqiue Key Kexchange Init and then the very unique Key Exchange Init of the server following in the clear - so one has to be careful with these; or intentionally reuse them. Which is why it fell in disuse soon thereafter. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
