Network Encryption - history and patents

First, a warning on Prior Art

Greg Aharonian warns us about submitting prior art to companies in a process which lets the companies and the Patent Office collaborate alone in a back room to review it, without letting opponents of the patent claims have their say.

Patents on network encryption

Uunet Technologies has two patents, '708 and '782, whose claims may cover some or all IP Security implementations. This has resulted in a "prior art" search among users, in the hope that the patents may be invalid. Rick Adams, the inventor and chairman of Uunet, says that if we can show actual prior art, they'll drop the claim.

A team from U. of Pennsylvania also obtained patent '623 on network encryption. However, their patent's claims are restricted to use in ATM networks, in which packets are broken up into cells. The patent filing was based on this paper: Jonathan M. Smith, C. Brendan S. Traw, and David J. Farber, "Cryptographic Support for a Gigabit Network," in Proceedings, INET '92, Kobe, JAPAN (June 15-18, 1992), pp. 229-237. (Inaugural Conference of the Internet Society),

The Sun SKIP team has also obtained patent '646 on network encryption. Here are the drawing pages from the patent as well: 2, 3, 4, 5, 6, 7, 8. If someone would write a brief summary of this patent, I would insert it here; send it to Sun's legal department has stated that if any prior art turns up which is "more relevant than the art that was before the Patent Office" they will bring it before the Patent Office to reconsider the patent's claims. (Both the patents their statement refers to are accessible on this page, in the following paragraphs.)

The Sun SKIP team has dedicated two previous patent applications (one of which resulted in issued patent '842) to the public:

Sun Microsystems, Inc., in the interest of promoting an open-systems,
standardized approach to key management for use on the Internet, is
taking the step of dedicating important intellectual property rights in
this area to the public.

Sun has submitted a proposed specification to the IETF entitled "Simple
Key Management Scheme for Internet Protocols (SKIP)".  On June 10 1994,
Sun filed two patent applications with the United States Patent Office
relating to SKIP, entitled "Method and Apparatus for a Key Management
Scheme for Internet Protocols", Serial No. 08/258,272; and "Method and
Apparatus for Key Management Scheme for Use with Internet Protocols at
Site Firewalls", Serial No. 08/258,344.  Sun wishes to dedicate its
rights under these two applications to the public, and to that end
hereby licenses all persons and companies to practice the SKIP
procedures claimed in these patent applications (and in the patents
resulting from the applications, when and if they issue).  This license
is immediately effective, and requires no fee.
IBM has a patent that cover some techniques for key refreshment (more precisely for two-party authentication protocols). IBM has granted a free license for use of this patent (US Patent 5,148,479) in connection to IKMP. For the exact "grant of rights" text see RFC 1822. Therefore, there is no reason to avoid these techniques; in particular, Oakley incorporates them already.

BTW [says Hugo Krawczyk,], this [IBM] patent (filed 3/91 issued 9/92) pre-dates any work in the IPSEC WG. None of the new work that we did in relation to this WG activity (e.g., MKMP, SKEME, HMAC) and which is now incorporated into current WG drafts (Oakley, AH, etc) has been patented by us.

DEC has a '961 patent on a network encryption system. It is focused on multilevel-secure systems, but some of its claims might apply to ordinary systems.

Netscape has a '390 patent on its Secure Sockets Layer encryption, which is very similar to IP Security except that it's done on a socket-by-socket rather than a packet-by-packet basis. Many people believe it's invalid due to prior art. The patent includes a full source-code listing of their SSL implementation, though the patent-search service I use didn't provide it as text. You can get crummy fax images of the source code from the IBM patent server.

History of network encryption

Here's a brief and incomplete summary derived from the IPSEC@TIS.COM mailing list in June 1996 and beyond. Here's more information about IPSEC (Internet Protocol Security), including the mailing list archives.

Phil Karn,

All the basic concepts of IP Security (especially including what we now call "tunnel mode") have been widely and publicly known since at least the original "lunch BOF" that I called at the San Diego IETF meeting way back in 1992.

Paul Lambert,

Approching for network layer encryption have been openly published before the work in the IETF.

The research and development of "Network Security" started in the late 70's at BBN with the development of the "IPLI". Classified research and development continued in this area on the Blacker (Unisys) and Caneware (Motorola) programs in the early 80's. The NSA sponsored Secure Data Network System (SDNS) project brought together a variety of vendors that created the early SP3, KMP and MSP specifications. SP3 provided network layer security services that included a tunneling mode. SP3 is very similar to the IPsec working group ESP specification. The Key Management Protocol (KMP) is similar to the ISAKMP specification in concept, but used ASN.1 for specifying the protocol formats. Much of the SDNS work was openly published starting in about 1988. The Motorola Network Encryption System (NES) is an SDNS device and was designed in the mid to late 80's.

The SDNS specification for SP3 was submitted to the ANSI and ISO standards committees and mutated into the Network Layer Security Protocol (NLSP). NLSP included a network layer key establishment protocol that served as a starting point for some of the current IPsec key management proposals.

An important early paper on network security was written by Dave Golber (Unisys at the time) on the "Dual versus Single Catenet Security Model" (about 1983). There are a variety of SP3 security papers written in 1988 and 1989.

So, there is a lot of prior art for network encryption. Most of the major wrinkles in the technology were worked out in the late 80's by projects sponsored by the NSA and openly published to help create "good" security standards.

Howard Weiss,

Actually, the PLI (Private Line Interface) was developed by BBN in the early '70s. The IPLI was to be its "modern" successor. It consisted of a classified-side (red) processor, a KG-30 encryption box, and an unclassified-side (black) processor. It was evaluated and certified by NSA around late-1975 or early-1976. Its function was to allow classified traffic to flow, encrypted, over the ARPAnet. This meant, at the time, that ARPAnet NCP headers remained in the clear while the data payload was encrypted. COINS (Consolidated On-line Intelligence Network) used the PLI to connect a distant node via the ARPAnet in order to save the line charges for the then, very expensive 50KB lines.

Steve Kent,

As one who participated somewhat more directly in the history of this, let me refine some of Paul's comments. The first packet encryptor was the PLI (not IPLI) developed in the early 70s by BBN under DARPA funding. It was approved by NSA for limited deployment on the ARPANET, to protect classified data being sent by DoD folks, starting in 1975 (a somewhat more sophisticated version was approved for use in 1976). Due to the restrictions imposed by use of government COMSEC equipment (KG-34), this was a manually keyed system.

In the 1975-1980 timeframe, BBN and the Collins Radio division or Rockwell developed and did limited deployment of the BCR, also under DARPA funding, as an experimental network encryption device. The BCR worked in the TCP/IP protocol environment, used the first NBS-certified DES chips, and had automated, KDC-based key management and access control (the same model later adopted by Kerberos and Blacker). The BCR underwent substabtial performance testing in 1980-81, before being retired. Later, DES-based network security devices were design and some were built as prototypes for DARPA in the early 80s, experimentin with higher speed network connections (Ethernet) and newer versions of protocols (IPv4 vs. IPv3).

The first Blacker program also began in the late 70's, funded by NSA with work done by SDC (software) and Burroughs (hardware). It too made use of centralized key management and access control. The followon program, designed to produce a product (vs. a proof-of-concept demo) was awarded to Unisys (merged SDC and Burroughs) in the early 80s, but it did not produce fielded devices until the late 80s. The fielded Blacker was revolutionary in its use of a single processor design with the (custom) crypto as a peripheral on the internal bus. It was designed to be a very high assurance (A1) system.

In the early-80s, BBN developed the IPLI, a successor to the PLI, updated to use TCP/IP, newer COMSEC technology (KG-84), but still manually keyed. The IPLI was a backup program, funded by DARPA and DCA, in case the more ambitious (multi-level secure) Blacker program was delayed (which it was) and caused programmatic problems for the newly inaugrated Defense Data Network (DDN). IPLIs also were deisgned for a tactical environment, for use with DARPA low cost packet radios. A small number of IPLIs were delivered in the mid-80s, but never saw real deployment.

All of the devices described above embody the essential network security designs that later were elaborated and improved upon in the SDNS program. However, none of them supported selective encryption on a per-packet basis, i.e., they all assumed that every packet emitted by a host or router on the "red" side of the device was to be encrypted.

The CANEWARE program evolved from the initial, pre-production Blacker work in the late 70s, when one of the projects was a multiplexed link encryptor. Motorola was the contrtactor and the Air Force was the primary client. The client decided that muxed link crypto was not the wave of the future and the program gradually evolved into a network encryption project, called ENSNARE, by the early 80s. ENSNARE was a traditional approach to network crypto, completely analogous to the BCR, but using high grade COMSEC chips designed explicitly for this purpose. ENSNARE begat CANEWARE in the mid-80s, and for a while CANEWARE became the preferred backup for the long-awaited BLACKER product. CANEWARE diverged from the other programs by adopting the FIREFLY key management technology that became a centerpiece of the SDNS program and later network security efforts. As CANEWARE continued, it adopted the SDNS protocols for IP layer security and key management. During the late-80s, the CANEWARE interface spec began to include a capability for selective encryption, i.e., traffic to selected host addresses need not be encrypted. To the best of my knowledge, this was the first high grade network crypto device to include such a capability. However, the first widely published paper on CANEWARE (which appears in the proceedings of the 10th National Computer Security Conference, 9/87), does not mention this facility.

The SDNS program (1986-91) developed protocols for layers 3 & 4 and for e-mail secruity and realtime key management. It included the notion that selective encryption could be employed (e.g., on an address-pair basis). I would check the SP3 specs sent to NIST in the late 80s for reference to this particular facility, since that seems to be the critical point.

In the late-80s, IEEE started the SILS program, to develop security protocols for LANs. It was oriented toward commercial (not just government) clients and thus had a model that allowed for selective encryption (and/or integrity protection) of packets. In the proceedings of the 12th National Computer Security Conference, 10/89, there is an overview paper on SILS and that may make mention of what seems to be the relevent feature. Russ Housley was the co-chair of this committe for some time, so he may have access to better/more citations that would point to this facility.

However, I did find what appears to be a relevent citation in looking through the 13th National Computer Security Conference proceedings (10/89). In a paper entitled "Low Cost Outboard Cryptographic Support for SILS and SP4" (B.J. Herbison, pages 286-295), there is explicit mention of a selective encryption facility in the device designed by DEC (and later built by them!). On page 288 the paper notes "The device recognizes several frame formats (both SILS and SP4) in frames passing through the device and encrypts or decrypts parts of the frames. if a frame doesn't contain a recognized format, then the frame is passed through unmodfied." In this design, software in the workstation or router or bridge decides what will or will not be encrypted and encapsulates it as appropriate. Then the simple crypto module does the necessary operations as directed by the encapsulation protocol. Thus, the combination of the software executing on the attached device plus this simple, inline crypto module, performs selective encryption/decryption of packets (viewed as MAC layer frames by this device).

Perry Metzger,

For prior art, see
   [VK83]  V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
           Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

Steven Bellovin,

A paper of mine might be relevant:
	%A S.M. Bellovin
	%T Pseudo-Network Drivers and Virtual Networks
	%P 229-244
	%B USENIX Conference Proceedings
	%D January 22-26, 1990
	%C Washington, D.C.
	%W AT&T Bell Laboratories
It's available as The part of interest is the discussion of the ``Greyer'' encryption system (which I never actually built, though at the time I'd intended to). The paper speaks of using the routing table (i.e., the destination address) to send packets for particular destinations to what we'd now call a tunnel driver; the packets would then be encrypted and reinjected.

My design was very consciously modeled on both BLACKER and SP3, and both designs are cited in the bibliography.

Something else worth checking -- in the late '80s, DEC was selling a bump-in-the-cord Ethernet encryptor --- called the DESNC, if I recall correctly. It was completely transparent to the hosts involved, and did its encryption based on the addresses in the Ethernet header.

Steve Kent,

Yes, I thought of the DESNC after I wrote my message. There is a paper on it in the 12th NCSC proceedings, but I am missing that year. I agree that it almost certainly provided for selective bypass on a host address (in this case a MAC layer address) basis. It relied on a KDC, which probably incorporated the access control database as well.

Joe Tardo,

The DESNC was ethernet only. The 'wart in the line' encryptor used a chip that did both ISO TLSP and IPv4 transport mode encryption. Both were intended to be 'transparent', but the chip mainly did streaming crypto operations, and worked in conjunction with host drivers.

Oh, by the way, DEC obtained a bunch of patents too. I don't remember all the numbers or claims or if any apply here, hopefully not, but, then, I'm no patent lawyer.

Paul Lambert,

One of these patents covered sending an encrypted session key in the header that was encrypted by a key know only to the recipient. This provides some interesting optimizations for hardware implementations. This function was forced into the IEEE 802.10 Standard for Interoperable Lan Standard (SILS) as an optional user or "management defined field". It was inserted ostensibly for labeling to support filtering at bridges, but in reality no other vendor supported this feature. There is now no documentation of the DEC usage of this field in the SILS standard, but the field still is documented in the standard (last I checked..). This is an interesting example of embedding patented technologies as options into a standard.

John Linn,

The proceedings of the 10th National Computer Security Conference (September 1987) included a set of papers about the SDNS program. I wrote one of them, "SDNS Products in the Type II Environment" (the phrase "Type II" referring in this parlance to anticipated usage for protection of commercial and Government unclassified sensitive information). On page 163 of the proceedings, this paper stated, "... As a specific example, it will be common for SDNS-secured Type II hosts to communicate not only with other SDNS-secured hosts, but also with unsecured hosts. This implies that Type II SDNS components must accomodate selective application of encryption, either on an address-driven basis or on request from an associated host." Although this paper's level was discussion of issues and requirements, not detailed design or implementation, I believe this validates the concept's visibility in at least one piece of published literature as of 1987.

Mark Vondemkamp,

Xerox started selling the Xerox Encryption Unit around 1990. The XEU was a layer 2 (Ethernet/802.3) network encryption device.

Wang started selling the Trusted Interface Unit around 1990. The TIU was a layer 2 (Ethernet/802.3) and layer 3 (IP) network encryption device.

These products were based on technology developed by Ultron Labs which started around 1985 by Ultron Labs.

Semaphore Communications Corp. started selling the Network Security System for Ethernet Workgroups in 1992. The NSS for WGs is a layer 2 (Ethernet/802.3) and layer 3 (IP, XNS, IPX, DECnet IV, Appletalk) network encryption system. The development of S4's system started in 1989.

Stephen Kent,

The XEU and TIU are good examples of inline network crypto from the latter 80s, but they also did not provide the selective bypass feature mentioned as a critical feature in the patent. However, the Semaphore device certainly did (and still does) and that's an excellent example of existing technology that was widely demonstrated and its product literature certainly mentioned the selective bypass capability. (Semaphore was a sort of spinoff from Xerox, the folks who developed the XEU, as your mentioned.)

One also could mention the Motorola NES, an IP (or MAC) layer, high grade crypto product which was sold starting in the early 90s, but it too lacked selective bypass. The Motorola folks often viewed the Sempahore devices as commercial versions of the NES, and in many respects that is an accurate characterization.

Matt Blaze,

These are by no means the earliest prior art, but here they are for the record:

Ioannidis & Blaze, "Architecture and Implementation of Network-Layer Security under Unix." USENIX Security Conference, October 1993.

Ioannidis & Blaze, "The swIPe IP security protocol." Internet Draft. December 1993.

Steve Bellovin,

For reference, Ran Atkinson's original drafts for the IPv6 security stuff had been filed in early '94 -- unfortunately, I only have the date of draft-ietf-sipp-ap-04.txt handy, which was a fourth draft, but that was 15 August 1994.)

Ran Atkinson,

The SIPP whitepaper online at the URL below demonstrates not only that the SIPP security extensions (which became the IPsec security extensions) were online as Internet-Drafts by January 1994 and moreover that they were known to Sun employees as being online at that time.

It might be prudent for you to download the source for that file to your own web site lest it get accidentally deleted from in future.

I'm still searching for the original draft-ietf-sipp-sa-00.txt, draft-ietf-sip-esp-00.txt, and draft-ietf-sip-ap-00.txt which were put online as formal Internet-Drafts on 31 Jan 1994 and had been circulating on the SIP list well prior to that. Email announcements of those drafts to the main IETF list are still archived among the IETF main list archives for 1993 at

The ESP spec is directly derived from the US Government's SP-3 specification published by NIST as a Special Publication in the late 1980s (1988 perhaps). AH is derived from SP-3 and from SNMP Security. The ISO Network Layer Security Protocol (NLSP) is another SP-3 derivative that was published in draft form by July 1991. Initially, the IPsec working group had looked at NLSP as a possible basis for an IETF standard.

See also Steve Deering's paper "SIP: Simple Internet Protocol" in the May 1993 issue of IEEE Networks magazine. I believe it includes mention of ESP and AH (then called AP) in the article.

Additional relevant prior art is in the following article, located online at The date is particularly interesting to me.

Charles Dinkel, et. al., "Prototyping SP4: A Secure Data Network System (SDNS) Transport Protocol Interoperability Demonstration Project", NIST Information Report 90-4228, NIST, Gaithersburg, MD, 1990.

Steve Bellovin,

That's SP4, not SP3, and while there are similarities, it might be harder to convince an examiner on that one.

Hugo Krawczyk,

There is a patent by Novell (US 5349642) that claims keyed hash functions for message authentication. Such claim would cover (I am not a lawyer!) all hash based schemes that have ever been suggested in this WG, including HMA Fortunately, the filing date of that patent is Nov 3 1992, while Gene Tsudik's paper proposing such functions appeared in Infocom in May 1992. (This work is also part of Gene's UCLA's PhD dissertation of May 1991).

The one element that does not appear in Tsudik's work is truncation. However, truncating the output of MAC functions is an old and very well known practice in cryptography. For example,

[MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, 1982.

[ANSI] ANSI X9.9, ``American National Standard for Financial Institution Message Authentication (Wholesale),'' American Bankers Association, 1981. Revised 1986.

and therefore a hard to defend claim (I'm not a lawyer!!).

After consulting with Jeff Schiller and the WG chairs, it became clear to me that the existence of Novell's patent shouldn't be an obstacle to include a section on truncation in the HMAC rfc, and more significantly, to propose it for adoption for AH-HMAC-SHA.

Jim Stevens,

Network security, including encryption, was studied in the Defense Advanced Research Projects Agency (DARPA) Survivable Adaptive Networks (SURAN) program, an outgrowth of the older DARPA Packet Radio (PR) programs. One paper that examined general network susceptibilities and described solutions, including encryption and encryption locations within the network, is "SURAN Network Susceptibilities Study (U)," by Jim Stevens of Rockwell International, Collins Defense Communications, Report Number SRTN-39, November 1985. The actual study itself is classified and distribution is limited to U.S. Government agencies and their contractors. Copies of the report are available from the Defense Technical Information Center (DTIC). Note that this study report does NOT describe particular protocols or encryption algorithms; instead it tries to exhaustively list potential network susceptibilities and sketch out general solutions for each susceptibility.

Circa 1987-8, Casey and McDermott (and Steve Kent?) of BBN developed several SURAN security architecture approaches and developed detailed algorithms and designs that included various encryption techniques. Although the architecture was not implemented, the architecture design included techniques similar to those now in standard network encryption designs and products. I believe that some of their reports are available from DTIC.

Chris Newman, Chris.Newman@INNOSOFT.COM

Was SSH publicly released before Aug 25, 1995?

It seems that Netscape was just granted a US patent on the idea of the SSL protocol. From reading the abstract (at, there might be a chance the patent applies to SSH. If SSH was publicly released before the filing date, then it should be clear of the patent. Otherwise it might be wise to check with a patent lawyer...

Bradley Dunn,

SSH 1.0.0 appears to have been released on Jul 12, 1995. See

Tatu Ylonen,

Yes, SSH-1.0 was publicly released in July 1995. Early versions were freely circulated at Helsinki University of Technology even before that.

Simon Cooper,

I designed something similar to SSL in early 1994 at Rutgers University, NJ, USA. The rough documentation for the system has been publically available since that time at The announcement of what Rutgers had been working on was made to on Thu, 21 Jul 94 16:59:51 EDT. At that time Walt, Greg and I announced the www-security mailing list. An old (very out of date) archive of the list is available at I am attaching the list announcement message and the message describing the location of the RUSSL documentation.
From Thu Jul 21 17:00:10 1994
Flags: 000000000001
Received: from by (5.59/SMI4.0/RU1.5/3.08) 
        id AA19226; Thu, 21 Jul 94 17:00:10 EDT
Received: from by (5.59/SMI4.0/RU1.5/3.08) 
        id AA07899; Thu, 21 Jul 94 17:00:07 EDT
Received: by (5.59/SMI4.0/RU1.5/3.08) 
        id AA16801; Thu, 21 Jul 94 16:59:54 EDT
Date: Thu, 21 Jul 94 16:59:51 EDT
From: Walt Drummond 
Subject: WWW Security mailing list

Hi all:

        Internally, Rutgers has been discussing different methods of
providing secure WWW service.  We've decided to open this discussion
up to the rest of the WWW community, and have created yet another
mailing list.   This list will focus on how to secure HTTP and/or
HTTP-like protocols to provide:

        o Privacy
        o User Authentication
        o Service Certification
        o Document Checking (Digital Signatures)

        and anything that I've forgotten!

To subscribe, send mail with a body of: 

subscribe www-security


Messages should be sent to 
(big surprise, I know.. :)


Walt Drummond (
Network Services
Rutgers University Computing Services
 - Lost: One mind. Owner sad. Reward.
From Thu Jul 21 17:04:18 1994
Flags: 000000000001
Received: from by (5.59/SMI4.0/RU1.5/3.08) 
        id AA19419; Thu, 21 Jul 94 17:04:18 EDT
Received: from by (5.59/SMI4.0/RU1.5/3.08) 
        id AA08038; Thu, 21 Jul 94 17:04:17 EDT
Received: (from scooper@localhost) by ( id RAA03769; Thu, 21 Jul 1994 17:01:17 -0400
Date: Thu, 21 Jul 1994 17:01:17 -0400
From: Simon Cooper 
Message-Id: <>
Subject: Outline RUSSL document.

   The "really sketchy" version of the RUSSL document is now available via
WWW, the URL is

You can find the ITU (CCITT) series of documents in


The IETF documents referenced are in,


The exact locations of where these documents came from are stored in
.desc.{pag,dir} dir files if you need to refetch them. (I have tools in my
$BIN directory :- "dl" and "describe" that update and access these dbm


Ran Atkinson,

At least under US law (based on my past painful involvement with patent lawyers), open publication of the concept by someone other than the patent filer prior to the filing date is often sufficient to invalidate the patent. So it isn't clear that actual code release is necessary. One might theorise that SP4 (published by NIST/NBS in the late 1980s) is prior art for the [Netscape SSL] patent in question.

Mitch Nelson,,

You might want to add a cite to the paper by Fumey appearing in Eurocrypt '92 (I think). It describes a `Kryptobox', that connects between a computer and the network.

Also, I have witnessed documents, and prototypes of a device that I developed probably well before the UUNET device, and have continued to develop and try to commercialize since then. From the information appearing in the working group, it very much seems that their box is a lot like my box.

Send comments to or My home page
Last updated Fri Nov 7 16:55:31 PST 1997