December 2003 - cypherpunks-legacy

Security (Encryption) Corps
by Matthew J Miszewski 17 Dec '03

17 Dec '03

To interupt the Monster in the name of Cypherpatriot Activity... I plan on starting up a security and consulting firm over the next few months. A great deal of what we will address are practical applications of crypto technology. Due to the fact that pre-LD experience with this list has showed a great deal of impressive peole or net.entities out there, I would like those interested in getting involved with an upstart (and yet comprehensive) corporation to contact me. The corporation will deal with all aspects of information security including telco product security, data integrity, data security, communication security, and general computer consultations. If you are interested, or have any ideas you think are ready for commercialization, let me know. Cypherpunks Start Corporations! (No longer merely write code). --Matt ______________________________________________________________________________ In defense of liberty, encrypt for all purposes, civil and professional. In defense of privacy, encrypt all correspondence, personal and professional. In defense of sanity, do not encrypt your dry cleaning invoice! ++++++++--------mjmiski(a)macc.wisc.edu (c)1993

1 0

PGP Question
by jaeck＠alc.com 17 Dec '03

17 Dec '03

Would someone please explain exactly what it is that using PGP to sign an electronic post is supposed to be good for? Given that I will understand that, how can I decipher a PGP block, and how can I create one? Thanks.

1 0

More Digressions Into Folklore
by anonymous＠extropia.wimsey.com 17 Dec '03

17 Dec '03

* Reply to msg originally in CYPHERPUNKS > From: arthurc(a)crl.com (Arthur Chandler) > Date: Sat, 4 Dec 1993 10:17:08 -0800 (PST) > Cc: cypherpunks(a)toad.com > I've had occasion to recall this quote several times as I've read > some of the menacing and/or obscure posts here: > "They muddy their waters that they may seem deep." Hm. Reminds me of the Mexican proverb: "Don't muddy the water; in the end you'll have to drink it." Perhaps this is even more apropos. Dark days, brothers, dark days...

1 0

swIPe Internet Draft
by jim＠Tadpole.COM 17 Dec '03

17 Dec '03

1 0

VOTE: Proposition desist: no
by fnerd＠smds.com 17 Dec '03

17 Dec '03

Shut Detweiler out of the cpunx list? no. I have no problem skipping his posts; presently I'm not worried about the bandwidth through the modem into /dev/null. He posts interesting things once in a while (most recently, that piece by Kapor about libertarians vs. "decentralists.") I wouldn't mind the creation of a special "Detweiler free" filtered version of the list, as long as it was just a postprocessor on the true list. -fnerd quote me -----BEGIN PGP SIGNATURE----- Version: 2.3a aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvtoxiQCVAgUBLMs3K ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2toust1Q5A3/n54PBKrUDN9tHVz 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hanC0R3seYNhUYhoJViCcCG sRjLQs4iVVM= =9wqs -----END PGP SIGNATURE-----

2 1

Majordomo results (fwd)
by bart＠netcom.com 17 Dec '03

17 Dec '03

Forwarded message:

1 0

swIPe Internet Draft, resent
by John Ioannidis 17 Dec '03

17 Dec '03

The swIPe IP Security Protocol John Ioannidis INTERNET DRAFT (Columbia University) Expires June 3, 1994 Matt Blaze <draft-ipsec-swipe-01.txt> (AT&T Bell Labs) December 3rd, 1993 The swIPe IP Security Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This document describes swIPe, a network-layer security protocol for the IP protocol suite. swIPe provides confidentiality, integrity, and authentication of network traffic, and can be used to provide both end-to-end and intermediate-hop security. swIPe is concerned only with security mechanisms; policy and key management are handled outside the protocol. 1. Introduction Security of network resources has been viewed traditionally as a trade-off between security and convenience. The lack of a network-layer security protocol suitable for use in large, administratively heterogeneous internetworks, has given rise to ad hoc security efforts, such as mailbridges, filtering routers, firewalls, application-level gateways, etc. The fundamental problem with these efforts is that, in enforcing security, they cripple the connectivity that makes internetworking attractive in the first place. Ioannidis & Blaze [Page 1] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 In order that the Internet continue to grow in size and features, its users must be confident that it is safe to connect without hiding behind impenetrable draconian barriers. The existing internetworking protocols, including IP, are deficient in three areas: * Lack of source authentication. * Lack of data integrity. * Lack of data confidentiality. The lack of these features in the network requires relying on higher-layer protocol features (e.g., TCP port numbers), or lower-layer features (e.g., which network interface a packet arrived from) to perform security functions (such as access control). In most cases, `firewalls' simply create an impenetrable barrier, thus making it cumbersome, or even impossible, for users inside the firewall to take advantage of network services in the global Internet. Network security being critically important to the continued growth of the Internet, it is necessary to solve these problems while maintaining connectivity. Cryptographic protection of network traffic can solve all three problems. However, we still lack full understanding of the problems of heterogeneous security policies and of cryptographic key management in large scale networks. Therefore, it is important to separate policy considerations and key management from the actual mechanisms in any security protocol. swIPe is a network-layer security protocol that provides the mechanisms to solve the three problems listed above. It works by augmenting each packet with a cryptographically-strong authenticator and/or encrypting the data to be sent. swIPe is simple to define, implement and use in existing and future networks and operating systems. It provides all the necessary security mechanisms and is easy to interface to loosely coupled policy and key management facilities that are outside the swIPe protocol itself. In addition, is tied to any specialized underlying protocol features or cryptographic algorithms, and can therefore be readily adapted to new protocols and new crypto systems. Because swIPe operates at the network layer, it can be used to implement a variety of security configurations. It can operate at the same granularity level as the network and therefore can provide security between any entities identified at the network layer (e.g., host-to-host security, host-to-network, individual links, etc.). Depending on the capabilities of the host environment, finer Ioannidis & Blaze [Page 2] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 granularity is possible as well, such as security between individual processes running on different hosts. The precise security configuration of a network (which links, hosts, connections between processes in hosts, etc. are protected) depends on the policy configuration of each network entity. That is, a host may determine which outgoing packets are protected, a router may determine which packets to pass or reject, and so on. For example, a trusted internal network need not run swIPe at all, but may still securely connect to external networks by running swIPe on its routers. It is important to note that the existence of a security protocol is not sufficient; host and site security policies must be chosen judiciously, and often in combination with higher-level security mechanisms to yield the desired effects. As an example, providing a secure link between a workstation and its file server does not protect file data once they are on the server itself. Similarly, trusting the identity of a particular host is not the same as trusting the integrity of the data and services provided by that host. Although it was designed to be readily adaptable to any connectionless network protocol, swIPe as described in this document is specific to IP. 2. Protocol Description swIPe works by encapsulating each IP datagram to be secured inside a swIPe packet. A swIPe packet is an IP packet of protocol type IPPROTO_SWIPE (temporarily, protocol 94, or IPPROTO_IPIP, is being used). A swIPe packet starts with a header, which contains identifying data and authentication information; the header is followed by the original IP datagram, which in turn is followed by any padding required by the security processing. Depending on the negotiated policy, the sensitive part of the swIPe packet (the authentication information and the original IP datagram) may be encrypted. In this document, we refer to the original IP datagram as the `inner packet', and the entire swIPe datagram as the `outer' packet. The components of a swIPe packet are shown in the following diagram. +-----+-----------+-----+----------------------+---------+ |IPhdr| swIPe hdr |IPhdr| payload | padding | +-----+-----------+-----+----------------------+---------+ ^_______ inner packet _______^ ^__________________ outer (swIPe) packet ________________^ Ioannidis & Blaze [Page 3] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 The inner IP header and the payload are transferred intact with respect to the swIPe endpoints. That is, the Time To Live field, original source and destination addresses, and other such fields in the inner IP header are not modified. It may be desirable (in a future version of the protocol) to `compress' the inner IP header, that is, replace it with enough information to reconstruct it from the outer header. This `compression', however, must be invisible at the swIPe endpoints. The format of a swIPe packet is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 .- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s H | Packet type | Header length | Policy identifier | w e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I a | Packet sequence number | P d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e e / / r \ Authenticator (optional, variable length) \ `- / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ \ / Original (inner) packet / \ \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ Padding (optional) \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields in the swIPe header are: Packet type (8 bits) 0 Plain encapsulation; Header length should be 1 and the Policy identifier should be 1. 1 Packet is authenticated but not encrypted. 2 Packet is encrypted; the encryption algorithm may provide some authentication (e.g., DES CBC residue). 3 Packet is both authenticated and encrypted 4-15 Unused. Ioannidis & Blaze [Page 4] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 16-63 Control packet. Reserved, undefined by the protocol, interpreted by policy and key management engines. 64-255 Reserved; must never be used. Header length (8 bits) The length of the swIPe header in 32-bit words. The minimum value is 1. Policy Identifier (16 bits) A token, negotiated at key- or policy-setup time, used by the recipient of the packet to choose the proper policy. Similar to a SAID. Packet sequence number (32 bits) This field protects against replay attacks and may also be used for synchronization by a stream cipher. It is unique within the context of an endpoint pair (common source/destination address and Policy identifier). It is incremented by one with every packet sent, and initialized whenever the hosts re-negotiate keys and/or policies. The hosts MUST renegotiate crypto variables before the packet sequence number wraps around. A host MUST NOT accept duplicate packets; this may be achieved by only accepting packets which increment the sequence number, or maintaining a small window of acceptable packet numbers. Authentication data (variable length, multiple of 32 bits) An authenticator, computed over the entire swIPe packet (minus the outer IP header), but before any confidentiality processing is performed. When the authenticator is computed, the authentication data field is zeroed. Encapsulated packet (variable length) The actual packet being secured. Padding (variable length) Some security algorithms (such as DES) require padding to bring the length of the data to an integral multiple of the block size. The padding is added after the authentication data have been computed. A swIPe system consists of three conceptual entities; the protocol engine, the key management engine, and the policy engine. The swIPe protocol described in this document comprises the protocol engine. We describe the swIPe processing without specifying the precise semantics of either the policy or key management engines, since these Ioannidis & Blaze [Page 5] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 are not part of the protocol itself. It is useful, however, to consider the interaction between protocol and key management and policy in terms of a simple upcall interface: whenever the swIPe processing engine needs to determine which keys and what policy to use in processing a datagram, it calls the appropriate processing engine. Needless to say, an implementation may optimize the actual mechanisms or blur the boundaries between protocol processing and policy. The policy engine is responsible for determining the precise kind of processing required of outgoing datagrams, and acceptance policy for incoming datagrams. The key management engine establishes the cryptographic variables used by the protocol. Both the policy and the key management engines may also communicate with their respective peers on remote endpoints for negotiation of policy and keys, as required. Outgoing datagrams are processed by swIPe as follows: based on information from the inner packet itself (IP source and destination address, IP protocol, other transport-layer parameters), as well as information from local system control structures such as protocol control blocks, a decision is made whether to send the packet and, if so, whether to apply swIPe processing to it. If swIPe processing is required, the authentication and encryption algorithms, the keys to use, and the destination of the outer packet are determined by consulting the policy and key management engines. Once the parameters have been determined, the swIPe packet is constructed. The swIPe header is prepended to the (inner) IP datagram. The sequence number is copied into the packet and incremented. If authentication is to be performed, the authenticator field (of the appropriate length) is zeroed, and the authentication algorithm is applied to the authentication information part of the header (i.e., the swIPe header minus the first 32 bits) and the original IP datagram. The checksum resulting from the application of the authentication algorithm is copied into the authenticator field. If authentication is not performed, then the authenticator field is not present. Next, if encryption is (also) specified, the appropriate algorithm and crypto variable are selected and applied to the same parts of the datagram as the authentication. The algorithm may require padding, which is appended to the packet after encryption has been performed. The resulting datagram is then transmitted to its destination (which may not be the same as that of inner packet). Input processing proceeds in roughly the opposite fashion. swIPe datagrams that arrive are decrypted and authenticated based on information contained in their swIPe header. Namely, the source, destination, and Policy Identifier of the outher packet are examined and the crypto variables and algorithms used to decrypt, verify, and Ioannidis & Blaze [Page 6] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 reconstruct the original packet. The resulting datagrams, plus any non-swIPe datagrams that arrive directly are checked against the local policy configuration to determine whether they should be accepted or not. Accepted packets are processed in the ordinary manner (delivered to the corresponding higher-layer protocol if they were destined for the receiving host, or further routed if not). 3. Discussion The security provided by swIPe depends upon the strength of the underlying cryptographic algorithms, the security of secret key information, and the characteristics of the protocol itself. Since swIPe can be used with a wide range of crypto systems, we focus on the impact of the protocol features on the resulting security. Source authenticity of the inner packet is protected by including the entire inner packet (and hence its source and destination IP addresses) in the computation of the authenticator. The implicit assumption is that the authentication function is a cryptographically strong one-way authenticator (such as key-seeded MD5), and that only the legitimate hosts have access to the authentication key. Similarly, data integrity is protected by the same checksum mechanism; replays are thwarted by the presence of the sequence number field. An adversary not possessing the authentication key cannot generate the authenticator for fraudulent packets; furthermore, since only packets that increase the sequence number are accepted (or packets within the acceptable window), replay attacks are not feasible either. Data confidentiality is provided by encrypting the entire swIPe packet. Confidentiality is not limited to the actual data being transmitted in the inner packet, but also extends to the source and destination addreses, protocol characteristics (such as TCP port number), and so on. Note that since the addresses of the inner packet are not necessarily the same as those of the outer packet, it is not possible for an adversary to determine the actual endpoints of communication without resorting to global traffic analysis. There are many ways to configure systems running swIPe, and many types of security policies that can be implemented with it. For a discussion of applications of swIPe and its implementation under Unix, the reader is referred to "The Architecture and Implementation of Network-Layer Security Under Unix", by John Ioannidis and Matt Blaze, which appeared in the proceedings of the 4th USENIX Security Symposium, Santa Clara, CA, October 1993. Ioannidis & Blaze [Page 7] INTERNET-DRAFT The swIPe IP Security Protocol December 1993 Authors' Addresses John Ioannidis Computer Science Department Columbia University 500 W. 120th Street New York, NY 10027 ji(a)cs.columbia.edu +1.212.939.7000 Matt Blaze AT&T Bell Laboratories 101 Crawfords Corner Road Holmdel, New Jersey 07733 mab(a)research.att.com +1.908.949.8069

1 0

Pabo and Interception
by Black Unicorn 17 Dec '03

17 Dec '03

This from the state department, -> COLOMBIA 12/02/93 SC14249 MORE ON ESCOBAR DEATH MEDELLIN, ANTIOQUIA DEPARTMENT REUTERS REPORTED THAT POLICE AND TROOPS SHOT AND KILLED FUGITIVE DRUG LORD PABLO ESCOBAR ON THURSDAY AFTER A FURIOUS ROOFTOP SHOOT-OUT IN MEDELLIN'S LAS AMERICAS SUBURB. (ALSO SEE THE OTHER DECEMBER 2 REPORTS.) WITNESSES AT THE HOUSE WHERE ESCOBAR WAS KILLED SAID THEY HAD SEEN THE BEARDED FUGITIVE ATTEMPTING TO FLEE ACROSS THE ROOF BEFORE SECURITY FORCES OPENED FIRE. ESCOBAR'S BROTHER-IN-LAW CARLOS MARIO HENAO WAS ALSO KILLED IN THE SHOOT-OUT. ESCOBAR HAD BEEN ON THE RUN SINCE ESCAPING FROM JAIL IN JULY 1992, ALONG WITH NINE OF HIS ASSOCIATES. POLICE CAUGHT UP WITH HIM AFTER A 16-MONTH SEARCH BECAUSE OF A FATAL MISTAKE -- A TELEPHONE CALL TO HIS FAMILY ON WEDNESDAY, ESCOBAR'S 44TH BIRTHDAY. ELECTRONIC MONITORING EQUIPMENT ALLOWED POLICE TO PINPOINT THE LOCATION OF THE CALL AND MOUNT THE OPERATION IN SECRECY, SURROUNDING ESCOBAR'S HIDEOUT WITH SHARPSHOOTERS. WITHIN HOURS OF THE DRUG LORD'S DEATH, ESCOBAR'S 17-YEAR-OLD SON VOWED REVENGE AND HIS MOTHER PREDICTED THAT "HORRIBLE THINGS" WOULD HAPPEN, BUT THE YOUNGER ESCOBAR LATER SAID HE WAS REACTING OUT OF GRIEF AND WAS NOT ISSUING THREATS. <- I don't know where the babble about calling a radio station came from, but this caught my eye as it seems to be the "offical" state department word on the topic. -uni- (Dark)

1 0

Help me get off cypherwonks list
by Alan (Miburi-san) Wexelblat 17 Dec '03

17 Dec '03

I tried "unsubscribe cypherwonks Alan Wexelblat" and got back a barf message saying that I had to "unsubscribe <listname> <address>" so I tried "unsubscribe cypherwonks wex(a)media.mit.edu" and got back a barf message saying "No matches found for 'wex(a)media.mit.edu' Help! Is there a human being associated with this annoying piece of crap? I suppose I can just add a new formula to my .procmailrc, but I'd rather kill it at the source... --Alan Wexelblat, Reality Hacker, Author, and Cyberspace Bard Media Lab - Advanced Human Interface Group wex(a)media.mit.edu Voice: 617-258-9168 Page: 617-945-1842 an53607(a)anon.penet.fi Withdrawing in disgust is not the same as apathy.

2 1

Re: Digicash question
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

One problem with your proposal is that at *some* point you want to be able to get *real* cash for your digicash - at that point you've got to give the bank the password, but also an account to deposit the cash into (or equivalent), and at that point the bank can compare it with the original owner of the bill. You not only have to trust them to not rip off the money, you have to trust them to not give away the information, which may be tough if the government requires it. Another problem is that: Suppose Alice gives the password to Bob, who gives it to Carol, and then Alice spends the cash before Carol can get it - you don't know if Alice or Bob ripped you off. Alice could also try spending it before Bob deposits it, but that's an issue for any offline cash protocol, though this appears to give you less protection. Different denominations aren't much of a problem - you need something like that anyway. Having each separate coin have a separate number registered with the bank is somewhat more annoying than some of Chaum's schemes, where you could prove the coin had been signed by the bank but the bank didn't (and couldn't) track the coins. Another trusting-the-bank problem is what happens if the government comes to you and says "Alice is a drug dealer (mushrooms?) - give us the passwords for all her digicash, and if she's given them to anyone else, we can still forfeit them because the law lets us confiscate them after she's spent them, just like stolen goods." In Chaum's case, that's explicitly impossible. (In the cases that led to Swiss Banking Secrecy laws, the crime wasn't "drugs",it was "being Jewish".) Similarly, even if the bank as a whole is honest, there may be employees trying to embezzle the funds - tough to prevent in your approach. Bill Stewart

1 0