Re: Certificate-stealing Trojan
Marsh Ray wrote: On 09/27/2010 08:26 PM, Rose, Greg wrote: On 2010 Sep 24, at 12:47 , Steven Bellovin wrote: Per http://news.softpedia.com/news/New-Trojan-Steals-Digital-Certificates-157442.shtml there's a new Trojan out there that looks for a steals Cert_*.p12 files -- certificates with private keys. Since the private keys are password-protected, it thoughtfully installs a keystroke logger as well Ah, the irony of a trojan stealing something that, because of lack of PKI, is essentially useless anyway... While I agree with the sentiment on PKI, we should accept this evidence for what it is: There exists at least one malware author who, as of recently, did not have a trusted root CA key. Additionally, the Stuxnet trojan is using driver-signing certs pilfered from the legitimate parties the old-fashioned way. This suggests that even professional teams with probable state backing either lack that card or are saving it to play in the next round. Is it possible that the current PKI isn't always the weakest link in the chain? Is it too valuable of a cake to ever eat? Or does it just leave too many footprints behind? Don't forget that the described trojan looks for an actual *client* private key and certificates. This puts Malory in a position to impersonate the victim comprehensively including non-crypto validity checks (e.g. confidence gained from log of recent activity using this certificate). Then the question is which PKIs actually deploy client certificates. - Marsh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com -- - Thierry Moreau CONNOTECH Experts-conseils inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Obama administration revives Draconian communications intercept plans
On 9/28/2010 1:47 AM, Florian Weimer wrote: Essentially, officials want Congress to require all services that enable communications — including encrypted e-mail transmitters like BlackBerry, social networking Web sites like Facebook and software that allows direct “peer to peer” messaging like Skype — to be technically capable of complying if served with a wiretap order. The mandate would include being able to intercept and unscramble encrypted messages. Isn't this just a clarification of existing CALEA practice? In most jurisdictions, if a communications services provider is served an order to make available communications, it is required by law to provide it in the clear. Anything else doesn't make sense, does it? Service providers generally acknowledge this (including Research In Motion, so I don't get why they are singled out in the article). SNIP This post from the IETF Wiretapping list [RAVEN] from October, 1999 may be relevant to the discussion. Should Tin Cans and String comply with CALEA? http://www.ietf.org/mail-archive/web/raven/current/msg7.html The question has special significance to me as proprietor of tincansandstring.net -- Josh Rubin jlru...@tincansandstring.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: ciphers with keys modifying control flow?
On Sep 22, 2010, at 9:34 AM, Steven Bellovin wrote: Does anyone know of any ciphers where bits of keys modify the control path, rather than just data operations? Yes, I know that that's a slippery concept, since ultimately things like addition and multiplication can be implemented with loops in the hardware or firmware. I also suspect that it's potentially dangerous, since it might create very hard-to-spot classes of weak keys. The closest I can think of is SIGABA, where some of the keying controlled the stepping of the other rotors. This reminds me of an old, apparently-abandoned idea for producing one- way hash functions: Choose two functions f_0 and f_1 that don't commute. For input b_0 b_1 ... b_k, the hash is f_b_k(f_b_k-1(...f_b_0(0)...)). Obviously, saying the functions don't commute isn't enough. What you really want is that if you consider the group generated by f_0 and f_1, then there are no short non-trivial relations (or, same thing, cycles). Also, of course, you can use more functions - e.g., use four functions and pull off successive pairs of bits. A variant uses the input itself as the initial value, rather than 0 - though that limits the domain. Alternatively, you could start with the length of the input, eliminating trivial extension attacks. This idea goes back to the early 70's at least. There was really no theory of how to produce or analyze one-way hash functions in those days, but this one clearly comes from an approach to designing encryption functions (alternating substitutions and permutations) suggested by Shannon in his seminal work on cryptography. Shannon, in turn, credits a theorem of Hopf's on mixing functions for the basic idea - which is ultimately at the root of most encryption functions in use today. On its face, this approach has much to recommend it. It's a pure stream computation. You can use any group for your functions. There's a ton of theory on group presentations that might apply. (Of course, many interesting questions about group presentations turn out to be non-computable; not just any group will work. Given what we've learned since the '70's, using two different representatives from a universal class of hash functions might be an interesting starting point.) Anyone aware of why, back in the pre-history of one-way functions, this design approach was abandoned? Perhaps there really are fundamental problems with it; or perhaps it's just that the MD-style approach was so successful that it just took over. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: ciphers with keys modifying control flow?
* Steven Bellovin: Does anyone know of any ciphers where bits of keys modify the control path, rather than just data operations? AES. See François Koeune, Jean-Jacques Quisqater, A timing attack aganst Rijndael. Université catholique de Louvain, Technicl Report CG-1999. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Haystack (helping dissidents?)
cryptography@metzdowd.com On Thu, Sep 16, 2010 at 04:49:19PM +, M.R. wrote: | I said (something like) this when Haystack first appeared on this | list... | | Words dissidents and oppressive regimes have no place in | serious discussions among cryptographers. Once we start assigning | ethical categorizations to those that protect and those that attack | (data files, communications channels, etc.) we are watering the | garden in which the weeds like Haystack flourish. They do tell you what level of attack you're trying to block. There's spammers trying to crack your system for money, but then there's a national government that doesn't like you, though I suppose it's possible that if you're not annoying one of the top ten governments, you might get a larger attack by annoying 4chan. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Stanford 10/7/2010 -- Lessons from the Haystack Affair
Potentially interesting lecture if you're in the Bay Area From: alli...@stanford.edu Reply-To: alli...@stanford.edu Subject: Liberation Technology 10/7/2010 -- Lessons from the Haystack Affair Date: Mon, 27 Sep 2010 13:40:55 -0700 (PDT) STANFORD FREEMAN SPOGLI INSTITUTE FOR INTERNATIONAL STUDIES The Stanford Program on Liberation Technology Seminar Series is starting up again. The first of the series will be held on Sept 23, 4:30pm at Wallenberg Hall. As an EE380 attendee you may find this series of lectures at the cust of Computer Science, Electrical Engineering, and Social Science his stimulating and informative series. Lessons from the Haystack Affair October 7, 2010 4:30 PM - 6:00 PM Wallenberg Theater Wallenberg Hall 450 Serra Mall, Building 160 Abstract Haystack, a circumvention tool, emerged in the wake of the repression after the Iranian election of June 2009. After achieving considerable public prominence, its use and distribution was recently halted. Important questions have been raised about Haystack's effectiveness and security, as well as the roots of its reputation. Evgeny Morozov, who emerged as a leading critic of Haystack, and Daniel Colascione, who wrote the Haystack code, will discuss the Haystack experience and the lessons it carries for circumvention technologies and, more broadly, for the evaluation and political deployment of new information technologies. Daniel Colascione co-founded the Censorship Research Center in June 2009 in the aftermath of the Iranian election and has had a lifelong interest in internet freedom and technological measures to mitigate censorship. He created the Haystack anti-censorship system and holds a BSc in Computer Science from the SUNY University at Buffalo. Speaker Evgeny Morozov is a leading thinker and commentator on the political impact of the Internet and a well known opponent of internet utopianism. He is a contributing editor to Foreign Policy and runs the magazine's Net Effect blog about the Internet's impact on global politics. Evgeny is currently a Yahoo! fellow at the Institute for the Study of Diplomacy at Georgetown University. Prior to his appointment to Georgetown, he was a fellow at the Open Society Institute, where he remains on the board of the Information Program. Before moving to the US, Evgeny was based in Berlin and Prague, where he was Director of New Media at Transitions Online, a media development NGO active in 29 countries of the former Soviet bloc. He is writing a book about the Internet and democracy, to be published this fall by Public Affairs. Open to the public No RSVP required For more information on the Program on Liberation Technology go to- http://liberationtechnology.stanford.edu/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
On 2010-09-28 1:58 PM, Thai Duong wrote: On Sat, Sep 18, 2010 at 8:43 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: I'm one of the authors of the attack. Actually if you look closer, you'll see that they do it wrong in many ways. The FormsAuth as well, not just the view state? �Interesting, I thought they had that one right, at least. We promised Microsoft not to release anything before they have a working patch. Now they have it, so we release the slide we presented at EKOPARTY. Check it out. http://netifera.com/research/poet//PaddingOraclesEverywhereEkoparty2010.pdf Now I understand why one should, counterintuitively, encrypt then MAC. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: 'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
Thai Duong wrote: On Tue, Sep 28, 2010 at 12:49 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ye gods, how can you screw something that simple up that much? They use the appropriate, and secure, HMAC-SHA1 and AES, but manage to apply it backwards! I guess they just follow SSL. BTW, they screw up more badly in other places. Download .NET Reflector, decompile .NET source, and do a grep 'DecryptString', you'll see at least three places where they don't even use a MAC at all. So, I think I brought this up once before with Thai, but isn't the pre-shared key version of W3C's XML Encrypt also going to be vulnerable to a padding oracle attack. IIRC, W3C doesn't specify MAC at all, so unless you use XML Digital Signature after using XML Encrypt w/ a PSK, then it seems to me you are screwed in that case as well. And there are some cases where using a random session key that's encrypted with a recipient's public key is just not scalable (e.g., when sending out to over something like Java Message Service, or the Tibco Bus, or almost anything that uses multicast). And even if a new XML Encrypt spec for using with PSK was adopted tomorrow, the adoption would take quite a long time. Sure hope I'm wrong about that. Maybe one of you real cryptographers can set me straight on this. -kevin -- Kevin W. Wall The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents.-- Nathaniel Borenstein, co-creator of MIME - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Obama administration wants encryption backdoors for domestic surveillance
as usual, there's an XKCD for that http://xkcd.com/504/ --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Obama administration revives Draconian communications intercept plans
On Tue, Sep 28, 2010 at 1:47 AM, Florian Weimer f...@deneb.enyo.de wrote: Isn't this just a clarification of existing CALEA practice? In most jurisdictions, if a communications services provider is served an order to make available communications, it is required by law to provide it in the clear. Anything else doesn't make sense, does it? Service providers generally acknowledge this (including Research In Motion, so I don't get why they are singled out in the article). Florian, The article seems to be saying that this would prohibit service providers from building strong end to end encryption onto their service offerings, where they do not possess the key themselves. There are only a handful of services that currently have offerings that fit this description, because it generally requires that clients at both end points are both made by the provider. It does not appear that this would affect crypto offerings by other technology companies who do not provide communications services. Of course, the text of any forthcoming bill is not yet known, and in any case I am not a lawyer. Neither is Chris Soghoian, but he makes an interesting point about CALEA: http://paranoia.dubfire.net/2010/09/calea-and-encryption.html Ken - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
2048 bits, damn the electrons! [...@openssl.org: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits]
See below, which includes a handy pointer to the Microsoft and Mozilla policy statements requiring CAs to cease signing anything shorter than 2048 bits. As I think I said last week -- was it last week? -- it's my belief that cutting everything on the Web over to 2048 bits rather than, say, 1280 or 1536 bits in the near term will be a significant net loss of security, since the huge increase in computation required will delay or prevent the deployment of SSL everywhere. These certificates (the end-site ones) have lifetimes of about 3 years maximum. Who here thinks 1280 bit keys will be factored by 2014? *Sigh*. - Forwarded message from Rob Stradling via RT r...@openssl.org - Lines: 327 Return-Path: owner-openssl-...@openssl.org X-Original-To: t...@panix.com Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by mailbackend.panix.com (Postfix) with ESMTP id B4B4031A88 for t...@panix.com; Wed, 29 Sep 2010 15:54:48 -0400 (EDT) Received: from master.openssl.org (master.openssl.org [195.30.6.166]) by mail1.panix.com (Postfix) with ESMTP id 2E38A1F094 for t...@panix.com; Wed, 29 Sep 2010 15:54:48 -0400 (EDT) Received: by master.openssl.org (Postfix) id 428621EAE8D5; Wed, 29 Sep 2010 21:54:16 +0200 (CEST) Received: by master.openssl.org (Postfix, from userid 29101) id 40DB41EAE8D4; Wed, 29 Sep 2010 21:54:16 +0200 (CEST) Received: by master.openssl.org (Postfix, from userid 29101) id EE8551EAE8D2; Wed, 29 Sep 2010 21:54:15 +0200 (CEST) Subject: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits From: Rob Stradling via RT r...@openssl.org In-Reply-To: 201009291252.23829.rob.stradl...@comodo.com References: rt-ticket-2...@openssl.org 201009291252.23829.rob.stradl...@comodo.com Message-ID: rt-3.4.5-45870-1285790055-1192.2354-2...@openssl.org X-RT-Loop-Prevention: openssl.org RT-Ticket: openssl.org #2354 Managed-by: RT 3.4.5 (http://www.bestpractical.com/rt/) RT-Originator: rob.stradl...@comodo.com Cc: openssl-...@openssl.org MIME-Version: 1.0 X-RT-Original-Encoding: utf-8 Content-type: multipart/mixed; boundary=--=_1285790055-45870-1 Date: Wed, 29 Sep 2010 21:54:15 +0200 (CEST) Sender: owner-openssl-...@openssl.org Precedence: bulk Reply-To: openssl-...@openssl.org X-Sender: Rob Stradling via RT r...@openssl.org X-List-Manager: OpenSSL Majordomo [version 1.94.5] X-List-Name: openssl-dev X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.1.7 This is a multi-part message in MIME format... =_1285790055-45870-1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit NIST (SP800-57 Part 1) recommends a minimum RSA key size of 2048-bits beyond 2010. From January 1st 2011, in order to comply with the current Microsoft[1] and Mozilla[2] CA Policies, Commercial CAs will no longer be permitted to issue certificates with RSA key sizes of 2048-bit. Please accept the attached patch, which increases the default RSA key size to 2048-bits for the req, genrsa and genpkey apps. Thanks. [1] http://technet.microsoft.com/en-us/library/cc751157.aspx says: we have advised Certificate Authorities...to transition their subordinate and end-certificates to 2048-bit RSA certificates, and to complete this transition for any root certificate distributed by the Program no later than December 31, 2010. [2] https://wiki.mozilla.org/CA:MD5and1024 says: December 31, 2010 ??? CAs should stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root. Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. =_1285790055-45870-1 Content-Type: text/x-patch; charset=utf-8; name=default_2048bit_rsa.patch Content-Disposition: inline; filename=default_2048bit_rsa.patch Content-Transfer-Encoding: 7bit RT-Attachment: 2354/28329/14216 Index: apps/genrsa.c === RCS file: /v/openssl/cvs/openssl/apps/genrsa.c,v retrieving revision 1.40 diff -U 5
