RE: Is PGP broken?
> A problem with including a public key with every plaintext message is that > it isn't very discreet - actually looks kind of ugly in some peoples's > email clients. You could use a separate PGP/MIME bodypart... > Come to think of it, there are some tricky issues with regards to crypto > on mailing lists, it might make sense to have a > X-crypto-originator [EMAIL PROTECTED] line in the headers to specify that the > crypto information contained in that piece of mail applies to the address > [EMAIL PROTECTED] - otherwise there's no clear way of unraveling all the > possible mixes of from, to, and reply-to headers which could possibly be > sent to a mailing list. The recipient would probably ignore the mail headers and use the userID(s) in the public key certificate included in the message. Ian :0)
Yahoo delivers "secure" email
Why don't they use SSL between sender and Yahoo?! http://news.cnet.com/news/0-1005-200-3901784.html?tag=st.ne.ron.lthd Yahoo delivers encrypted email By Paul Festa Staff Writer, CNET News.com November 28, 2000, 11:30 p.m. PT Yahoo has quietly introduced a way for people to send scrambled messages through its email service. As first reported in August, Yahoo is providing its email encryption option through a deal with Zixit, a Dallas-based email encryption firm. Yahoo will rout encrypted email through Zixit's SecureDelivery.com Web site . . . Yahoo's free encryption option handles outgoing email messages in a multistep procedure that the portal warns is not foolproof. "Please be aware that this is not an end-to-end secure service," reads an explanation of the service posted by Yahoo. "This option only avails your recipient of a certain level of security in accessing and reading the email message you are sending. Before your email message is encrypted by SecureDelivery.com it is still subject to the inherent limitations of a standard TCP/IP connection." Yahoo's new system works like this: Once a message is composed, it travels, unencrypted, to Yahoo, which sends it through a secure connection to SecureDelivery. There, the message and any attachments are scrambled. SecureDelivery then sends the recipient to a Web page, secured by Secure Sockets Layer (SSL) and hosted by SecureDelivery, where the message can be picked up and descrambled for up to seven days. Recipients first have to verify that they hold the specified email account. They then can choose a "pass phrase" that will automatically give them access to future messages . . .
Re: Is PGP broken?
Bram Cohen wrote: >What we really need is a system which just stops passive attacks. The best >idea I've come up with so far is for all outgoing messages to have a >public key attached, and if you have the public key of an email address >you're sending to you use it Indeed -- this is one of the current advantages of S/MIME over OpenPGP. Absolutely no reason why any PGP implementation shouldn't do it. This also allows you to do perfect forward secrecy: generate new short-life encryption key pairs for each message, sign the public key with your longer-lived signature key, and include it in your message for the reply. See http://www.ietf.org/internet-drafts/draft-brown-pgp-pfs-01.txt for an attempt by Adam Back, Ben Laurie and myself to standardise this and other PFS techniques for OpenPGP. >The worst that could really happen is that I lose my key info, construct >new stuff, and next time Russ sends me mail I respond 'sorry, but I lost >my old private key, please send that last message again'. A nice touch in a mailer would be to store sent messages in an "in transit" folder until a signed receipt is received, either in an individual receipt message or piggy-backed onto the reply, to help with this and other problems. >The only real >gotcha is that the first message is unencrypted, and that's not a big >deal, especially when you know about it and always send a 'checking to >make sure I got your address right' message to start things off. Right. And we could all start putting our public keys into the DNS -- do NAI have any plans to put that functionality into their software (e.g. allow the key manager to communicate with an agent running on your local authoritative nameserver?) Including your public signature key in signed messages also solves a gotcha with distributed keyserver systems, reverse lookup of keys by keyID. Ian :0)
International Forum on Surveillance by Design
*** PLEASE REDISTRIBUTE WIDELY *** http://www.cs.ucl.ac.uk/staff/I.Brown/ifsd.html International Forum on Surveillance by Design A one day public meeting on the development of global surveillance strategies for law enforcement and national security The Old Theatre The London School of Economics Houghton Street London WC1A 2AE Friday September 22, 2000 9.30 am Hosted by the Department of Information Systems The London School of Economics Organised by Privacy International, the American Civil Liberties Union, and Quintessenz Sponsored by Zero Knowledge Systems, Securify, and the Electronic Privacy Information Center General Chair: Simon Davies Admission : free Communications surveillance is now a global business. Over the past three decades, law enforcement and national security agencies have worked with the private sector to ensure that all new forms of communications are capable of being monitored. A range of new international legal agreements provide the foundation for this activity. Who are the key players in this new industry? What mechanisms are being developed to build surveillance into the architecture of communications? What forms of technology are being used to intercept communications - and to resist interception? This unique one-day conference will explore these technical and legal questions, and provide a public forum for open discussion. PROGRAMME 9.15Chairman's welcome and introduction 9.25Setting the landscape of engagement. A overview of the main players and key initiatives Tony Bunyan (Statewatch) 9.50Technique 1: Developing the Telephone System * An overview of global National Security arrangements Steve Wright (Omega Foundation) * Re-Designing the Plain Old Telephone System Barry Steinhardt (American Civil Liberties Union) * The International Law Enforcement Telecommunications Seminar Tony Bunyan (Statewatch) 10.45Technique 2: Re-Designing the Internet Intercepting the Internet * The Russian SORM system; Boris Pustinsev, Citizens Watch, Russia * The Regulation of Investigatory Powers Act * The Netherlands interception arrangements. Maurice Wessling (Bits of Freedom) * Unlawful conduct and the FBI Carnivore system International Collaboration (G8, Council of Europe) Global Protocols * IETF (invited * ETSI (invited) 11.30BREAK 12.00Technique 3: (De)Constructing Mobile Phone Security * GSM surveillace techniques * UMTS surveillance techniques Erich Moechel (Quintessenz, Austria) 1.00LUNCH 2.15 Technique 4: Imminent Technologies * Convergence * Mobile Telephony - Advanced Services of UMTS (location tracking, interactive services) - Bluetooth implications * Infrastructures of Identity * Privacy Risks of Public Key Infrastructures: Stefan Brands (ZeroKnowledge) 3.15BREAK 3.45Fighting for Privacy Industry Perspectives * Peter Harter (Securify) * Stephanie Perrin (ZeroKnowledge Systems) Legislative and Constitutional Protections Technical Countermeasures * Secure telephony; Eric Blossom, Starium * Secure internet communications; ZeroKnowledge 4.45Action Plan * Human Rights Organisations -- Simon Davies (PI) * Industry Action * Action through media Places are strictly limited in number, so anyone wishing to attend should email the conference chair, Simon Davies, at [EMAIL PROTECTED] Telephone enquiries : 0207 955 6579 Organising Committee: Simon Davies (PI & LSE), Erich Moechel (Quintessenz), Barry Steinhardt (ACLU), Ian Brown (UCL & Hidden Footprints), Stephanie Perrin (ZKS), Gus Hosein (LSE).
Comcast@Home bans VPNs
Customers blast Comcast move to foil bandwidth hogs By Corey Grice Staff Writer, CNET News.com August 16, 2000, 12:00 p.m. PT Revisions made to a Comcast Online customer agreement document have irked some high-speed cable-modem customers concerned about a prohibition on the use of secure networking technology. The document, which governs acceptable uses for the company's cable-modem service Comcast@Home, was recently updated for the third time. The new version, in section 6B, requires subscribers to agree not to use the service as a means to create what is known as a virtual private network, or VPN--a technology that provides a secure connection across the Internet... http://news.cnet.com/news/0-1004-200-2536215.html
Re: UK searching traveler's disk drives for pornography (fwd)
>Wasn't there a story very much like this, a year or two ago, that turned >out to be a hoax? Not that I have heard about. Ken Cukier's original story was confirmed by a UK Customs spokesperson: http://www.sightings.com/political/laptops.htm 'A spokesman for Customs and Excise said officials would routinely scan laptops for illegal material such as pornography. Encrypted files will be treated in the same way as a ordinary luggage. "So far as we are concerned, there is no difference between an encrypted file and a locked suitcase," said the spokesman. "All travellers entering the country should be prepared to have their equipment scanned."' >I suspect the Customs people could get away with all >kinds of nonsense, but is there any independent documentation that they >really are getting away with it right now? I haven't heard anything further since Ken's report, but it may just be they've avoided journalists more effectively since then ;) Ian :)
Re: FBI involves itself in Verio merger
>IANAL but wouldn't the UK's proposed legislation make software that >won't provide access to all keys implicitly illegal? This has been the subject of great debate in the UK. The RIP Bill says that you can be served with a key demand if you "have or have had" the requested key. Until this week, the burden of proof then fell upon *you* to prove it was no longer in your posession. (How to prove a negative...) Many people interpreted this as saying that you had to keep copies of all keys, just in the case any public authority decided it wanted a copy. The one substantive concession the government made last week was to put the burden of proof back on the prosecution, and add some language to try and make clear that keys destroyed in the normal manner by software were legitimately no longer in your posession. This would almost have certainly been forced on the government anyway by the European Convention on Human Rights; a very recent case held that another such "reverse burden of proof" (under anti-terrorism legislation) contravened the right to a fair trial (no sh*t!) Ian.
UK's key-grabbing legislation
Latest is that the UK's horrendous mish-mash of Internet surveillance and decryption/key (actually government-issued) "warrants" legislation is facing extreme opposition in our House of Lords. Unfortunately, the Government seems intent on driving the bill through Parliament (as they have the power to do against the unelected Lords). Businesses considering UK investments might find the following useful. Its author worked at the UK Ministry of Defence for 35 years, rising to a very senior level in their COMSEC office. Further information is at http://www.fipr.org/rip/ From: Brian Gladman <[EMAIL PROTECTED]> To: ukcrypto <[EMAIL PROTECTED]> Subject: UK E-Commerce Business Alert Date: Mon, 19 Jun 2000 15:48:01 +0100 UK E-COMMERCE BUSINESS ALERT I have put up a page at: http://www.btinternet.com/~brian.gladman/rip.html as a preliminary warning to companies about the need to consider RIP legislation before they create an e-commerce presence in the UK. I have advised all such companies not to abandon plans for such a presence but to put their plans on hold until the situation with RIP legislation becomes clearer. I have also advised companies to develop contingency plans for locating in Ireland or Germany in the event that RIP is enacted without significant change. I have also put up the following document: http://www.btinternet.com/~brian.gladman/res.pdf as a response to the Home Office comments on a number of aspects of the report written for the British Chamber of Commerce by the London School of Economics on the economic impact of RIP. My comments show, in particular: 1) That the Home Office suggestion that there are 'major inaccuracies' in the business risks identified in this report is completely flawed. Moreover, it is disingenuous, since these risks cannot be quantified as a direct result of the Home Office refusal to provide the information needed to do this. 2) The Government has admitted that information that it classifies as SECRET will not be protected to the standards that it sets for such information because the costs would be too high. In effect other people's information will not be treated with the same care as the Government treats its own information. I hope that people on this list will develop links to this page so that they can help to alert companies to the actions of the UK Government in seeking to undermine the safety, security and privacy of UK citizens and UK located businesses with this pernicious piece of legislation. Dr Brian Gladman (http://www.gladman.uk.net)
Multicast of Whit Diffie on non-secret encryption and public-key cryptography
Sorry for the short notice, but we're going to multicast on Tuesday a talk Whit Diffie did here last year on the history of PKC. Unfortunately, multicast support is flaky at best on the UK Internet: most universities will have it, but ISPs may not. I'm not sure about the global situation. You need three programs to watch: sdr (session directory), vic (video) and rat (audio), which are all at http://www-mice.cs.ucl.ac.uk/multimedia/software/ When you run sdr, you will see on Tuesday a description of the session details, and can start vic and rat from there to view the lecture. Ian :) -- Date:Tuesday, May 16 Time 15:00 BST (14:00 GMT) Title: Non-secret encryption and public-key cryptography Speaker: Dr. Whitfield Diffie In a remarkable case of 'scientific parallelism', a secret British group and a public American group, working entirely independently, made very similar discoveries during the early 1970s. The discovery was a revolutionary new form of cryptography. What was 'Non-secret Encryption' to the British and 'Public Key Cryptography' to the Americans, is at the heart of internet commerce and is achieving wide use throughout telecommunication. Whit Diffie, whose interests are both historical and scientific, was a participant in the American endeavour and has studied the work of the British team since the early 1980s. At a UCL public lecture on 29 April 1999, he ranged from reflections on the personal experience of discovery to an examination of the techniques developed and analysis of the differences in thinking of the two groups. The talk was organised by the British Society for the History of Mathematics and the Department of Computer Science, UCL.
Re: GPS integrity
Dorothy Denning wrote an interesting paper on authenticating location using GPS signals... I think it's reachable from her home page as well as the following citation: D. E. Denning and P. F. MacDoran, "Location-Based Authentication: Grounding Cyberspace for Better Security," Computer Fraud and Security, Feb. 1996 Ian :)
Re: Napster - the quiet revolution
>It seems however, that Napster suffers from a few design flaws:
>centralism (there is a central database, right?)
Unfortunately, yes. Each client logs on to a server, hands over a list of the
files it currently is sharing, then uses the server for searches. This seems
bad even for Napster Inc., who seem to be reducing one legal defense they
could have against copyright infringement lawsuits ("we don't distribute the
files, just the software used to access them...")
Even worse, the server then returns the IP addresses of clients where a
searched-for file can be retrieved. That really exposes Napster users! This
would be fixed if clients ran something like Freedom, but I don't think that
currently allow anonymous server addresses, so the Napster server couldn't
point a client to another anonymised IP address.
>An obvious problem is how to avoid collision with vanilla https
>(other than intercepting/redirecting https://aaa.bbb.ccc.ddd/napster/
>traffic. Perhaps just using https on a different port would be a
>smarter idea, though usage of a nonstandard port is bound to draw
>closer scrutiny).
It would be nice if Napster flows could be made completely indistinguishable
from standard https connections, including port numbers. You could always just
use vanilla https to transfer files between clients. The Napster protocol
includes lots of other functionality like chatrooms that isn't needed for this
application.
Alternatively, you could just mandate that tunnel-mode IPSEC or Freedom's
Anonymous IP be used on flows between clients.
>It would seem to be necessary to limit the scope of visibility to
>direct neighbours only, to prevent malicious users from obtaining
>extensive lists of other Napster users' addresses. To increase
>obfuscation, introducing some traffic mixing should be contemplated,
>injecting pseudorandom garbage traffic between direct neighbours to
>foil statistical traffic attacks.
The consensus on the [EMAIL PROTECTED] Majordomo list (set up to discuss
this kind of anonymous publishing) was that publishing on its own is a
difficult task without needing to handle anonymising clients as well. As we
already have tools to perform the second function, it would be nice to
leverage them here.
There's a link farm of projects of this type at http://www.cypherspace.org/
Ian :)
Re: TechWeb 10/2/2000: "E-Spying Bill Called 'Escrow By Intimidation'"
>A question on UK legislative terminology: >Does "published a bill" mean that Parliament approved it? >Or does it just mean that the ministers are proposing this law >that they'd _like_ to get Parliament to pass, but it >hasn't been passed yet? The latter. A Bill becomes an Act once it has been approved by Parliament. However, the Labour government has a large majority (179 as I recall) and is ferocious in forcing its MPs to vote the way it wants. This parliamentary term, even more than Margaret Thatchers' in the 80s, has been a a real demonstration of an "elective dictatorship" in action. One of our few consolations is that the government has brought the European Convention on Human Rights into domestic law, which provides at least some remedy against over-encroachment of government power -- though far less than the US Constitution. Ian :)
Re: Coerced decryption?
>Let's suppose that some stranger send me an unsolicited >document encrypted with a key different from mine: how am I supposed to >decrypt it? And can I really be thrown to jail for that?? Under the previous draft of the UK bill, yes -- see http://www.stand.org.uk/ for an amusing demonstration of this point. But the new draft says that you can only be compelled to hand over a key the authorities suspect you "have or have had." Still puts a horrendous burden of proof on you to show you don't currently possess it, unless you use PFS all the time. Ian :)
Re: Controlled CPU TEMPEST emanations
>How easy would it be to include some electronics or use >the circuitry in keyboards and have them emit signals? > >How vulnerable are keyboards to emitting tempest emanations? Some analysis, and suggestions on reducing this threat are at http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/nato-tempest.pdf
Re: HushMail: free Web-based email with bulletproof encryption
Perry Metzger wrote: >Some parts of this description make me nervous. Why are PRIVATE keys >being stored on a server, for instance? It's still hard to give applets access to client-side data in a secure and browser-independent way, but obviously this would be a great improvement. >Why use SSL to send keys when you could use SSL to just send the data? I think it's because the crypto library they are using (Cryptix) doesn't do SSL yet ;) I presume the applet and its startup parameters can be transferred over SSL by the browser, but the applet can't use that SSL pipe itself. Ian
Re: US Treasury use of BBN SafeKeyper in Echeck system
Ryan Lackey wrote: >I believe this to be a categorical problem for all systems lacking a >secured/tamper-resistant I/O conduit directly to the user. If you've solved >it, I would be very interested to learn how. cryptographic neural implants ;)
Re: What was the quid pro quo for Wassenaar countries?
Phillip Hallam-Baker wrote: >In addition under the single European act the entire country of Europe is >one export zone for crypto control purposes. Unfortunately, not yet. The European Commission has proposed amending the Dual-Use regulations to allow the free circulation of crypto products among member states, while extending controls to 'intangible' goods (i.e. Internet downloads). Until then an export license is required. Licenses are granted more readily and with fewer conditions (e.g. permitted end uses) for exports to other EU nations and Australia, Canada, Japan, New Zealand, Norway, Switzerland and the US. Amazing the minutiae you have to trawl when co-authoring a paper on crypto export controls ;) Ian.
Re: DCSB: Risk Management is Where the Money Is; Trust in Digital Comm
> Uhm, I see. But in that case, what happens if someone gets a (non-escrowed) > DSA cert, and uses it for a secure web server only supporting the > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite (ephemeral Diffie-Hellman > authenticated with DSS)? Strong, MIM-attack-resistant, and required by TLS > for minimum compliance (and, HOPEFULLY, some day supported by popular > browsers...) Although it isn't clear if this will happen (or even if the govt. has realised the possibility), the CA could set keyUsage flags in the certificate to stop a DSA cert from authenticating a strong encryption key at all, or limit authenticated encryption key length to 40 bits, or not allow any further certification by that key. The wonders of X.509... Ian.
Re: DCSB: Risk Management is Where the Money Is; Trust in Digital Comm
>Alas, the latest proposals by the Department of Trade and Industry in UK are >to extend legal protection only to digital signatures whose keys are >escrowed with OFTEL Much as I dislike the DTI's proposals, it is more complex than that. "Licensed" CAs do not have to escrow signature-only private keys when they certify the corresponding public key. But if a certified public key can be used for encryption and not just signature verification, the corresponding private key must be escrowed, and available to law enforcement within an hour of a warrant being presented to the CA. Cue mass switch from RSA to DSA... Oh, and CAs aren't allowed to be licensed for certifying signature-only keys but unlicensed for certifying encryption-capable keys. The DTI are trying to intimate to judges that signatures checkable with certificates from licensed CAs should be given a stronger presumption of validity than those from unlicensed CAs. But the draft European Commission directive on electronic signatures explicitly prohibits member states from doing this. Could be an interesting battle. Ian :(
