Re: What email encryption is actually in use?
-BEGIN PGP SIGNED MESSAGE-
If you signed your messages on a regular basis, it would let me know
whether or not you're the same Tim May, I've been reading since back
when toad.com was the only server for the list.
If you're key was signed by anyone I've dealt with, who I know will
actually check your id, it would increase my confidence that you
really are Tim May, and not just a net persona.
It doen't make one iota of difference, whether you choose to
distribute your key or not. Your ideas are usually thought
provoking,
and consistent enough to form a persona in the minds of the list
readers. Or at least, in mine.
I know you know (whether or not you agree) with the above. It just
struck me as humourous that you'd sign the post, with the comment
to the effect that there isn't much point in doing so, with a key
that isn't on the servers.
Do you see the PGP web of trust as completly useless?
As to who I am, well...
I'm a programmer, living in London, Ont. Canada.
I've been lurking, off and on, since 94 or so. I don't think I've
actually posted anything to the list since back in 96, when I
wrote a freeware program to simplify using PGP with dos based
offline mail readers (MPI.ZIP).
While I normally promote privacy issues, only with those I meet
face to face, I still consider myself a cypherpunk. I normally
only post to the list, when my point of view isn't being
expressed by any of the regular posters.
Regards, Dave Hodgins.
Tim May wrote:
On Sunday, November 3, 2002, at 06:14 PM, David W. Hodgins wrote:
-BEGIN PGP SIGNED MESSAGE-
The advantages really disappear, when the key used to sign the
message
isn't sent to the key servers {:.
Those who need to know, know.
You, I've never seen before. Even if you found my key at the
Liberal Institution of Technology, what would it mean?
Parts of the PGP model are ideologically brain-dead. I attribute
this to left-wing peacenik politics of some of the early folks.
- --Tim May
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com
iQEVAwUBPcXu94s+asmeZwNpAQFQuAf+LbwrdQV8CPAc/lw2AF5HPvKLGopHCj3i
tFR+drfFAYDDA6UHMPJOFxzDdhFYrRbhQ3c3cSkExSSoI7Mce389KPdGimWQZTJZ
rCYyvnXtG+S//ya8yCELXC3SSwwra0+laPpoSz6lseIU6YJUYFyMLnnXaH5gpxHi
O7TtK8kfPFQVVdbBuJC4mp9SjNO3DqIM29UbPSrf9KZ1w2zPXA4eov9GL9jjU808
CzT+wncCYaE1EU8cT3C+TFJyd8r8B1S6CLbjX9hC71kIt5bVUt1EHMHUx8u2YaXZ
i4o2kKQGePbJvIIiOuwngIUOuwnbgLlGO7+zhsL4y2UuXeJ1/W5NVQ==
=8BJt
-END PGP SIGNATURE-
Re: What email encryption is actually in use?
at Monday, November 04, 2002 2:28 AM, Tim May [EMAIL PROTECTED] was seen to say: Those who need to know, know. Which of course is a viable model, provided you are only using your key for private email to those who need to know if you are using it for signatures posted to a mailing list though, it just looks silly. You, I've never seen before. Even if you found my key at the Liberal Institution of Technology, what would it mean? it would at least give us a chance to check the integrity of your post (what a sig is for after all) and anyone faking your key on the servers would have to prevent you ever seeing one of your own posts (so that you can't check the signature yourself) Parts of the PGP model are ideologically brain-dead. I attribute this to left-wing peacenik politics of some of the early folks. The Web-of-Trust model is mildly broken - all you can really say about it is that it is better than the alternatives (X509 is not only badly broken, but badly broken for the purpose of hierachical control and/or profit) In the current case, one reason to sign important posts is to establish a pattern of ownership for posts, independent of real-world identity. If I know that posts a,b c sent from nym x are all signed, I will be reasonably confident that key y is owned by the normal poster of nym x. that I don't know who that is in meatspace is pretty irrelevant. Where both systems break down is when trying to assert that key y is tied to anything but an email address (or possibly a static IP). There is little to bind a key to anything or anyone in the real world, unless you meet in person, know each other reasonably well (if only via third parties that can identify you both) and exchange fingerprints. in fact, WoT is simply an attempt to automate this process offline, so that you can be introduced to someone by a third party without all three of you having to meet; you still have to make a value judgement based on how sure you are about the third party's reliability and how confident they seem about the identity of x - however in the real world, both of those are vague, hard-to-define values and in the WoT they are rigid (you have a choice of two levels of trust for an introducer, and no way to encode how much third parties should rely on your identification)
Re: What email encryption is actually in use?
On Saturday November 2 2002 11:09, Adam Shostack wrote: I'd be interested to hear how often email content is protected by any form of crypto, including IPsec, Starttls, ssh delivery, or PGP or SMIME. There's probably an interesting paper in going out and looking at this. I use GnuPG to the people I know that have it. Admittedly that number is rather low but I am working on raising it. My e-mail client will do SSL and TLS so most if not all of my messages are protected at least to and from the ISP's servers. I would like to use GnuPG (my OpenPGP application of choice) more often. Unfortunately the number of people that have it is too low to make this practical and providers like AOL making it very difficult to use encryption with their proprietary e-mail clients pushes the number even lower than it should be. Part of the problem is too many people not realizing that one sending e-mail in the clear means that one trusts their ISP's admins, the receiving ISP's admins, and anyone with root (or possibly even just physical access) on a network between them. All it takes is one untrustworthy person snooping on the wire and there goes your privacy. Granted, yes, it's a violation of laws like the ECPA (in the US) to do so, but when there are potentially dozens of people who could have divulged a message, how does one know who to prosecute? -- Shawn K. Quinn
RE: Intel's LaGrab
Tim wrote: Microsoft calls its technology Palladium. Intel dubs it LaGrande. I say we call it LaGrab. Has anybody on the list seen any official specs, datasheets, etc. for Intel's LaGrande feature set? Any documents that could be donated to Cryptome's collection? So far, all I have been able to locate are vague press releases, marketing blather, and wild-eyed promises of hack-proofing computers. TIA, --Lucky
RE: What email encryption is actually in use?
Tim May[SMTP:[EMAIL PROTECTED]] On Saturday, November 2, 2002, at 08:01 PM, Tyler Durden wrote: Prior to that, the encrypted email I've sent in the past year or so has almost always failed, because of version incompatibilities, While in Telecom I was auditing optical transport gear, and we adopted the practice of encrypting all of our audit reports to vendors. Of course, the chance of there being an eavesdropper (uh...other than NSA, that is) was a plank energy above zero, but it gave the vendors the imporession we really cared a lot about their intellectual property (if we determined a problem with their equipment, and if that info ever leaked, it could have a major impact on them). When I was at Intel we sent our designs for microprocessors to European branches and/or partners. One set of designs sent to MATRA/Harris, a partner in the 80C86, was stolen in transit. (The box of tapes arrived in Paris, but the tapes had been replaced by the suitable weight of bricks.) I suspect that there is a fair amount of encrypted mail flowing over the net which is not obvious to ISPs. It's internal mail of large corporations. Many corps maintain VPNs between their offices, with encryption handled at the firewall. A great deal of highly sensitive internal email flows over these links, with the encryption totally transparent to the end-users. Of course, this is just internal stuff. The external mail is as open as everyone's been saying. Peter Trei
RE: Katy, bar the door
Major Variola (ret)[SMTP:[EMAIL PROTECTED]] When that trucker kamakazi'd into the state capital in Sacramento last year, they decided to put Jersey barriers up. Hard to do that in the air (Blimps with nets?) The name for these is 'barrage balloons'. They were widely deployed during WW2 against dive bombers and ground-attack fighters. I suspect they are less useful today for this purpose, due to the increased distances of attack, but they might make life harder for cruise missiles and other UAVs. Plan to see them over Baghdad. Peter Trei
RE: Intel's LaGrab
On Sun, 3 Nov 2002, Lucky Green wrote: Tim wrote: Microsoft calls its technology Palladium. Intel dubs it LaGrande. I say we call it LaGrab. Has anybody on the list seen any official specs, datasheets, etc. for Intel's LaGrande feature set? Any documents that could be donated to Cryptome's collection? So far, all I have been able to locate are vague press releases, marketing blather, and wild-eyed promises of hack-proofing computers. I didn't think any of it was near finalized yet. Even the comments here from people working close to it indicate it isn't finished. I suggest LaGrande Screw. Once in place, it will be pretty easy for Microsoft to screw everyone who owns a Paladium machine! Patience, persistence, truth, Dr. mike
Re: What email encryption is actually in use?
at Monday, November 04, 2002 3:13 PM, Tyler Durden This is an interesting issue...how much information can be gleaned from encrypted payloads? Usually, the VPN is an encrypted tunnel from a specified IP (individual pc or lan) to another specified IP (the outer marker of the lan, usually the firewall/vpn combo box but of course that function can be split if needs be) sniffers can usually catch at least some of the initial login - normally a host name or user name is passed unencrypted as part of the setup - but any actual mail traffic will be indistinguishable from any other traffic; it is encapsulation of IP packets in an outer encrypted wrapper. similar statements can usually be made for Zeb, SSH and other similar tunnels - each encapsulates a low level (almost raw in the case of strict tunnels like zeb or ssh) packet passing tunnel in a crypto skin.
RE: Sending bricks through the mail
At 11:17 PM 11/3/02 +0100, Thoenen, Peter Mr. EPS wrote: Tried emailing direct but bounced so apologize to the list for the OT content :) You don't happen to have the url do you? Think it would make an amusing read. Sorry, no. BTW, my nym is for humor value, and spam-avoidance, not replies.
Blacknet hits the trade press
EWeek 21 Oct 2002 p 58, High-tech products invite tech crimes P. Coffee Writing about a consultant who tried to sell a client's software, and got busted: Next time, a code theif may use a BlackNet brokerage (as envisioned in the widely circulated essay by Timothy May) to avoid such traps. [He is commenting on whereas stolen chips are valuable to many, stolen software is valuable only to a few...]
RE: What email encryption is actually in use?
At 10:13 AM 11/4/02 -0500, Tyler Durden wrote: This is an interesting issue...how much information can be gleaned from encrypted payloads? Traffic analysis (who, how frequently, temporal patterns) Size of payload Is it possible for a switch or whatever that has visibility up to layers 4/5/6 to determine (at least) what type of file is being sent? Yes. Modern network equiptment can examine all the way up to layer 7. Can tell that you're sending an .mp3 and will cut your QoS, if that's the policy. Can it determine at what layer encryption was performed? Various packet classification hardware companies [1] make chips to find fields in headers. (The classification chips pass this info to the NPU) IPsec, SSL are trivial. App-level crypto is easy if the crypto has signatures, like -BEGIN PGP MESSAGE-. Steganography + encryption, however, is pretty tough. The S/N ratio can become useless due to false alarms. The Feds probably have an enormous collection of intercepted arab baby pictures... [1] Here's a blurb from http://solidum.com/products/index.cfm Based on programmable state machine technology and a powerful, openly-distributed pattern description language, our scalable, forward-compatible, and field-upgradable classification processors can be configured to closely inspect packets for vital information up to and including Layer 7. The information collected can then be used to make intelligent routing and switching decisions for service, application, and QoS requirements. This improves the speed, power and efficiency of next generation network processing architectures, facilitates the delivery of content-based services and enables true QoS for differentiated services. --- CALEA: What did you think layer 7 awareness meant?
RE: What email encryption is actually in use?
Most the ones I've seen are IPSEC over IPv4. You might be able to glean some info from packet size, timing, and ordering, but not much. IPSEC takes a plaintext IP packet and treats the whole thing as a data block to be encrypted. SO this would indicate that IPSEC creates a sort of blockage from seeing up to Layers 4/5/6. Now when you say it takes the IP packet, is this just the datagram or is it also he procotol bytes? (I'm assuming the layer-2 information remains intact.) If the protocol bytes are unencrypted, then there's a LOT that can probably be determined about any IP session. If the protocol bytes are encrypted, then this will ot be a very flexible session, no? (More of a secure pipe I guess.) And then, does IPSEC include specification for MPLS? I would assume that the MPLS header information is not encrypted, simply because the headers have no global significance... From: Trei, Peter [EMAIL PROTECTED] To: [EMAIL PROTECTED], 'Tyler Durden' [EMAIL PROTECTED] Subject: RE: What email encryption is actually in use? Date: Mon, 4 Nov 2002 11:00:56 -0500 -- From: Tyler Durden[SMTP:[EMAIL PROTECTED]] Sent: Monday, November 04, 2002 10:13 AM To: [EMAIL PROTECTED] Subject: RE: What email encryption is actually in use? The ever-though-provoking Peter Trei wrote... A great deal of highly sensitive internal email flows over these links, with the encryption totally transparent to the end-users. This is an interesting issue...how much information can be gleaned from encrypted payloads? Is it possible for a switch or whatever that has visibility up to layers 4/5/6 to determine (at least) what type of file is being sent? Can it determine at what layer encryption was performed? (These may be obvious to many of you, but I can only claim expertise in layers 0/1, and pieces of 2. Ok, I have a working knowledge of 3.) It may be possible for hardware that examines large numbers of communiques to pre-determine that much is of no interest. Most the ones I've seen are IPSEC over IPv4. You might be able to glean some info from packet size, timing, and ordering, but not much. IPSEC takes a plaintext IP packet and treats the whole thing as a data block to be encrypted. _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
RE: What email encryption is actually in use?
Tyler Durden[SMTP:[EMAIL PROTECTED]] writes: Most the ones I've seen are IPSEC over IPv4. You might be able to glean some info from packet size, timing, and ordering, but not much. IPSEC takes a plaintext IP packet and treats the whole thing as a data block to be encrypted. SO this would indicate that IPSEC creates a sort of blockage from seeing up to Layers 4/5/6. Now when you say it takes the IP packet, is this just the datagram or is it also he procotol bytes? (I'm assuming the layer-2 information remains intact.) If the protocol bytes are unencrypted, then there's a LOT that can probably be determined about any IP session. If the protocol bytes are encrypted, then this will ot be a very flexible session, no? (More of a secure pipe I guess.) And then, does IPSEC include specification for MPLS? I would assume that the MPLS header information is not encrypted, simply because the headers have no global significance... It's a pipe. The whole plaintext IP packet, from start to finish, including headers and checksum, gets treated as data, and encrypted. The encrypted packet is the data for a new packet, which goes from one firewall to another (and has only the firewall IP addresses exposed). The packets visible on the outside only tell Eve that firewall A sent firewall B an IPSEC packet of a certain size, with a particular Security Association. (ie, the protocol field says 'this is an IPSEC packet'). A single SA can be used for many, many, internal connections. Check the IPSEC RFCs for more info. Peter Trei
RE: What email encryption is actually in use?
Tyler Durden[SMTP:[EMAIL PROTECTED]] wrote But from your previous email, you indicated that the secure IPSEC tunnel is created by taking the packets, encrypting S/A, D/A, payload and protocol fields (ie, pretty much everything) and then dumping them into the payload of another packet, and setting the Protocol field of the parent-packet to IPSEC. All that is now visible are the firewall addresses. That's a lot, methinks! In other words, there's practically a bright red flag sticking up saying I'm encrypted! Look over here!...it's child's play (well, if you consider making an ASIC child's play!) to then look at the S/A and D/a to see if they are interesting. If they belong to the IP spaces of two large companies, for instance, then look elsewhere (though I hear rumors that the NSAs of the world are branching out into industrial eavesdropping for their parent companies, ehr, for their parent countries). If a secure VPN tunnel forms between al-Jazeera's firewall and, say, some ISP near Atlantic Avenue in Brooklyn (heavy Arab community), then all sorts of spyglasses could pop up. The title of this thread is What email encryption is actually in use?. I posted that a lot intra-company email often goes over encrypted VPNs between worksites, and that this should be considered in trying to figure out how much email is encrypted. After some back and forth to educate you on how IPSEC tunneling works, you now understand, but it turns out that that was not what you were interested in. VPNs no more raise a red flag than does any other form of encrypted communication without steganography. If your threat model includes end-point identification, then use alt.anonymous.messages. If traffic analysis is also a worry, use stego. VPNs are probably responsible for more encrypted traffic than anything else on the net, and meet corporate threat models very well. If your threat model is different, you may need a different solution. Peter Trei
Re: What email encryption is actually in use?
On Sun, Nov 03, 2002 at 11:23:36AM -0800, Tim May wrote: - -- treat text as text, to be sent via whichever mail program one uses, or whichever chatroom software (not that encrypted chat rooms are likely...but who knows?), or whichever news reader software http://www.invisible.net is sort of an encrypted chatroom. -- Windows, Icons, Mice and Pointers. A jedi craves not these things.
CARDIS '02 - 5th Smart Card Research and Advanced Application Conference
Dear colleague - I'd like to invite you to attend the 5th Smart Card Research and Advanced Application Conference, November 21-22 in San Jose, CA. http://www.usenix.org/events/cardis02/ CARDIS '02, the joint IFIP/USENIX International Conference on Smart Card Research and Advanced Applications, will bring together researchers and practitioners in the development and deployment of smart card systems and technologies. This two-day conference features: Keynote speaker Vincent Cordonnier, LIFL; 14 refereed papers; panel discussions; Work-In-Progress reports as well as ample opportunities to informally interact with fellow attendees and speakers. Unlike events devoted to commercial and application aspects of smart cards, the CARDIS conferences bring together researchers who are active in all aspects of the design, validation, and application of smart cards. The breadth of smart card research stimulates a synergy among disparate research communities, making CARDIS an ideal opportunity to explore and learn from the latest research advances. We hope you will join us in San Jose. On behalf of the program committee - Peter Honeyman, CITI, University of Michigan CARDIS '02 Program Chair -- Alex Walker Production Editor USENIX Association 2560 Ninth Street, Suite 215 Berkeley, CA 94710 510/528-8649 x33
RE: Sending bricks through the mail
I think this is what you're looking for: http://www.improb.com/airchives/paperair/volume6/v6i4/postal-6-4.html At 11:17 PM 11/3/02 +0100, Thoenen, Peter Mr. EPS wrote: Tried emailing direct but bounced so apologize to the list for the OT content :) You don't happen to have the url do you? Think it would make an amusing read.
traffic analysis of VPN/secure tunnels (Re: What email encryption is actually in use?)
On Mon, Nov 04, 2002 at 12:58:55PM -0500, Trei, Peter wrote: Durden's question was whether a snooper on an IPSEC VPN can tell (for example) an encrypted email packet from an encrypted HTTP request. The answer is no. All Eve can tell is the FW1 sent FW2 a packet of a certain size. The protocol of the encapsulated IP packet, it's true source behind FW1, it's true destination behind FW2, and the true destination port are all hidden. An external obseverer being able to tell the time of exchange or percentage of traffic which is email vs http through a VPN probably isn't a big deal to most people. But if someone did care, it may be that you could have some probabilistic indication of whether the traffic is email or http (or other distinctions) based on the size of the packets, the timing that kind of thing. As there are different internal originating-points (mail hub, vs desktop/desktop+proxy cache), probably aspects of the hardware, TCP stack and application performance and behavior would leave some still recognizable performance and IP packet size signature. A more direct traffic-analysis type of risk is interactive session protocols like telnet, perhaps some chat programs where the characters are sent as they are typed. In this scenario it may be that an attacker could reconstruct the plaintext by analysing typing characteristics. (There was a paper about this risk for interactive sessions over SSH published a while back -- don't have the reference handy, probably google could find it). Another related type of risk is that SSL does not necessarily obsecure the page requested as the request and/or response may have unique, predictable and publicly measurable size uniquely identifying the document requested. Adam -- http://www.cypherspace.org/adam/
