Cryptography-Digest Digest #806, Volume #12 Sun, 1 Oct 00 13:13:00 EDT
Contents:
Re: NIST Statistical Test Suite ("Paul Pires")
Re: GSM tracking (Roger Fleming)
Re: Which is better? CRC or Hash? (David Blackman)
Re: NIST Statistical Test Suite (Mok-Kong Shen)
Re: AES annoucement due Monday 2nd October (Mok-Kong Shen)
Question about encryption. ("Melinda Harris")
Re: AES annoucement due Monday 2nd October (John Savard)
Re: Deadline for AES... (John Savard)
Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins .... check
out the developers .... they just want to violate people's freedom of speech rights
... (John Savard)
Re: Choice of public exponent in RSA signatures (Francois Grieu)
Re: GSM tracking (Marc)
Re: Question about encryption. (Serge Paccalin)
Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins .... check
out the developers .... they just want to violate people's freedom of speech rights
... (John Savard)
Re: Is RC4 a serious cipher? ("CMan")
----------------------------------------------------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Statistical Test Suite
Date: Sun, 1 Oct 2000 00:43:42 -0700
Benjamin Goldberg <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Pires wrote:
> [snip]
> > I hope I am not mis-understanding you. The test suite lists efrc
> > (in the glossary up front) as:
> >
> > "Complementary error function. See efrc"
> > "...is related to the normal edf."
>
> Hmm... "You are such a wonderful, stupendous person, I hate telling you
> there's an error, but..." That kind of complimentary?
Ok, what's the normal edf? Error distribution factor?
"Ya wanna spread those stupendous goofs around
or ya gonna hog em all like normal?"
>
> --
> ... perfection has been reached not when there is nothing left to
> add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: GSM tracking
Date: Sun, 01 Oct 2000 07:53:36 GMT
Very interesting discussion about CDMA phones, guys, if not strictly speaking
crypto. Just to add .02 about the original thread: I have a GSM phone, and its
behaviour is as follows:
If I move into a signal shadow, the phone displays:
No network. Search networks?
Whilst in the shadow area, any amount of pressing "Yes" causes it to spend
about 6s going "bip bip", then displaying the same screen again.
When you get out of the shadow area, getting it to search networks causes it
to take about 6s, then display a list of networks it found, with a # next to
the one you were last connected to; you select this one by just pressing
"Yes". It then takes about 20s to receive any SMS messages sent while you were
in the shadow.
On the other hand, if you power the phone off (with or without removing the
battery), upon being powered on (after asking for the SIM password) it does
_exactly the same thing_ except that it automatically selects the previous
network, if it found that one to still be available; it takes the same length
of time too, ie 6s. (By experiment with swapping cards, I find that info on
last network used lives in the SIM card flash, along with the password, phone
number, and user prefs).
Furthermore, on standby mode the battery lasts about 5 days; with the phone
off (but battery connected) I have found the battery still fully charged after
two months.
All this leads me to believe that when I turn off my GSM phone, it really is
one hundred percent off and capable of neither transmission nor reception.
ObCrypto (well, closer than the rest of the thread. Let's call it ObSIGINT):
It was suggested that CDMA phones do not easily reveal their distance from the
base station, due to automatic power level adjustment. I suspect this is
untrue. I have no idea if individual companies can actually access the
information through an unmodified base station, but in order to synchronise
the spreading signals one or both ends must track the time difference between
transmitted and received chips caused by time-of-flight. Now I am no expert on
CDMA, but IIRC in the IS-95A specs this is done by both ends, with forward and
reverse ends having different chip rates. The reverse (mobile to base) channel
has a chip rate of 1.2288 MHz, giving a spacial resolution of about 250m,
(with a repeat distance considerably larger than a cell). Good enough for
government work.
Furthermore a system called "Rake fingers" enables the station to receive and
recorrelate time staggered, multipath signals. This provides enough
information to, in principle, localise the transmitter from _one_ receiver.
All I need to know is the location of the two strongest reflectors in my
cell, and do a little trig with the direct, and two other, times of flight. I
doubt that any base stations are actually able to provide such a service
automatically, though.
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: Which is better? CRC or Hash?
Date: Sun, 01 Oct 2000 19:31:21 +1100
Tiemo Ehlers wrote:
>
> I want to be able to notice any changes, no matter if done by evil forces or
> just by coincidence.
> And it should be infeasable to generate a file with a different content but
> the same digest number.
> I think real one way hash functions would do that job.
Yes. That's one of the things they were invented for.
> But CRC is easier to computer. How likely is it to generate a file with a
> different content and the same CRC value as before?
> I don't have a clue. How can I find out?
Very unlikely to happen by chance, or by accident. Very likely to happen
if an evil person who knows their stuff is involved.
Best to use a good crypto hash then. And make sure that evil people
can't modify the hash. Or the program that checks that the hash is ok.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: NIST Statistical Test Suite
Date: Sun, 01 Oct 2000 10:47:11 +0200
bubba wrote:
>
> I built it last night using Microsoft VC6.0 for x86.
> I had to dummy out erfc() and erf(), as those are
> not standard in the PC world. I wish they would
> have release PC compatible source, more than
> a few of use those nowadays.
These are two well-known statistical functions. Could
you check once again whether they are present somewhere
in the header files of the compiler distribution?
I suppose it would be fine if someone also tries on a C++
compiler and see what it comes out.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AES annoucement due Monday 2nd October
Date: Sun, 01 Oct 2000 10:47:03 +0200
"Douglas A. Gwyn" wrote:
>
> Brian Gladman wrote:
> > Nevertheless, I will be rather surprised if multiple winners are adopted.
>
> If they select multiple algorithms, then they have lost sight of the
> original goal, which was to standardize a single sufficiently good
> encryption algorithm to replace DES. The only commercial
> consideration should be how well the algorithm supports commercial
> requirements for a standard block cipher algorithm.
I suppose 'commercial consideration' means desires from
the manufacturers. These certainly prefer a single algorithm
instead of more (less work vs. more work). In my view
NIST should mainly take side of the users and not be much
influenced by the manufacturers.
M. K. Shen
------------------------------
From: "Melinda Harris" <[EMAIL PROTECTED]>
Subject: Question about encryption.
Date: Sun, 01 Oct 2000 12:06:12 GMT
We are still trying to find out who is responsible for ANEC encryption. Any
one out there have a clue?.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: AES annoucement due Monday 2nd October
Date: Sun, 01 Oct 2000 12:47:55 GMT
On Sat, 30 Sep 2000 21:09:02 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>Brian Gladman wrote:
>> Nevertheless, I will be rather surprised if multiple winners are adopted.
>If they select multiple algorithms, then they have lost sight of the
>original goal, which was to standardize a single sufficiently good
>encryption algorithm to replace DES. The only commercial
>consideration should be how well the algorithm supports commercial
>requirements for a standard block cipher algorithm.
As I recall, the original goal, as with DES, was to obtain a means by
which to secure the sensitve but unclassified communications of the
U.S. Government.
If all five finalists meet that goal, for NIST to state that Federal
agencies will be AES-compliant if they use any of those five
algorithms they like, the goal will still be met.
I however agree that so doing is not a good idea, but I think the
reason has more to do with unfairness to the submitters, who submitted
based on a perception or a promise of the possibility of recognition
as "the" standard. Naturally, there is also the loss of the benefit of
interoperability to the community at large (to whom, except for the
large segment of that community who are U.S. taxpayers, NIST doesn't
really "owe" anything, it may be argued), but a single AES algorithm
does not by itself guarantee interoperability anyways.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Deadline for AES...
Date: Sun, 01 Oct 2000 12:54:55 GMT
On Fri, 29 Sep 2000 19:57:33 -0700, "Scott Fluhrer"
<[EMAIL PROTECTED]> wrote, in part:
>Well, since NIST is making up the rules, I suppose they could do anything
>they feel like. In principle, they could go and announce that FROG is the
>winner after all...
Well, at least if the winner was already picked on Friday, September
29, 2000, they can't have decided to pick Quadibloc VIII A1 R as the
winner after all, since I've only *now* gotten around to fixing the
Quadibloc VIII key schedule, and defining that variant.
Since, no matter which algorithm is chosen, there are bound to be
people who will not be happy with it, now there is an alternative!
Of course, :) .
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins
.... check out the developers .... they just want to violate people's freedom of
speech rights ...
Date: Sun, 01 Oct 2000 13:00:18 GMT
On Sat, 30 Sep 2000 14:49:27 GMT, Markku J. Saarelainen
<[EMAIL PROTECTED]> posted his .sig.
Actually, if you will recall, it was announced that the NSA examined
all five finalists, and the announcement said something like:
"the NSA has no objection to any of the five finalists on the grounds
of security"
which, like the State Department's "disposed to discredit" comment
about Yardley quoted in David Kahn's _The Codebreakers_ (which
literally meant we'd rather people didn't believe it, without actually
saying, wrongly, that it wasn't true) is ambiguous, as it could, I
suppose, just as easily mean "we can break all of them" as "all five
are secure enough for their intended purpose", the meaning we are
intended to take.
Thus, the paranoid are allowed to remain paranoid without having to
believe that the NSA can fib.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Sun, 01 Oct 2000 15:50:58 +0200
So far, my question:
Why choose e = 2^16+1 rather than e = 3 in RSA signatures
when using a proper formatting scheme, such as ISO 9796-2
got the following answers; more are welcome !
Ref[1] recommends against low RSA exponents, stating:
"There is evidence that the equivalence (..of factoring and
RSA..) does not hold if the (..public exponent is small..).
Based on recent results in this area the public exponent for
RSA must be sufficiently large. Once popular values such as
3 and 17 can no longer be recommended, but commonly used
values such as 2^16+1 = 65537 still seem to be fine. If one
prefers to stay on the safe side one may select an odd 32-bit
or 64-bit public exponent at random."
Ref[2] makes a theoretical advance in the direction of proving
that the RSA problem with small (more precisely smooth) public
exponent might not be as difficult as factoring, but gives no
clue on how to solve either problem.
Ref[3] gives a chosen-messages attack against ISO 9796-2
signatures that is made harder when choosing a higher public
exponent e; however the time and space complexity grows very
slowly with e so other protection techniques are advisable,
such as widening the portion of the formatted message that
the attacker can't possibly choose, or using a padding
format with provable security.
Some say that 2^16+1 is fast enough; to this I answer that in
a Point Of Sales Terminal using an 8 bit processor and checking
a 1024 bits signature, 1.3s may be far more acceptable than 11s.
Francois Grieu
PS: I miss sci.crypt.research badly; when will it be fixed ?
[1] Arjen Lenstra, Eric Verheul: Selecting Cryptographic Key Sizes
<ftp://ftp.sunet.se/pub/security/docs/crypt/cryptosizes.pdf>
Thanks to Pierre Vandevenne for pointing the paper.
[2] Dan Boneh, Ramarathnam Venkatesan: Breaking RSA May Be
Easier Than Factoring
<http://crypto.stanford.edu/~dabo/papers/no_rsa_red.pdf>
Thanks to Roger Schlafly for pointing the paper.
[3] Jean-Sebastien Coron, David Naccache, Julien P. Stern:
On the Security of RSA Padding, Advances in Cryptology
CRYPTO '99; for sale at
<http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-66347-9>
------------------------------
From: [EMAIL PROTECTED] (Marc)
Subject: Re: GSM tracking
Date: 1 Oct 2000 14:10:26 GMT
>All this leads me to believe that when I turn off my GSM phone, it
>really is one hundred percent off and capable of neither transmission
>nor reception.
Usually yes. Some phones provide the ability to set an alarm time
and turn themselves on when the alarm triggers. The phone then usually
searches a network for emergency calls but does not activate the SIM
(you haven't supplied your PIN anyway). The network is entered as
guest, like a phone w/o SIM.
It is possible, though no case is known to me where it actually was
done, to modify a phone in a way that it waits in the off-state for
a certain trigger (eg a date+time) - possibly remote-programmed via
SMS - and then wakes up clandestino without any LCD activity. It
could book on the network and announce your position, or transmit
an audio grabation (maybe taken at a previous time and stored until
now), etc.
This does not involve hardware changes at your phone, but definately
an excessive firmware modification and is (not impossible but) veeerry
difficult to achive for anyone except the manufacturer himself who
has the source codes.
>receiver. All I need to know is the location of the two strongest
>reflectors in my cell, and do a little trig with the direct, and two
>other, times of flight. I doubt that any base stations are actually able
>to provide such a service automatically, though.
This is being done already, although not to a great detail. In crowded
areas such as city centers, sometimes a cell is split into sectors.
The 360 degree circle is for example split into 3 120 degree sectors,
with their own frequency resources. The sectoring can be and is done
at times by the methods you described in your posting.
It is not "tracking the exact position of a mobile" but it is implemented
and can be used when perceived necessary.
------------------------------
From: Serge Paccalin <[EMAIL PROTECTED]>
Subject: Re: Question about encryption.
Date: Sun, 1 Oct 2000 16:32:53 +0200
On/le Sun, 01 Oct 2000 12:06:12 GMT,
Melinda Harris <[EMAIL PROTECTED]>
wrote in/a écrit dans sci.crypt...
> We are still trying to find out who is responsible for ANEC encryption. Any
> one out there have a clue?.
>
According to:
http://www.metrowestnews.com/guestbooks/north.html
Mon Aug 7 12:21:28 2000
David Matthias Schiesl ([EMAIL PROTECTED])
"I am a freelance cryptographer, inventor of the strong
encryption program called ANEC. Looking for book,journals
and magazine on the subject of cryptograhy."
Melinda, do you think you can find that asshole now? I guess
you can work out the typo in "his" email address...
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypothèse la plus élaborée ne saurait remplacer
_/___(_) la réalité la plus bancale. -- San-Antonio (1921-
2000)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The algorithm that can be broken by the U.S. mil and NSA/CIA/FBI wins
.... check out the developers .... they just want to violate people's freedom of
speech rights ...
Date: Sun, 01 Oct 2000 15:57:55 GMT
On Sun, 01 Oct 2000 13:00:18 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>it could, I
>suppose, just as easily mean "we can break all of them" as "all five
>are secure enough for their intended purpose", the meaning we are
>intended to take.
It should be noted, however, that I don't believe that _this_
ambiguity was really intended by the NSA. Instead, I am inclined to
trust that the *intended* meaning is true, but the ambiguity is an
inadvertent consequence of releasing the statement in a guarded form.
Clearly, a statement like:
"Algorithm V is satisfactory as a Type 1 algorithm; algorithms W, X,
and Y are secure enough for Type 3, but algorithm Y could be made Type
2 with just this little tweak..., and we were able to determine that
algorithm Z is at least secure enough for type 3; it may be more
secure, but we weren't able to fully analyze it in a reasonable amount
of time..."
would presumably have disclosed (or at least hinted at) loads of
highly classified information, which is why a statement was issued
that was worded to reveal as little as possible.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "CMan" <[EMAIL PROTECTED]>
Subject: Re: Is RC4 a serious cipher?
Date: Sun, 1 Oct 2000 09:48:59 -0700
Right, if you assume a perfectly secure computer. On almost any real world
computer, the possibilities are limitless. Trust nothing. Even this article.
They are all in cahoots...
:--)
JK
--
CRAK Software
http://www.crak.com
Password Recovery Software
QuickBooks, Quicken, Access...More
Spam bait (credit E. Needham):
root@localhost
postmaster@localhost
admin@localhost
abuse@localhost
webmaster@localhost
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
"Guy Macon" <[EMAIL PROTECTED]> wrote in message
news:8r3n83$[EMAIL PROTECTED]...
>
> Another advantage is that you can be pretty sure that your RC4
> implementation does not have back doors or implementation errors
> in it. If you examine the source and see nothing funny, and the
> result properly encodes and decodes the test cases, it's hard to'
> see where a back door could be hidden.
>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
