[Cryptography] IPsec DH parameters, other flaws

jrzx jrzx at protonmail.ch
Tue Nov 17 15:47:05 EST 2020


> On 11/14/20 1:17 AM, iang wrote:
>> The NIST AES process showed one way: a knock down competition. Set the
>> requirements, invite open submissions. Only one proposal wins. Set a
>> schedule. Stick to it. Thunderdome. 30 proposals enter, 1 leaves.

On 2020-11-16 18:57, Stephan Neuhaus wrote:
> [...]> So let's say that NIST organises a competition and "TCPng" wins. So
> what? Why on Earth should anyone implement that thing when it cannot
> give them an edge? (I realise that this is an argument from incredulity,
> so I'd be happy to hear counterarguments.)

Presumably because TCPng would give them an edge.

TCP was designed in more trusting times, when the name system consisted of a widely shared hosts file, and everyone trusted everyone.

Over the years people have piled warts on top of TCP and warts on top of warts to fix one problem after another, and every fix results in additional round trips

Thus "Cloudfare is checking your browser, you will be redirected shortly"

Every additional round trip before a web page comes up results in a significant loss of viewers.

TCP is a major problem, which is slowing down the internet. DDOS protection and the certificate mess are warts growing on top of warts.

If TCPng fixes those warts, you get more views.

TCPng needs to reply with a proof of work request when a client requests a connection, as the second phase of the four phase handshake, where the work demanded goes up as the server load increases, thus fixing the horrors of DDOS protection.

Key agreement needs to be part of the TCPng handshake, rather than a layer on top, to reduce round tripping.

The name system needs to be integrated with the key system, so that you get the key when when you get the network address associated with the name, and the key/name pairing needs to be blockchain secured, so you don't have one thousand certificate authorities each with the authority to mount a man in the middle attack.

The TCPng handshake needs to be a four phase handshake.
Client->Server:  Give me a connection, here are my parameters, here is my session key.

Server->Client:  Here is a proof of work request, my parameters, and a keyed hash of your and my parameters.  Ask again with proof of work, the same parameters, and the keyed hash.

Server then throws away the request, allocating no memory.

Client->Server:  OK, here I am again, with all that stuff you asked for.

Server checks the keyed hash to ensure that this is a real client reply to a real and recent server reply.  Then it checks the proof of work.

If the proof of work passes, Server allocates memory, generates and stores a session key, and stores connection parameters, the client and server session keys among them.

Server->Client:  OK, here is my session key, authenticated but not signed by my permanent key, and stuff, now you can start sending actual data.

Thus we can integrate TCP handshake and encryption hand shake and the innumerable DDOS protection handshakes  "Cloudfare is checking your browser, oops, your browser did not pass, here is a captcha" at the cost of one single additional trip, half a round trip.

Instead of the person establishing the connection fuming while round trip after round trip goes through, we get all that stuff at the cost of one additional half round trip.

To authenticate but not sign a session key, the connection symmetric encryption key has to depend on a shared secret established by the client session key and server session key, and also on the client session key and the (server session plus permanent key)

If the server session secret key is _server_, the server durable key is $server_identifier$, the client session key is $client$, and the corresponding public keys are $Server$, $Server_Identifier$, and $Client$, then the shared secret used for symmetric encryption depends on the following private secrets:

$client * Server$ and $client * (Server + Server_Identifier)$

Which are equal to:

$Client * server$ and $Client * (server + server_Identifier)$

The operation of deriving a third elliptic point from two elliptic points is represented as addition, and the public elliptic points are distinguished from their corresponding secret scalars by capitalization.

This procedure gives perfect forward secrecy (since the session keys only live in volatile memory and are erased when a session ends) and deniable authentication.  The client can prove to himself that a message came from the party that knows the durable secret key $server_identifier$, but cannot prove it to anyone else.



More information about the cryptography mailing list