RE: Exponent 3 damage spreads...

2006-09-22 Thread Leichter, Jerry
|10.2.3 Data decoding
|The data D shall be BER-decoded to give an ASN.1 value of
|type DigestInfo, which shall be separated into a message
|digest MD and a message-digest algorithm identifier. The
|message-digest algorithm identifier shall determine the
|selected message-digest algorithm for the next step.
| Here, any trailing garbage would be included in data D. But does an
| ASN.1 value allow such a thing? I am asking this independently of our
| discussion here.
| I don't think it's a problem, you just take the ASN.1 DigestInfo
| value, since the trailing garbage isn't part of the DigestInfo, you
| ignore it.  Specifically, the ASN.1 object is entirely self-contained,
| so you can tell exactly where it ends and what it contains.  Anything
| outside it is beyond the scope of this specification :-).
This is a rather peculiar interpretation of the spec.  If I look at a C
specification and it tells me that an integer is a string of digits,
when I write a C compiler, am I permitted to say that [EMAIL PROTECTED]% can
be parsed as an entirely contained integer, with the @#% beyond
the scope of the specification?

The only reasonable reading of the text quoted above is that the D must
consist of, and *only* of, an ASN.1 value of the given type.

Granted, one or more implementations got this wrong.  (Has anyone looked
to see if all the incorrect code all descends from a common root, way
back when?)  Those implementations are as wrong as a C compiler that
skips irrelevant junk at the end of an integer constant.  I wouldn't
blame either the spec or the use of ASN.1.  The implementations are
just plain wrong.  There isn't even any plausible interpretation that
would make them right.  (On the one hand, they use all the data,
including the junk, in computing the signature.  On the other hand,
they ignore some of the data when extracting the digest.  It's
clearly one piece of data!)

Granted, this particular design, e=3 and all, *may* be particularly
vulnerable to mistakes.  Until we know whether this is *one* mistake
that was copied from implementation to implementation, or the same
mistake made by multiple developers, it's really premature to draw any
conclusions.  But assume that's so.  Then indeed it's prudent to avoid
e=3 - more because of the likely number of broken implementations out
there that will take forever to move out of active use than for any
other reason.  But let's not draw the wrong conclusion.  Bad code is bad
code.  The error in reasoning here is not all that different from what
happens in various kinds of attacks, where for example the length of a
contained record is marked as larger than the length of the containing
record, is not checked separately - and produces a buffer overflow.

This is also related to an error in the C library design.  When
comparing *for equality*, strcmp(s,t) - ignoring issues about possible
missing trailing NUL's - has a very simple semantics:  It compares two
*strings*.  The corresponding memcmp(s,t,n) is usually thought of as
similarly comparing two memory regions - but that's *not* what it does.
To really compare two memory regions, it would have to have accept two
memory regions as inputs - that is, have separate pointers and a lengths
to give memcmp(s,m,t,n).  As it stands, the programmer given two memory
regions is left with the task of coming up with the right value for n.
In fact, what he *should* do is first compare the two lengths and decide
not equal if they differ.  In practice, programmers often use the
minimum of the two lengths for n, which actually tests one region and
one leading substring of another.  Not what they had in mind - and
indeed earlier in this thread we saw exactly this produce buggy code.
(BTW, strncmp(), the fix for unterminated strings, has the same
problem:  Since it has a single maximum length, it no longer has a
simple semantics as a C string comparison function.)

| (When the spec was written, I think the thought that someone would append
| trailing garbage never cropped up, so it's never explicitly addressed).
I think you'd be hard pressed to find any spec that addresses such a
thing.  When a spec says X is an A followed by a B, the and nothing
else is implied.

| Anyway, I think we agree on the point that the spec (even version 2.1) is in
| some point unprecise which should be considered a bug, as it can lead to
| implementation flaws. And yes, given what we know, e=3 is a good candidate
| for elimination :)
| Yup :-).
I think you're putting the blame in the wrong place.

-- Jerry

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

Re: Did Hezbollah use SIGINT against Israel?

2006-09-22 Thread James A. Donald

Steven M. Bellovin wrote:
 That isn't supposed to be possible these days...  (I
 regard it as more likely that they were doing traffic
 analysis and direction-finding than actually cracking
 the ciphers.)

Ciphers cannot be cracked when used correctly.  However,
military cipher procedures are often highly user
unfriendly, and in consequence seldom used correctly.
Come to think of it, we have the same problem on the

 James A. Donald

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

Re: Did Hezbollah use SIGINT against Israel?

2006-09-22 Thread Travis H.

On 9/20/06, Leichter, Jerry [EMAIL PROTECTED] wrote:

Newspaper reports have claimed that many troops were sent into the
field with old equipment - including in particular 10+-year-old
communications equipment.

The Single Channel Ground and Airborne Radio System was designed in the 80's:

I don't know the hop frequency, but it's probably smaller than modern
standards (could
possibly be followed with real-time tracking), it probably uses a
manually-entered seed to
generate a hop sequence, the PRNG that stretches the seed is probably
not secure any
more, and the input space is probably searchable by now in a
reasonable amount of time.

Further, once broken with some expensive hardware (maybe a
custom-designed SIGINT SDR), they could program much cheaper units to
follow the sequence until the Israelis

Just my total guess.
On the Internet noone knows you're a dog - except Bruce Schneier.
Unix guru for rent or hire --
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

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

RE: Exponent 3 damage spreads...

2006-09-22 Thread Anton Stiglic
O.k., thanks to Hal Finney for pointing out to me in a private email that my
modulus wasn't in fact the right size.  I have had some problems with the
openssl key generation (doesn't always seem to generate the exact modulus
size I ask for).  

In attachment, the forged signature opensslB-fake-bin.sig on
messageBunicode.txt which can be validated using the new key I generated
bellow.  I took the same s that I computed beforehand, without reducing it
this time.  The value s is independent of the value of the modulus of the
public key (only dependency is the size)

So here are the instructions, once again (but I bit simplified):

I followed the instructions of Hal Finney's excellent post:

I started out by generating 3072 RSA key pair, with public exponent e = 3.

openssl genrsa -des3 -3 -out my.key 3072
(make sure that the modulus is really 3072 bits, no less no more).

the resulting key can be found at the end of this post, the passwords is
test if you ever want to use it. I also included the public key
certificate by itself.  All in PEM format.

I created a plaintext message messageBunicode.txt on which I want to forge a
signature.  The file can be found in attachment, it is in Unicode because I
wanted to also try this out with a VBscript implementing a signature
function using CAPICOM, in which all plaintext is transformed into UNICODE
(pretty annoying!). 

The hash of this file is

openssl dgst -sha1 messageBunicode.txt
SHA1(messageBunicode.txt)= 5d89b46034e0f41a920b2fa964e230ebb2d040b0

Now, let's create a valid signature over messageBunicode.txt using the
private key, just to see what the output looks like:

openssl dgst -hex -sha1 -sign my.key messageBunicode.txt
Enter pass phrase for my.key:

Now, let's do some bignumber math.
I wanted to look at the value obtained when you verify a signature (RSA
encrypt the signature with exponent 3).  I use BC, a bignumber calculator I
like allot:
A version that can be installed on Windows:

I use a fast modexp function I implemented for BC, available at

You can load it by simply calling bc like this:

bc modgroup.bc

I did all the calculations in hex, so typed the following in bc


Now, denote by sp the signature given above, e = 3 and m is the modulus in
the public key certificate I generated.  When pasting the values into BC,
the hex digits need to be in capital letters.  You can get the value of the
modulus by using an ASN.1 interpreter, such as ASN.1 Editor or Peter
Gutmann's dumpASN1 program.  Here are the BC calculations:


Re: fyi: On-card displays

2006-09-22 Thread Peter Gutmann
Steve Schear [EMAIL PROTECTED] writes:

I have a Mondex card from years ago that used a separate reader with LCD.

Oh, so you were the Mondex user!  I've always wondered who that was.


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

Re: Did Hezbollah use SIGINT against Israel?

2006-09-22 Thread Thomas
  (I regard it as more
  likely that they were doing traffic analysis and direction-finding than
  actually cracking the ciphers.)
 IIUC, spread-spectrum communication is not much stronger than the
 background noise, and thus the traffic analysis is not that easy

We can just speculate here, a practice I dislike, but for fun (hey
today is Friday :) ) I'll add my 2 cent here too.

My first thought while reading this article was: the seed!

One thing I assume is that they did not break a cipher, even if
the radio equipment uses DES with 56-bit keys I doubt they had
broken it and can break it in real-time on the battle field.

All they say is that they can now coordinate their anti-tank forces
better because they know where Israeli tanks will appear on the battle
This can be done with traffic monitoring and some simple math. formulas
to calculate the directions the tanks drive, plus their distance, and
a lower bound of the number of tanks (at least all communicating peers).

But today military radio eq. use frequency hoping based on a PRNG. This
PRNG is the same in every device and needs the same seed to hop to the
right frequency at the right time.

In the last few weeks during the fights the Hezbollah must be able to
capture zillions of messages which all use the same freq. at the same
time. Maybe they did some statistical magic and were able to guess the
seed of the PRNG based on their observations. Or maybe they get access
to a radio device and were able to reverse engineer the PRNG (or just
connect the radio device to a capture device that uses the freq. the
radio device will use). Or maybe it is just the usual war hoax blah blah,
who knows. :)


Freq. hoping should protect against jamming only if I remember
correctly. So if I were able to reproduce the PRNG's seed I would use it
to disable the communication between troops during an attack and don't
just do traffic analysis with it. The same result can be accomplished
by let some guys sit in the trees with a spyglass, a compas, and a CB
radio device. ;)

Have a nice weekend,

fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF

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