Re: RSA SecurID SID800 Token vulnerable by design

2006-09-10 Thread Anne Lynn Wheeler

Lance James wrote:

Agreed, and since my research is focused on online banking I can see
yours and my point, either way, SecurID should not be the only concept
for dependence.


as i've mentioned serveral times, in the mid-90s, the x9a10 financial 
standards working group was given the task of preserving the integrity 
of the financial infrastructure for all retail payments. the result was 
x9.59 standard

http://www.garlic.com/~lynn/x959.html#x959

which specified (end-to-end) authenticated transaction (and a business 
rule that account numbers used in x9.59 transactions could not be used 
in non-authenticated transactions) ... recent, related post:
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK 
ChipPin woes


part of the issue was with the actual transactions being signed and 
running end-to-end ... and account numbers no longer vulnerable to 
naked exploits ... it was no longer necessary to hide the account 
number (as countermeasure to prevent fraudulent replay attack 
transactions).

http://www.garlic.com/~lynn/subpubkey.html#harvest

the issue then became end-point attacks; either the originating 
end-point or the authorizing end-point. most infrastructure have had the 
authorizing end-points pretty well armored for some time. that primarily 
leaves vulnerabilities at the originating end-point.


part of the EU finread terminal work was to close off some of the 
originating end-point vulnerabilities.

http://www.garlic.com/~lynn/subpubkey.html#finread

basically an independent, secure token terminal with its own display and 
key-entry. the transactions is forwarded from the end-point to the 
finread terminal ... the finread terminal displays a summary of the 
transaction details ... and passes it to the token for digital signing. 
any pin-entry (for two-factor authentication ... token something you 
have and pin-entry something you know) is performed at the finread 
terminal (minimizing any pin evesdropping and associated pin replay 
attack exploits).


while session encryption is useful for confidentiality and privacy of 
the operations ... a lot of existing session encryption is primarily 
because existing transactions don't have end-to-end armored 
authentication ... leaving various pieces of information involved in the 
actual transaction naked and vulnerable to various kinds of replay attacks.


the x9.59 standards approach was to provide end-to-end armoring of the 
actual transactions ... eliminating numerous kinds of replay 
vulnerabilities and some of the man-in-the-middle attacks

http://www.garlic.com/~lynn/subpubkey.html#mitm

... independent of any possible use of authentication for session purposes

note that while it isn't part of the x9.59 standard ... the standard was 
carefully crafted such that end-point environments like the EU finread 
would be allowed to also sign transactions.


the issue is that the responsible authorization end-point frequently 
will be doing risk assessment  (especially involving financial 
transactions). it is easy to see that a eu finread terminal provides a 
much higher integrity digital signing environment that many personal 
computers (for instance, virus software than log the entered pin and 
replay it to a connected hardware token w/o the person's knowledge) ... 
it is useful to have some knowledge about the transaction originating 
environment when doing risk assessment.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: IGE mode is broken (Re: IGE mode in OpenSSL)

2006-09-10 Thread Ben Laurie
Adam Back wrote:
 Hi Ben, Travis
 
 IGE if this description summarized by Travis is correct, appears to be
 a re-invention of Anton Stiglic and my proposed FREE-MAC mode.
 However the FREE-MAC mode (below described as IGE) was broken back in
 Mar 2000 or maybe earlier by Gligor, Donescu and Iorga.  I recommend
 you do not use it.  There are simple attacks which allow you to
 manipulate ciphertext blocks with XOR of a few blocks and get error
 recovery a few blocks later; and of course with free-mac error
 recovery means the MAC is broken, because the last block is
 undisturbed.
 
 There is some more detail here:
 
 http://groups.google.ca/group/sci.crypt/browse_thread/thread/e1b9339bf9fb5060/62ced37bb9713a39?lnk=st

Interesting. In fact, Gligor et al appear to have proposed IGE rather
later than this date (November 2000).

In any case, I am not actually interested IGE itself, rather in biIGE
(i.e. IGE applied twice, once in each direction), and I don't care about
authentication, I care about error propagation - specifically, I want
errors to propagate throughout the plaintext.

In fact, I suppose I do care about authentication, but in the negative
sense - I want it to not be possible to authenticate the message.

These properties are needed for the Minx protocol.

So, I mentioned the authentication properties in passing. It is,
however, good to know they don't work! And I love the more general
result in the paper mentioned (http://eprint.iacr.org/2000/039/).

I may have misunderstood the IGE paper, but I believe it includes proofs
for error propagation in biIGE. Obviously if you can prove that errors
always propagate (with high probability, of course) then you can have
authentication cheaply - in comparison to the already high cost of
biIGE, that is.

Thanks!

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: IGE mode is broken (Re: IGE mode in OpenSSL)

2006-09-10 Thread Adam Back
On Sat, Sep 09, 2006 at 09:39:04PM +0100, Ben Laurie wrote:
  There is some more detail here:
  
  http://groups.google.ca/group/sci.crypt/browse_thread/thread/e1b9339bf9fb5060/62ced37bb9713a39?lnk=st
 
 Interesting. In fact, Gligor et al appear to have proposed IGE rather
 later than this date (November 2000).

Well looking at the paper by Gligor in their mode submission to NIST
on IGE, it appears rather that our FREE-MAC was a re-invention of IGE!
Apparently according to Gligor IGE was proposed by Carl Campbell in
Feb 1977, about the same time as CBC mode was proposed.  Gligor et al
wrote the mode-submission for IGE in Nov 2000.

 I may have misunderstood the IGE paper, but I believe it includes proofs
 for error propagation in biIGE. Obviously if you can prove that errors
 always propagate (with high probability, of course) then you can have
 authentication cheaply - in comparison to the already high cost of
 biIGE, that is.

I am not sure about the proofs in the IGE-spec paper, but at least the
proofs about IGE at least must be flawed somehow because the sci.crypt
post shows a a class of known plaintext modifications that exhibits
error recovery.  I worked through it on paper at the time, and as far
as I can see it trivially breaks IGE/FREE-MAC.  No doubt there are
other variations so there are lots of permutations you can do in
rearranging the ciphertext such that the integrity check still
passes.

Adam

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Raw RSA

2006-09-10 Thread James A. Donald

Leichter, Jerry wrote:

| It is known, that given such an oracle, the attacker can ask for
| decryption  of all primes less than B, and then he will be able to
| sign PKCS-1 encoded messages if the representative number is B-smooth,
| but is there any way to actually recover d itself?



RSA is multiplicative, so, yes, this follows easily unless the encoding
used prevents it.


Could you describe this attack in more detail.  I do not see a scenario 
where it would be useful.


The attacker can encrypt a subset of numbers - those that encrypt to a B 
smooth number, but for this to be useful to him, he has to find a number 
in the subset set that corresponds to what he desires to encrypt, which 
 looks like a very long brute force search.



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Exponent 3 damage spreads...

2006-09-10 Thread James A. Donald

--
Ben Laurie wrote:
 Subject:
 [dnsop] BIND and OpenSSL's RSA signature forging issue
 From:
 Ben Laurie [EMAIL PROTECTED]
 Date:
 Fri, 08 Sep 2006 11:40:44 +0100
 To:
 DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
 [EMAIL PROTECTED], dnsop@lists.uoregon.edu

 To:
 DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
 [EMAIL PROTECTED], dnsop@lists.uoregon.edu


 I've just noticed that BIND is vulnerable to:

 http://www.openssl.org/news/secadv_20060905.txt

 Executive summary:

 RRSIGs can be forged if your RSA key has exponent 3, which is BIND's
 default. Note that the issue is in the resolver, not the server.

 Fix:

 Upgrade OpenSSL.

 Issue:

 Since I've been told often that most of the world won't upgrade
 resolvers, presumably most of the world will be vulnerable to this
 problem for a long time.

 Solution:

 Don't use exponent 3 anymore. This can, of course, be done server-side,
 where the responsible citizens live, allegedly.

 Side benefit:

 You all get to test emergency key roll! Start your motors, gentlemen!

This seems to presuppose that Secure DNS is actually in use.  I was 
unaware that this is the case.


What is the penetration of Secure DNS?


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 fLselD6l8fdbF1p4sjg3RQ2GXi+NnQ//1CymnfKs
 4+JAX1zwW3fSIStp6glgbAygK1zCuoMeiTigr4qmd

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: signing all outbound email

2006-09-10 Thread James A. Donald

--
James A. Donald:
  One way of doing this would be for the MTA to insist
  on a valid signature when talking to certain well
  known MTAs, and then my MUA could whitelist mail
  sent from those well known MTAs

Paul Hoffman wrote:
 Yes, if you are willing to throw out messages whose
 signatures are broken during transit.

Signatures should not be broken when transmitted
directly from the signing MTA to the receiving MTA.  If
they are, then there is a bug in the signing or the
receiving MTA, in which case the offending party has the
ability and incentive to fix the bug.  Signatures are
likely to be broken when the signature is being checked
by the MUA, because an MTA that knows nothing about
signatures will probably break them, but an MTA that
knows to check signatures should know not to break them.

James A. Donald:
  In short, I am not able to get any advantage out of
  using this protocol, which means that there is no
  advantage in sending me signed mail.

Paul Hoffman wrote:
 And there is no disadvantage either. There is
 advantages for sending signed mail to users who have a
 different threat model than you have,

I don't think anyone is a different position to me. DKIM
is usable in principle, but I am not able to benefit
from it in practice.  If I am not able to benefit from
it in practice, who is?

DKIM would be a good idea if done right.  It does not,
in fact, seem to be working at present.

Part of the problem is that part of the whitelisting
task has to be done on the MTA, and part on the MUA, and
no one has made any provision for keeping them in sync.
Seems to me, that DKIM, as implemented, implements the
high tech part of the solution, but not the actual nuts
and bolts details of the solution.

As with so many specifications, the DKIM spec is both
overspecified and underspecified - too much fluff and
bullshit, but missing essentials.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 xI3XYSEBPo53gqyefixu7gq7WbsD5RRhDxMekg3p
 4xjdOGVtm+v4uCubvbccar454roc1aGW3/J1OXrQp

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Raw RSA

2006-09-10 Thread John R. Black
 I don't follow.  For RSA, the only difference between encryption and
 decryption, and public and private key, and hence between chosen
 plaintext and chosen ciphertext, is the arbitrary naming of one of
 a pair of mutually-inverse values as the private key and the other
 as the public key.
   -- Jerry
  
Negative, Jerry.

There is a very big difference between which one you make public and
which one you make private.  The difference is that the public one
is given out to the world.

It is well known that if d (the RSA private exponent) is small enough,
it can be recovered via Wiener's continued fraction attack or the 
several extensions of it.  I think Wiener's attack worked if d  N^{1/4},
and Boneh (with Glenn Durfee) brought this up to N^{.292}.  There is
a conjecture that d needs to be  sqrt(N), but no one's come close to
proving this.

So it IS important which one you name as the private key: name the bigger
one! :)

john//

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Exponent 3 damage spreads...

2006-09-10 Thread Ben Laurie
James A. Donald wrote:
 --
 Ben Laurie wrote:
 Subject:
 [dnsop] BIND and OpenSSL's RSA signature forging issue
 From:
 Ben Laurie [EMAIL PROTECTED]
 Date:
 Fri, 08 Sep 2006 11:40:44 +0100
 To:
 DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
 [EMAIL PROTECTED], dnsop@lists.uoregon.edu

 To:
 DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
 [EMAIL PROTECTED], dnsop@lists.uoregon.edu


 I've just noticed that BIND is vulnerable to:

 http://www.openssl.org/news/secadv_20060905.txt

 Executive summary:

 RRSIGs can be forged if your RSA key has exponent 3, which is BIND's
 default. Note that the issue is in the resolver, not the server.

 Fix:

 Upgrade OpenSSL.

 Issue:

 Since I've been told often that most of the world won't upgrade
 resolvers, presumably most of the world will be vulnerable to this
 problem for a long time.

 Solution:

 Don't use exponent 3 anymore. This can, of course, be done server-side,
 where the responsible citizens live, allegedly.

 Side benefit:

 You all get to test emergency key roll! Start your motors, gentlemen!
 
 This seems to presuppose that Secure DNS is actually in use.  I was
 unaware that this is the case.

Does it? All it presupposes, I thought, was that secure DNS was being
tested. Which it is.

 What is the penetration of Secure DNS?

Anyone who is running any vaguely recent version of BIND is DNSSEC
enabled, whether they are using it now or not. Unless they upgrade, they
will be vulnerable when they start to use it. So, the question of
whether to use exponent 3 is unrelated to the penetration of DNSSEC use
now, it is related to the penetration of broken implementations of
DNSSEC now.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: IGE mode is broken (Re: IGE mode in OpenSSL)

2006-09-10 Thread James A. Donald

--
Adam Back wrote:
 Hi Ben, Travis

 IGE if this description summarized by Travis is
 correct, appears to be a re-invention of Anton Stiglic
 and my proposed FREE-MAC mode. However the FREE-MAC
 mode (below described as IGE) was broken back in Mar
 2000 or maybe earlier by Gligor, Donescu and Iorga.  I
 recommend you do not use it.  There are simple attacks
 which allow you to manipulate ciphertext blocks with
 XOR of a few blocks and get error recovery a few
 blocks later; and of course with free-mac error
 recovery means the MAC is broken, because the last
 block is undisturbed.

 There is some more detail here:

 
http://groups.google.ca/group/sci.crypt/browse_thread/thread/e1b9339bf9fb5060/62ced37bb9713a39?lnk=st


http://www.quadibloc.com/crypto/co040603.htm gives a
list of integrity preserving techniques, most of them
patented - perhaps all of them patented.

Of the top of my head, I would think the following
method preserves integrity - but then who am I.  I
cannot prove it preserves integrity, whereas some of the
modes listed in url above have such proofs.

Let P(k) be the kth block of plain text.  We prepend a
random block, P(0) to the text, and append a fixed block
to the end.  If anything is altered, the fixed block at
the end will not contain the expected data, but will be
gibberish.

The adversary knows every block in the plain text
message except our P(0).  He can intercept and change
the encrypted message.  He wishes to modify the message
so that the intended recipient receives something
different from the message that the adversary knows he
should receive without the intended recipient realizing
something is wrong.

Let W(k) = P(k) + W(k-1) + W(k-1){W(k-1)}

Where  means bitwise and, and + means addition modulo 2
to the block size.

W(0) = P(0) (our random block, unknown to the adversary
or the recipient, and changing with every message.)

{} means encryption, {W(k-1)} is the block we get by
encrypting W(k-1)

We transmit T(k)= {W(k)} + W(k-1)|{W(k-1)} where |
means bitwise or, curly brace means encryption.

W(-1) is zero.

The adversary knows P(k), except for P(0), and can
intercept all transmitted values T(k).

Because the combination of addition and bitwise logical
operations is non linear, this method gets through a
loophole in Jutla's proof in
http://eprint.iacr.org/2000/039


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 YQoZxoUUL1Yd2nQ51t9INEhGv6av+5inX+kWvsHX
 49/HJZZyTbJf7yBMbpd6xO13ERPibcb3683FhcMMI

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Raw RSA

2006-09-10 Thread Leichter, Jerry
|  | It is known, that given such an oracle, the attacker can ask for
|  | decryption  of all primes less than B, and then he will be able to
|  | sign PKCS-1 encoded messages if the representative number is B-smooth,
|  | but is there any way to actually recover d itself?
| 
|  RSA is multiplicative, so, yes, this follows easily unless the encoding
|  used prevents it.
| 
| Could you describe this attack in more detail.  I do not see a scenario where
| it would be useful.
| 
| The attacker can encrypt a subset of numbers - those that encrypt to a B
| smooth number, but for this to be useful to him, he has to find a number in
| the subset set that corresponds to what he desires to encrypt, which  looks
| like a very long brute force search.
Let R(x) = x^k mod n - where k might be the public key - for encryption -
or the private key - for signing.  R(xy) = R(x)R(y) mod n.  For
encryption, this means little - since the encryption exponent is
public, anyone can compute R(xy) directly anyway.  But for signing,
it means that if I have my hands on signed copies of x and y, I can
forge a signature on xy.  Thus, if I am able to get signatures on a
good collection of primes, I can sign many messages easily.  Yet
another reason to sign hashes of messages, not raw messages - and
that the signer module should compute the hash itself, not rely on
the caller to do it.
-- Jerry


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Exponent 3 damage spreads...

2006-09-10 Thread bmanning
On Sun, Sep 10, 2006 at 08:30:53AM +1000, James A. Donald wrote:
 --
 Ben Laurie wrote:
  Subject:
  [dnsop] BIND and OpenSSL's RSA signature forging issue
  From:
  Ben Laurie [EMAIL PROTECTED]
  Date:
  Fri, 08 Sep 2006 11:40:44 +0100
  To:
  DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
  [EMAIL PROTECTED], dnsop@lists.uoregon.edu
 
  To:
  DNSEXT WG namedroppers@ops.ietf.org, (DNSSEC deployment)
  [EMAIL PROTECTED], dnsop@lists.uoregon.edu
 
 
  I've just noticed that BIND is vulnerable to:
 
  http://www.openssl.org/news/secadv_20060905.txt
 
  Executive summary:
 
  RRSIGs can be forged if your RSA key has exponent 3, which is BIND's
  default. Note that the issue is in the resolver, not the server.
 
  Fix:
 
  Upgrade OpenSSL.
 
  Issue:
 
  Since I've been told often that most of the world won't upgrade
  resolvers, presumably most of the world will be vulnerable to this
  problem for a long time.
 
  Solution:
 
  Don't use exponent 3 anymore. This can, of course, be done server-side,
  where the responsible citizens live, allegedly.
 
  Side benefit:
 
  You all get to test emergency key roll! Start your motors, gentlemen!
 
 This seems to presuppose that Secure DNS is actually in use.  I was 
 unaware that this is the case.
 
 What is the penetration of Secure DNS?

hard to tell... how many delegations are there?
that said, RIPE has signed all their delegations
and the SE delegation is signed.  privately, i am
aware of perhaps a dozen or so other delegations 
which are signed.  one might also look to the ISC
DLV registry to see which of those delegations are
signed.

--bill
 
 
 --digsig
  James A. Donald
  6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
  fLselD6l8fdbF1p4sjg3RQ2GXi+NnQ//1CymnfKs
  4+JAX1zwW3fSIStp6glgbAygK1zCuoMeiTigr4qmd
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]