Al Qaeda crypto reportedly fails the test

james hughes hughejp at
Sun Aug 15 02:00:31 EDT 2004

In message <41153C1F.9020808 at>, John Denker writes:
> Here's a challenge directly relevant to this group:  Can you
> design a comsec system so that pressure against a code clerk
> will not do unbounded damage?  What about pressure against a
> comsec system designer?

If I understand your question correctly, in 1994 a VPN product was 
fielded that had this capability. It did not have any capability for 
static group or tunnel keys. It was only RSA/DH using DH for the tunnel 
key and RSA only for authentication. The device had "perfect forward 
secrecy" because the use of RSA disclosed nothing about the tunnel 
keys, and complete RSA secret disclosure would only divulge that the 
D-H was authentic. The DH private keys were use once random and the 
public parameters, well, public. The user could set the tunnel lifetime 
short or long, their choice.

In this case, the "code clerk" had no direct access to the key material 
and could not set static keys even if they tried. The box was not 
tamper resistant, but it was not easy to remove the keys even with 
physical access.

The device did not have a "group password" (current Cisco IPSEC 
vulnerability) and used an invitation scheme to bring new nodes in. 
Link to Cisco notice is here

Once the system was fielded, pressure on the systems designer could not 
change this.

In essence, there was no code clerk. One can argue that the network 
administrator is the code clerk, but that person could still wire 
around the VPN device or attach a completely separate backdoor to to 
cause, as you say, "unbounded damage" in a way that does not compromise 
the comsec system.

This was one of the original proposals for IPSEC, but was not selected 
(but that is another story). Subsequent generations of this device are 
still being built and sold from

So, as long as I have understood your question, such systems have 
existed for some time.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list