Cryptography-Digest Digest #796, Volume #10 Mon, 27 Dec 99 07:13:01 EST
Contents:
Re: More idiot "security problems" (Terry Ritter)
Re: Disbelief about Numbers Stations (David Bernier)
Re: Synchronised random number generation for one-time pads ("Joseph Ashwood")
Re: MARS ("Joseph Ashwood")
Re: More idiot "security problems" (John Savard)
Re: Are PGP primes truly verifiable? (David A Molnar)
Re: Disbelief about Numbers Stations (NFN NMI L.)
Re: Adobe Acrobat File Encryption...AAARGH!! (Doctor M)
Trying to find a soft copy of Simon Singhs puzzles ("John Lupton")
Re: ToySaber: a dehanced CipherSaber. (Guy Macon)
Re: Synchronised random number generation for one-time pads (Guy Macon)
Re: ToySaber: a dehanced CipherSaber. (Jim Gillogly)
Re: ToySaber: a dehanced CipherSaber. (Guy Macon)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: More idiot "security problems"
Date: Mon, 27 Dec 1999 03:45:33 GMT
On Sun, 26 Dec 1999 02:55:04 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (John Savard) wrote:
>On Sat, 25 Dec 1999 12:15:24 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>>Just to keep things honest, I would say the real situation is even
>>more general:
>
>>*Any* *group* can create an encryption algorithm that no-one in the
>>group can break.
>
>>Here "group" includes individuals, academics, AES participants, etc.
>
>Come to think of it, that is a consequence of the law to which you
>replied: at least the smartest guy in the group, when creating a
>cipher he cannot break, will have created one the rest of the group
>can't break.
Yes.
>However, it doesn't automatically follow that those who are not
>members of the "best" group (NSA employees) must give up all hope.
There may well be groups which each can produce ciphers the other
cannot break. Being "best" doesn't mean that everything lesser is
known.
>But
>if what you mean is that it is very hard to tell...well, that is quite
>correct.
Not quite: What I mean is that -- absent mathematical proof -- it is
*impossible* to know whether our unknown opponents will be as confused
as we might hope they would be. And there is no such mathematical
proof.
>It is hard to tell, so I think that for serious use, even the
>best-respected academic designs should be "padded" with things like
>extra rounds to be on the safe side (where resources permit, as Bruce
>Schneier has often pointed out, they do not always do so).
Then perhaps he also will have pointed out that -- in general --
individuals have plenty of cycles to spare, and this is the ideal
situation for end-to-end cryptography.
It is the servers which are cycle-limited, and if encryption does not
expand message size much, servers will not be affected much, unless
they also cipher.
I think one of the worst things we can do in cryptography is to
pre-judge the capabilities of our opponents, and then build a
mechanism which we think to be only somewhat stronger than that,
perhaps because "we cannot afford to do more."
>But I have to admit that is just a personal opinion on my part; since,
>in the nature of things, substantive evidence one way _or the other_
>is hard to come by.
For example, the idea that AES will be strong enough, and my statement
that we can never know, are *not* equally reasonable ideas.
That we can never know is an obvious fact, and is logically provable
if we assume that we can never hope to know either all of our
opponents or all of their capabilities. No "evidence" for this is
needed.
In contrast, the idea that a bunch of guys can get together and make a
cipher that nobody else can break is just a claim, no more than that.
For this sort of claim, evidence is needed, but of course cannot be
obtained. In the end, it is just yet another insupportable claim.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: David Bernier <[EMAIL PROTECTED]>
Subject: Re: Disbelief about Numbers Stations
Date: Mon, 27 Dec 1999 04:46:38 GMT
In article <846a5a$534$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I find it hard to believe that no one has ever attempted to track
these
> things down. It's as if no one knows anything about them! If they
are
> Morse or voice, surely some sort of DF (direction finding) should be
> possible to pin them down.
>
> Can anyone tell me if the stations move constantly, if the same voice
> or hand is recognizable, what power level they appear to be using,
what
> cities they appear to be in, etc. Even as an amateur effort, I'm
> surprised that people haven't ganged up on them to do some sort of
DF...
>
> Curiously Yours...
A good Internet reference seems to be:
http://www.blackcatsystems.com/numbers/numberTypes.html
I once heard and recorded such a numbers station broadcast.
I can attest that everything the above site says about the
English language "Counting station" format, as well as the *.wav
file for this type, is in agreement with my audio recording.
Curiouserly Yours,
David Bernier
--
links of mathematical interest:
http://www.deja.com/~mathworld/
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Synchronised random number generation for one-time pads
Date: Sun, 26 Dec 1999 21:31:28 -0800
> I think that we all agree that OTP plus (some other method) has
> different attributes than OTP alone. This could indeed be useful;
> OTP cannot be broken with cryptanalysis, so using another method
> that is resistant to plaintext attacks but not to cryptanalysis
> then feeding the result to your OTP would seem to be a good idea.
>
> It's important to talk about the weaknesses and strengths of
> various encoding methods as they stand without jumping into
> quick fixes. You need a good understanding of the basic scheme
> before you can be confident that your proposed fix actually
> addresses the weakness.
While I certainly can't argue with your statements, I think you
misinterpretted what I meant. What I meant is that typically in a OTP is
something like
x[...] = random data
m[...] = input
d[...] = output
for(i = 0 to length of data)
d[i] = m[i] XOR x[i]
What I propose is that instead we use a function like
x[...] = random data
m[...] = input
d[...] = output
for(i = 0 to length of data)
d[i] = DES(m[i], x[i])
It was this that I used to make the judgement of that it is not subject to
any reasonable attack that I am aware of. It also has the improved security
of having a 1/(2^56) chance of a correct guess of a subpassword, and a
resistance to known-plaintext attacks as well (ie they still require
significant resources for to determine the key for each block), the flipside
is that DES takes significantly longer to compute than XOR. I see where this
could be of use in a stream cipher, and could potentially obscure minor
issues with the pRNG.
Joseph
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: MARS
Date: Sun, 26 Dec 1999 21:45:02 -0800
I realize that it's structly a political reasoning for a preference, but
anyway.
I see MARS or RC6 as the two most likely winners (perhaps even both). As has
been pointed out it is likely that all the candidates are approximately as
secure (although the MARS key schedule has been replaced so that may become
a question as to security). The primary reason for choosing MARS or RC6 is
that they are the ones that are not already free, this makes chosing any of
the others a self-defeating idea for me.
Personally I support RC6 and Twofish as the most likely strong methods,
Twofish has been subjected to some of the most grueling tests that I can
imagine, and RC6 is simply an extension of a method with a proven track
record. the others I haven't seen nearly as much discussion about, and until
recently (when I quit my job) I didn't have time to review the candidates
fully, once I do, if I come up with anything of import you can be assured
that I will inform everyone.
Joseph
"Ken Lamquist" <[EMAIL PROTECTED]> wrote in message
news:83rcv7$r1n$[EMAIL PROTECTED]...
> Volker Hetzer <[EMAIL PROTECTED]> wrote:
> > "William W. Joslin" wrote:
> >> Can anyone tell me more about MARS algorithm... I know that it is a
> >> finalist as an AES, but, tell me more about it...
> > You mean, something that isn't covered in the spec?
> > Well, personally I believe (in my VERY humble opinion) that it's the
> > most likely winner. Mainly for political reasons. However that is
> > pure speculation.
>
> My speculation is that it is one of the less likely winners. RC6,
> Rijindael, and Twofish appear to be a bit faster than MARS on general
> purpose computers which have good support for integer multiplication
> and 32 bit rotates. The performance relative performance of MARS
> suffers on machines where these operations are slow. The modified
> key schedule decreases the RAM requirements for implementations on low
> end smart cards, but the algorithm still requires relatively large ROM
> tables.
>
> The NSA was originally scheduled to release its analysis of hardware
> implementations six months after the start of round two. Does anyone
> know if that is still the schedule? My expectation is that MARS is
> not particularly well suited to hardware implementation. It uses
> multiplication, and fast multiplication takes a lot of silicon. It
> has four different types of rounds, which operate at three different
> speeds, making pipelined implementations awkward.
>
> All of the AES finalists are secure as far a we know, but NIST notes
> that the complexity of MARS "makes analysis difficult in a restricted
> timeframe." Thus if no security flaws are found in any of the candidates
> during round two, MARS is likely to be considered to be slightly less
> trusted than the other candidates. (Complexity is also an issue for
> Twofish, but less so than for MARS.)
>
> MARS offers considerable flexibility in the choice of key lengths,
> which is nice but not likely to be a major factor in the competition.
>
> I'm not sure about the politics. IBM is a valuable brand name, but
> the submitters of the other finalists are at least as well known among
> people who use cryptography. Three of the finalists have been placed
> in the public domain, meaning that people are considering using them
> in applications now.
>
> My speculation is that the most likely winners are Twofish, Rijindael,
> and RC6, in that order. If only one winner is selected, I don't think
> it will be Serpent because Serpent is slow on general purpose computers.
> NIST might select Serpent as a second winner due to its suitability for
> hardware implementation.
> Kenneth Almquist
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: More idiot "security problems"
Date: Mon, 27 Dec 1999 06:02:49 GMT
On Mon, 27 Dec 1999 03:45:33 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>In contrast, the idea that a bunch of guys can get together and make a
>cipher that nobody else can break is just a claim, no more than that.
>For this sort of claim, evidence is needed, but of course cannot be
>obtained. In the end, it is just yet another insupportable claim.
I cannot disagree with the facts you are stating.
The trouble is, though, if I were to claim that the ciphers in the AES
were really breakable, that would also be insupportable. Hence, in
this situation of ignorance, what sort of response should be taken to
the fact that we don't know our ciphers to be secure? How seriously do
we take the possibility that they are not, since we have no proof of
how real that possibility is, either?
It comes down to a very subjective judgement, which depends on an
individual's personality and emotions. Given that, I cannot argue
forcefully for stronger ciphers; I gently point out possible
opportunities to achieve greater strength at a limited cost in cycles,
but it seems pointless to do more.
Also, since *most* cryptography users seem to be, at present,
primarily concerned about attacks by criminals within a limited time
frame, I think it is reasonable to view that class of adversary as
having capabilities inferior to the academic community. The trouble
is, though, things get declassified by the NSA eventually, and
computers keep getting faster - so, unlike credit card transactions,
medical records, say, should be protected by something stronger.
But using "something stronger" means using something nonstandard -
triple DES, or the AES when it comes along, satisfies the insurance
companies and the lawyers. Overcoming _that_ kind of problem is a task
of enormous proportions. (And, of course, the book 'Decrypted Secrets'
brought up another point: it is possible, if certain kinds of care are
not taken, to make a cipher weaker by adding what appear to be
complications.)
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Are PGP primes truly verifiable?
Date: 27 Dec 1999 06:32:59 GMT
In sci.crypt Paul Crowley <[EMAIL PROTECTED]> wrote:
> David A Molnar <[EMAIL PROTECTED]> writes:
>> I know that there exist algorithms which will tell you with 100% certainty
>> whether a number is prime, and run in poly time, but don't know enogh
>> to go into detail on this point. :-(
> ISTR hearing that those algorithms rely on the Generalised Riemann
> Hypothesis, which is unproven. There may now be algorithms that don't
> rely on it though.
Yes, that's what I've heard as well -- but I think the hypothesis is
required for proving that the algorithm will terminate. If the hypothesis
is not correct, then I think there is a chance of the algorithm running
much longer than expected, but still possibly coming up with the correct
answer.
At this point, however, I have to go borrow a copy of Bach & Shallit
_Algorithmic Number Theory : vol 1_ and/or find the relevant
papers. Because the above is a hazy memory of what I've read. The fact
that I'm not near a nice library may be the only bad thing about Christmas
break. :-)
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L.)
Subject: Re: Disbelief about Numbers Stations
Date: 27 Dec 1999 07:26:35 GMT
sci.crypters may be interested in this page:
http://www.ibmpcug.co.uk/~irdial/crackhome.htm
Hay, kewl.
S. "13747 66600" L.
------------------------------
From: [EMAIL PROTECTED] (Doctor M)
Subject: Re: Adobe Acrobat File Encryption...AAARGH!!
Reply-To: [EMAIL PROTECTED]
Date: Sun, 26 Dec 1999 21:37:57 GMT
I know that there are several programs on the net that can crack it.
On Sun, 26 Dec 1999 13:09:42 -0000, "Piff" <[EMAIL PROTECTED]> wrote:
>Hi There
>
>I've spent the last two weeks trying to find more information on the
>encryption method used by Adobe Acrobat but can't seem to find anything.
>
>Do they use a algorithm created by themselves or a standard method like XOR?
>I assume that as they can export the software it's restricted but other than
>that I have no idea...
>
>Could one of you kind peeps give me an idea where to look as I'm down to my
>last patch of hair!!
>
>Thanks
>
>Piff
>
>
------------------------------
From: "John Lupton" <[EMAIL PROTECTED]>
Subject: Trying to find a soft copy of Simon Singhs puzzles
Date: Mon, 27 Dec 1999 10:27:58 -0000
Is there anywhere I can get a soft copy of the ciphertexts for "The Code
Book" Cipher challenge.
Bit slow typing them in and can't get to a scanner for a few days.
Thanks in advance,
John
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: ToySaber: a dehanced CipherSaber.
Date: 27 Dec 1999 05:46:04 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jim Gillogly) wrote:
>
>Under the export regs du jour it's not clear that 40 bits will
>have any special consideration. Of course all crypto being
>exported, including Caesar ciphers, needs an export license
>according to the BXA regs -- it's just that some is easier to
>get than others.
I need to get an export license for ROT13?? Quick, someone who is
reading this from outside the US, please give me your email address
and I will violate the law by sending you source code for ROT13
encryption. (I am not doubting you on this - I am mocking any
goverment this stupid).
>The actual security on ToySaber is less than 40 bits. Michael
>Johnson suggested this variant shortly after RC4 was exposed,
>and I did an overnight hillclimbing attack on it that was closer
>to 28 bits on a laptop, based on recovering the state array given
>a small amount of known plaintext.
Does anyone have details on Michael's program, such as how big
the IV was?
I cannot find "hillclimbing attack" anywhere on the web. What is it?
It occurs to me that ToySaber would also be a nice start to writing
toy versions of dictionary attacks, brute force attacks, man in the
middle attacks, etc. Could be educational...
After I posted about it it occured to me that I would end up with
an array of nybbles to XOR with the plaintext, not bytes. I could
do the old high nybble/low nybble trick, but I think that I will
write a Hexadecimal to ASCII / ASCII to Hexadecimal routine instead
and keep the toy program nybble based throughout.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Synchronised random number generation for one-time pads
Date: 27 Dec 1999 05:59:55 EST
In article <ejOJO2CU$GA.280@cpmsnbbsa03>, [EMAIL PROTECTED] (Joseph Ashwood) wrote:
>While I certainly can't argue with your statements, I think you
>misinterpretted what I meant. What I meant is that typically in a OTP is
>something like
>x[...] = random data
>m[...] = input
>d[...] = output
>for(i = 0 to length of data)
> d[i] = m[i] XOR x[i]
>
>What I propose is that instead we use a function like
>x[...] = random data
>m[...] = input
>d[...] = output
>for(i = 0 to length of data)
> d[i] = DES(m[i], x[i])
>
>It was this that I used to make the judgement of that it is not subject to
>any reasonable attack that I am aware of. It also has the improved security
>of having a 1/(2^56) chance of a correct guess of a subpassword, and a
>resistance to known-plaintext attacks as well (ie they still require
>significant resources for to determine the key for each block), the flipside
>is that DES takes significantly longer to compute than XOR. I see where this
>could be of use in a stream cipher, and could potentially obscure minor
>issues with the pRNG.
I know that a fundamental property of XOR is that XORing anything
to a true random (if such exists) message cannot reduce the randomness.
is this also a known property of the way you are using DES? I sure can
see the advantages iof it is.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: ToySaber: a dehanced CipherSaber.
Date: Mon, 27 Dec 1999 11:32:57 +0000
Guy Macon wrote:
> I need to get an export license for ROT13?? Quick, someone who is
> reading this from outside the US, please give me your email address
> and I will violate the law by sending you source code for ROT13
> encryption. (I am not doubting you on this - I am mocking any
> goverment this stupid).
Realistically you won't get in trouble for exporting ROT13... the point
is merely that the government claims the right to decide how strong a
cipher is, and doesn't leave it up to the exporter.
> I cannot find "hillclimbing attack" anywhere on the web. What is it?
>From a starting point, perturb the state array and test whether
that results in a better fit to the known plaintext. Follow the
gradient to a maximum. If the local maximum isn't good enough, try
a different starting point.
--
Jim Gillogly
Mersday, 5 Afteryule S.R. 2000, 11:29
12.19.6.14.15, 4 Men 3 Kankin, Seventh Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: ToySaber: a dehanced CipherSaber.
Date: 27 Dec 1999 06:42:05 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jim Gillogly) wrote:
>
>Guy Macon wrote:
>> I need to get an export license for ROT13?? Quick, someone who is
>> reading this from outside the US, please give me your email address
>> and I will violate the law by sending you source code for ROT13
>> encryption. (I am not doubting you on this - I am mocking any
>> goverment this stupid).
>
>Realistically you won't get in trouble for exporting ROT13... the point
>is merely that the government claims the right to decide how strong a
>cipher is, and doesn't leave it up to the exporter.
Sigh. what is this world coming to...
I don't suppose those kind folks in Washington DC gave us any hints
as to what parameters they use to decide this, did they? It's
enough to make me think that they don't trust me! ;)
------------------------------
** 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
******************************
