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

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

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

On Thu, Sep 03, 2015 at 11:59:11AM +0000, Peter Gutmann wrote:
> One saving grace about RFC 2631 was that it was pretty much universally
> ignored for the reason that it was, well, a pretty stupid way to do things, so
> the number of affected implementations would be approximately zero.
>

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

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

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)

Prev by Date: Possible crypto backdoor in RFC-2631 Diffie-Hellman Key Agreement Method
Next by Date: [tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")
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