Re: RSA SecurID SID800 Token vulnerable by design
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 Chip&Pin 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)
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)
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
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...
-- 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 , "(DNSSEC deployment)" > <[EMAIL PROTECTED]>, dnsop@lists.uoregon.edu > > To: > DNSEXT WG , "(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
-- 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
> 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: IGE mode is broken (Re: IGE mode in OpenSSL)
Adam Back wrote:
> 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.
Indeed, and you'll find this attack (or a similar one) in the proof of
Lemma 4 ("the schemes IGE$-z0 and IGE$-c are not EF-CPA, PU-CPA, PI-CPA,
and NM-CPA secure"), so I don't think you can cite them as flaws :-)
> 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.
Note that I was talking about biIGE, not IGE. IGE is indeed broken under
many attack types, and the paper acknowledges that.
--
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: Exponent 3 damage spreads...
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 , "(DNSSEC deployment)" >> <[EMAIL PROTECTED]>, dnsop@lists.uoregon.edu >> >> To: >> DNSEXT WG , "(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)
--
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
| > | 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...
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 , "(DNSSEC deployment)" > > <[EMAIL PROTECTED]>, dnsop@lists.uoregon.edu > > > > To: > > DNSEXT WG , "(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]
