[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method

To: Georgi Guninski <[email protected]>
Subject: Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
From: [email protected] (Peter Gutmann)
Date: Thu, 3 Sep 2015 15:38:23 +0000
Cc: "[email protected]" <[email protected]>
In-reply-to: <[email protected]$>
References: <[email protected]$> <9A043F3CF02CD34C8E74AC1594475C73F4AF0463@uxcn10-5.UoA.auckland.ac.nz>, <[email protected]$>

Georgi Guninski <[email protected]> writes:

>Even if "affected implementations would be approximately zero",
>can we count this as "crypto backdoored RFC" as per OP?

Oh sure, it's definitely broken.  OTOH I'm not sure if it's a deliberate
backdoor, the whole thing is such a bad design to begin with that something
like this is really just the icing on the cake.

It may be worth submitting an erratum to the RFC that mentions the problem,
just in case anyone is actually crazy enough to want to implement this in the
future.

Peter.

References:
- Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
  - From: [email protected] (Georgi Guninski)
- Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
  - From: [email protected] (Peter Gutmann)
- Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
  - From: [email protected] (Georgi Guninski)

Prev by Date: [tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")
Next by Date: Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
Previous by thread: Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
Next by thread: Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
Index(es):
- Date
- Thread