Re: Certificate-stealing Trojan

2010-09-29 Thread Thierry Moreau

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

2010-09-29 Thread Josh Rubin

 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?

2010-09-29 Thread Jerry Leichter

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?

2010-09-29 Thread Florian Weimer
* 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?)

2010-09-29 Thread Bill Stewart

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

2010-09-29 Thread Bill Stewart

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

2010-09-29 Thread James A. Donald

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

2010-09-29 Thread Kevin W. Wall
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

2010-09-29 Thread dan

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

2010-09-29 Thread Ken Buchanan
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]

2010-09-29 Thread Thor Lancelot Simon
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