Hi
I had an idea very similar to the one Peter Gutmann had this morning. I
managed to write a real world exploit which takes as input:
* an CA-Certificate using 1024 Bit RSA and Exponent 3 (ca-in)
* a Public Key, using an algorithm and size of your choice
(key-in)
and generat
--
Greg Rose wrote:
> At 19:02 +1000 2006/09/14, James A. Donald wrote:
>> Suppose the padding was simply
>>
>> 010101010101010 ... 1010101010101 hash
>>
>> with all leading zeros in the hash omitted, and four
>> zero bits showing where the actual hash begins.
>>
>> Then the error would n
On Thu, Sep 14, 2006 at 11:25:11AM -0400, [EMAIL PROTECTED] wrote:
>
> "James A. Donald" writes:
> -+---
> |
> |
> | ASN.1 provided additional redundant information, making
> | possible unexpected data layouts that should not
> | normally happen. It had too much express
| The problem is that _because there is an interface to poll the token for
| a code across the USB bus_, malicious software can *repeatedly* steal new
| token codes *any time it wants to*. This means that it can steal codes
| when the user is not even attempting to authenticate
I think this su
At 23:40 +1200 2006/09/14, Peter Gutmann wrote:
But wait, there's more! From what I understand of the attack, all you need
for it to work is for the sig.value to be a perfect cube. To do this, all you
need to do is vary a few of the bytes of the hash value, which you can do via
a simple brute-
At 19:02 +1000 2006/09/14, James A. Donald wrote:
Suppose the padding was simply
010101010101010 ... 1010101010101 hash
with all leading zeros in the hash omitted, and four
zero bits showing where the actual hash begins.
Then the error would never have been possible.
I beg to differ. A
So, there is at least one top-level CA installed in some common
browsers (I checked Firefox) that uses exponent-3. It is "Starfield
Technologies Inc." "Starfield Class 2 CA". There may well be
others... I only looked far enough to determine that that was a
problem.
So the next question become
Peter Gutmann writes:
> But wait, there's more! From what I understand of the attack, all you need
> for it to work is for the sig.value to be a perfect cube. To do this, all you
> need to do is vary a few of the bytes of the hash value, which you can do via
> a simple brute-force search. So eve
[EMAIL PROTECTED] (Peter Gutmann) writes:
>>>Changing this could be tricky because there are all sorts of
>>>inconsistencies both in standards and implementations, the standard
>>>practice has been to skip the parameters field because if you don't,
>>>things break.
>>
>>I don't think so. The cont
On Wed, Sep 13, 2006 at 10:23:53PM -0400, Vin McLellan wrote:
>
[... a long message including much of what I can only regard as
outright advertising for RSA, irrelevant to the actual technical
weakness in the SID800 USB token that Hadmut described, and which
Vin's message purportedly disputes.
Peter Gutmann wrote:
There'll always be broken standards out there that require e=3 (I know of
at least one that uses e=2, and [...]
OK, we've got into trouble with the exponent 3 because the RSA technique
has been applied with varying degrees of care (both specifications
drafting and im
"James A. Donald" writes:
-+---
|
|
| ASN.1 provided additional redundant information, making
| possible unexpected data layouts that should not
| normally happen. It had too much expressive power, too
| much flexibility. It could express cases that one does
| not exp
On 9/14/06, James A. Donald <[EMAIL PROTECTED]> wrote:
It seems to me that the evil here is ASN.1, or perhaps standards that
use ASN.1 carelessly and badly.
It is difficult to write code that conforms to ASN.1, easy to get it
wrong, and difficult to say what in fact constitutes conforming to ASN
Simon Josefsson <[EMAIL PROTECTED]> writes:
>[EMAIL PROTECTED] (Peter Gutmann) writes:
>>Simon Josefsson <[EMAIL PROTECTED]> writes:
>>>The second problem is that the "parameters" field can ALSO be used to store
>>>data that may be used to manipulate the signature value into being a cube.
>>>To my
Why the exponent 3 error happened:
The signature consists of a number that when cubed, is
equal modulo N to the padded hash of the quantity to be
signed.
Part of the padding is the ASN.1 encoding of the hash.
Now suppose we had not ASN.1 encoded the hash.
Suppose the padding was simply
010101
[EMAIL PROTECTED] (Peter Gutmann) writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>>The second problem is that the "parameters" field can ALSO be used to store
>>data that may be used to manipulate the signature value into being a cube.
>>To my knowledge, this was discovered by Yutaka Oiwa
Simon Josefsson <[EMAIL PROTECTED]> writes:
>The second problem is that the "parameters" field can ALSO be used to store
>data that may be used to manipulate the signature value into being a cube.
>To my knowledge, this was discovered by Yutaka Oiwa, Kazukuni Kobara, Hajime
>Watanabe. I didn't at
Simon Josefsson wrote:
Jostein Tveit <[EMAIL PROTECTED]> writes:
Anyone got a test key with a real and a forged signature to test
other implementations than OpenSSL?
There are actually two problems to consider...
First, there is the situation by Bleichenbacher at Crypto 06 and
explained in:
On Cryptography, and in several other online forums, Hadmut Danisch
<[EMAIL PROTECTED]>, a respected German information security analyst,
recently published a harsh critique of one optional feature in the
SID800, one of the newest of the six SecurID authentication tokens --
some with slightly
19 matches
Mail list logo