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
internet.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 c/n1W5sl/AyzClfoXunWJSJOHHUhW1DmgUQG8ZC3
 4TpD3sBZLjv0gUHYB2nlyeJ6n8hZV0ZQ0ET1/zHLL

-
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:

http://www.fas.org/man/dod-101/sys/land/sincgars.htm

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
re-keyed.

Just my total guess.
--
On the Internet noone knows you're a dog - except Bruce Schneier.
Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/
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:
http://www.mail-archive.com/cryptography@metzdowd.com/msg06537.html

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:
SHA1(..\messageBunicode.txt)=
bb029c611d34e98188eb23bd1a836ec7305e94fc726577a59c8dab927fb6c5b3fce549be389f
6b15d8608c15a256f4209c7e76ed1186d8382242d53ee36e47b2d8ccb09be0440dcdcb373e37
967cfbe9d38b12a16dc9aa78e20e1303f8033f27b4c679dc215ac56b4bf33edc2c50f73d3da9
424bc072de81674b1905020546a9e57e3f96ceef7932751b94883f0409577ed7c0aa8cbed272
8dabf2a6df334357df2cabf7f5282107b6ec99e2bf0f65cd992a97f2f3e004e35739a368823c
4c0cebe4fdff53a9f039c2d85e57feff81284c7db97823359d9982da23707c8a48923e16e09e
13803cb5da3d87b94d32b5241198d91d490a3d1b343448b528e853d2add80679054e39e2e21c
1096ba66100ea73559c283c4f281fbf82fa292e6bc1dc5df5773affc3ea2425ce95ac779e7d7
90f59d11e3527d5645d9580bbf68909c2a1c4672204859cf46caa247186d917241a79224c9b6
95499644aeea43daefdc5438e9b96952771f1fbc809655ef5a5a5a148ffd47197369f4a85498
3220596a

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:
http://www.gnu.org/software/bc/
A version that can be installed on Windows:
http://gnuwin32.sourceforge.net/packages/bc.htm

I use a fast modexp function I implemented for BC, available at
http://crypto.cs.mcgill.ca/~stiglic/Programming/modgroup.bc

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

obase=16
ibase=16

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:

sp
BB029C611D34E98188EB23BD1A836EC7305E94FC726577A59C8DAB927FB6C5B3FCE5\
49BE389F6B15D8608C15A256F4209C7E76ED1186D8382242D53EE36E47B2D8CCB09B\
E0440DCDCB373E37967CFBE9D38B12A16DC9AA78E20E1303F8033F27B4C679DC215A\
C56B4BF33EDC2C50F73D3DA9424BC072DE81674B1905020546A9E57E3F96CEEF7932\
751B94883F0409577ED7C0AA8CBED2728DABF2A6DF334357DF2CABF7F5282107B6EC\
99E2BF0F65CD992A97F2F3E004E35739A368823C4C0CEBE4FDFF53A9F039C2D85E57\
FEFF81284C7DB97823359D9982DA23707C8A48923E16E09E13803CB5DA3D87B94D32\
B5241198D91D490A3D1B343448B528E853D2ADD80679054E39E2E21C1096BA66100E\
A73559C283C4F281FBF82FA292E6BC1DC5DF5773AFFC3EA2425CE95AC779E7D790F5\
9D11E3527D5645D9580BBF68909C2A1C4672204859CF46CAA247186D917241A79224\
C9B695499644AEEA43DAEFDC5438E9B96952771F1FBC809655EF5A5A5A148FFD4719\
7369F4A854983220596A
m
C68C6FEA9A08822C1DA79D4D975F95BF9EB56A906A66F7B63AF7CFC5B7A43012DDB4\
2779002AFE4109922FA7B98CECDED22CADDBF1B1F116C79E9068D62A3B371318EA1C\
56CA2106F196D0E6E8DE2D95D300935F5942638220073E311EB59FE9E2D7F84E\
F753A415E47E42604175F4B7F1AF52838B0BBA5769120B8DAFA1FFB5C96D961BA1E5\
20717202DE09379F34960F03FE196F0A97704BFE32A5DF0D81445E8DDBAF750B5213\
3EBF07D4859032AE392F161544BE5860579ABA6A6F34395D44754DC24C5C37D90F7F\
017F7225F4EA20D4EADD7BEAFA9025D6D58B49DB151FB6C5C5F2CF6BE9175DCFE96D\
5B752C00D71F032C6E89DEE85514816C50AC70D53A6417B30E93EA640E0E274BE926\
4E94C9D1BE835EE252EB9550AFB7E26DCD3E42407F0797332562C2CA202A5A7C200A\

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.

Peter.

-
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
 either.

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
field.
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. :)

Whatever... 

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,
Thomas






-- 
Tom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF

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