Cryptography-Digest Digest #424, Volume #10 Sun, 17 Oct 99 20:13:04 EDT
Contents:
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Re: Bernstein and letting the court write (or rewrite) laws (Anthony Stephen Szopa)
Re: Testing of randomness (Mok-Kong Shen)
Re: Testing of randomness (Arthur Dardia)
Re: accurate decryption (wtshaw)
Ciphertext Stealing in CBC Mode ("Eric W Braeden")
Re: Testing of randomness (wtshaw)
Re: accurate decryption (Clown's Paw)
newbie: resources needed. (Aslak Johansen)
Re: The Quad. in RC6 (Tom St Denis)
Re: Strengthening passwords against dictionary attacks (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 17 Oct 99 19:33:32 GMT
Terry Ritter ([EMAIL PROTECTED]) wrote:
: On Fri, 15 Oct 1999 19:07:15 GMT, in
: <[EMAIL PROTECTED]>, in sci.crypt
: [EMAIL PROTECTED] (John Savard) wrote:
: >It's obviously wrong if you jump from "no cipher is proven secure" to
: >"all ciphers are equally bad".
: I don't believe that, I doubt I ever said it, and find it hard to
: imagine that anyone could reasonably interpret my words to have that
: meaning.
: >You may rightly protest that you never
: >jumped to that kind of conclusion, but at times you allowed it to
: >appear that this was the basis of your multi-ciphering proposal.
: I "allowed it to appear"? You say I deliberately allowed a
: misconception because it would improve my position? No. Nonsense.
: That did not happen.
I agree. When I said "allowed it to appear", I did not mean that you
_deliberately_ promoted any misconceptions.
It's just that there were flaws in your proposal as it originally
appeared, but that, although you did address those flaws (with multiple
layers of encryption), you still managed to leave the impression that
those measures were less than critical, or that they were an afterthought.
And that impression has led to the other impression: that the whole idea
is based on faulty reasoning.
: This is not about me winning. This is about solving a serious problem
: on the horizon at a time when the solution cost is relatively small.
: If we wait for AES-only to get wired-in, we will have a very serious
: and costly situation indeed.
Be assured that AES-only will get wired in to a number of systems, but
that encryption will also be done elsewhere in software in a multitude of
ways.
: >The "conventional wisdom" in cryptography, as in other fields, did not
: >arise simply by whim or prejudice, but came about as the result of
: >knowledge and experience. That doesn't mean it doesn't have its
: >limitations and omissions - many of which I feel you have correctly
: >located, and are attempting to address.
: >To be "part of the solution", however, one has to be more than a
: >"voice crying in the wilderness". And that involves paying the
: >conventional wisdom its due, and recognizing that due.
: There is no "due." The conventional wisdom *caused* the situation by
: failing to practice the Science they claim to support. Nor are they
: in any hurry to correct their error despite the fact that society will
: actually depend upon this stuff. That hardly deserves respect.
Of course, I do not agree. The specific part of the conventional wisdom at
issue here is the importance of extensive study and testing of any cipher.
As cipher designs have a large "infant mortality", and it gets harder and
harder to find flaws in those ciphers that have survived longer, this
isn't unscientific.
You have pointed out a problem that needs correcting, and a way to correct
it: but that isn't enough. It also has to be made clear that the proposed
method of correcting matters won't make things worse. I think I can see
that this can be avoided, but I also understand why quite a few people are
remaining unconvinced.
John Savard
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,talk.politics.misc
Subject: Re: Bernstein and letting the court write (or rewrite) laws
Date: Sun, 17 Oct 1999 12:52:20 -0700
Reply-To: [EMAIL PROTECTED]
wtshaw wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> (Johnny Bravo) wrote:
>
> > On Fri, 15 Oct 1999 15:56:32 -0700, Sundial Services
> <[EMAIL PROTECTED]>
> > wrote:
> >
> > >I don't mean to start any flame war here, but I guess I do feel that the
> > >place to create law and policy is the Congress and in the Executive
> > >branch, not the Judiciary. It's an age-old problem of course, inherent
> > >in our system of "checks and balances," which system is deliberately
> > >designed that it be so! But cryptography was hardly on the Framer's
> > >minds when they drafted the Amendment.
> >
> > I doubt that television, radio, or the internet was on their minds
> either, do
> > you think that the above mediums do not deserve any protection because
> > they weren't invented in the late 1700s? Many of the current religions
> did not
> > exist then, do they deserve the protection of the first amendment?
>
> Thomas Jefferson, inventor?/adapter? of what is call the Jeffersonian
> Cylinder, known as the Father of American Cryptography, a sometimes
> important scribe on things revolutionary, including our own...
>
> Benjamin Franklin, inventor, statesman, dallier, and our man-about-town
> (Paris), known for secret missions, secret messages, not too secret other
> affairs....
>
> Recall the XYZ Affair...
>
> These men knew nothing of cryptgraphy and its value? You have got to be joking.
> --
> Truth lies in your path for you to stumble over,
> even if you think you can easily sidestep it.
What the founding fathers knew and did not know is significant but may not be
significant to a particular issue.
Cryptography is a privacy issue. The founding fathers knew exactly where they
stood on privacy. They felt it necessary to declare against unlawful search and
seizure.
And the founding fathers knew exactly where they stood on the greater good.
Additionally, the fact that they provided for the prohibition of compelled self
incrimination clearly supports the issue that the People have the right to use
encryption any damn time they feel like it without restriction.
This entire issue of restricting encryption is clearly unconstitutional.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Testing of randomness
Date: Sun, 17 Oct 1999 22:23:11 +0200
Kim G. S. OEyhus wrote:
>
> I have made a random generator, electronic. So far all my tests show
> complete randomness. Do you have some thorough tests to recommend?
> I work in the GB range.
Which tests have you done? Maurer's universal statistical test is
convenient to program.
M. K. Shen
M. K. Shen
------------------------------
From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: Re: Testing of randomness
Date: Sun, 17 Oct 1999 16:16:23 -0400
Dave Scott once mentioned that his suite passed the DIEHARD tests;
however, I'm unaware on how hard that test is to past due to my
unfamiliarity with how it is run. I hope this helps somewhat.
In addition, I'm sure I'm not the only one in this newsgroup who'll
ask this question - how did you do it? Maybe we could construct the
exact device as well (provided it's cost effective) and test the
randomness of it.
"Kim G. S. OEyhus" wrote:
> I have made a random generator, electronic. So far all my tests show
> complete randomness. Do you have some thorough tests to recommend?
> I work in the GB range.
>
> Kim0
--
Arthur Dardia Wayne Hills High School [EMAIL PROTECTED]
PGP 6.5.1 Public Key http://www.webspan.net/~ahdiii/ahdiii.asc
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: accurate decryption
Date: Sun, 17 Oct 1999 15:22:25 -0600
In article <[EMAIL PROTECTED]>, eminor54
<[EMAIL PROTECTED]> wrote:
> This may be slightly off- topic, but I was wondering - how can one
> defend against this scenario - you have a decrypted mesage intercepted
> by someone in authority who wants to accuse you of a crime. They are
> unable to decrypt the message themselves and of course, you dont give
> them the key. However, they then contrive a phony decryption that is
> incriminating, yet you cant prove to anyone that it's a fake without
> revealing the true message. What defenses exist in a case like this? Is
> it possible to show that the fake message is indeed a fake without
> revealing the true text?
>
For that matter, how do you determine that a zealous and dishonest person,
official or otherwise, did not plant evidence, encrypted or not, on your
computer. Furthermore, it seems that someone finding themself a victim of
backdoor abilities means that and evidence gained that way means it might
the possibility now exists that it might have just as well been planted.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: "Eric W Braeden" <[EMAIL PROTECTED]>
Subject: Ciphertext Stealing in CBC Mode
Date: Sun, 17 Oct 1999 16:53:25 -0400
I'm reviewing the idea of Ciphertext Stealing in CBC mode
and having a little trouble with Figure 9.5 page 196 in AC.
Because Bruce didn't explain much in the book, the Figure
just isn't clear to me. I would seem that the last full block
and the final partial block are flipped around. Also what
is the symbol phi supposed to be? Any good discriptions
of Ciphertext Stealing out there?
TIA
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Testing of randomness
Date: Sun, 17 Oct 1999 15:29:37 -0600
In article <7ud83f$bj5$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Kim G. S.
OEyhus) wrote:
> I have made a random generator, electronic. So far all my tests show
> complete randomness. Do you have some thorough tests to recommend?
> I work in the GB range.
>
Good at testing randomness? Is this a random series: 45, 87, 3, 30.
Some additional information about what you did would be helpful, is it
physical or a program for instance.
--
Truth lies in your path for you to stumble over,
even if you think you can easily sidestep it.
------------------------------
From: Clown's Paw <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.misc,talk.politics.drugs,alt.privacy
Subject: Re: accurate decryption
Date: Sun, 17 Oct 1999 14:50:38 -0700
Alternate scenario. You could simply have a third party, read here lawyer,
with whom you could confer. The lawyer, under client privilege, could take
the original message and the fake and compare them. The proof is on the
lawyer, not the client. Through sworn statement the matter could be taken
care of.
A couple of years ago I wrote a triple key encrytion method that renders the
original text as total garbage. The bytes are so twisted up that no readable
form would be possible without the original method. Anyone want a copy?
Nothing comes out looking like words of any sort.
The Clown
Anthony Stephen Szopa wrote:
> eminor54 wrote:
>
> > This may be slightly off- topic, but I was wondering - how can one
> > defend against this scenario - you have a decrypted mesage intercepted
> > by someone in authority who wants to accuse you of a crime. They are
> > unable to decrypt the message themselves and of course, you dont give
> > them the key. However, they then contrive a phony decryption that is
> > incriminating, yet you cant prove to anyone that it's a fake without
> > revealing the true message. What defenses exist in a case like this? Is
> > it possible to show that the fake message is indeed a fake without
> > revealing the true text?
> >
> > Thanks
> >
> > Bill Heiss
>
> You lose.
>
> If they are willing to do this, they are willing to frame you in other
> ways such as planting drugs on you, etc.
>
> They might also simply kill you outright.
>
> Once the "authorities" break the law coming after you or in order to
> get you, I just don't see any logical reason why they should stop at
> anything to accomplish their goal.
>
> In this scenario, you may have no choice but to break the law
> yourself.
>
> But if comes to this you probably have no options except revenge.
>
> Did you hear about the guy in Texas who called 911 and when the
> police arrived he killed three outright and wounded two others before
> being killed himself.
>
> They spotted him with thermal infrared from a helicopter.
>
> Excellent plan on his part except he didn't count on the aerial
> infrared.
>
> There are techniques to evaded and decoy thermal infrared.
------------------------------
From: Aslak Johansen <[EMAIL PROTECTED]>
Subject: newbie: resources needed.
Date: Mon, 18 Oct 1999 02:08:38 +0200
Salut, Mundi
I am a student at a Danish Gymnasium (which I believe equals a
'College of higher education' or a 'Sixth form College'). As a last-year
project (this year) I am going to write about Cryptology, Knapsack, RSA
...
I am now yet sure about the title, but the point is, that I need some
resources (This couldt be books, links, algorithms, White Papers etc.).
Therefore I come to You and ask for help ...
thanks: Aslak Johansen
[EMAIL PROTECTED]
http://www.crosswinds.net/denmark/~cornersite/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Quad. in RC6
Date: Sun, 17 Oct 1999 22:03:12 GMT
In article <7ucv3s$3r6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7u7jin$o3t$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > Ok to sumarize the quad in RC6 is
> >
> > F(x) = x(2x + 1)
> >
> > Which has been shown to be a function (multiplication of any variable
> by a
> > odd number is a function mod 2^w).
> >
> > However have any weaknesses been found? What if you change it to
> >
> > F(x) = x(ax + b)
> >
> > Where (a, b) are round/key dependant integers (a being even and b
> being odd
> > of course)? Would that make it any harder to attack/model? Would it
> still
> > be a function (as shown in RC6)?
>
> I see a couple of problems with this because there will be a limited
> number of possible a's and b's that you can choose. The problem stems
> from the fact that multiplication by powers of two acts as a left shift,
> or right shift depending on endienity. In the case of the original
> quad, x is shifted left by one bit. Now, for every bit we shift, we
> lose a bit. In the case of a one bit shift, we lost the highest bit.
> If we multiply by 256, or shift by 8 bits, we lose 8 bits of
> information. As far as I remember, the quad is primarily used to
> generate 5 bits for the rotates that come next, with some additional
> mixing included. Thus, you want to use as much information from the
> data as possible, so by multiplying by larger values, you lose
> information. Now, I'm not sure of the exact mathematics behind this,
> but the lost information may provide an attacker a means of attack.
>
> As for b, or the odd number, that will probably have to relate to how
> much information is lost by the multiply. Assuming we limit a to a
> maxmimun value of 256, you will have to have at least 8 good odd values
> to obtain the desired effect of the quad. More than likely, you will
> have to predefine these. If an attacker can force certain values for a,
> he or she can then guess b.
>
> Anyway, that's what I came up with as a possibility as to why x(ax+b) is
> bad. If anyone can prove me wrong, or help refine what I said, I'd
> appreciate it.
Actually you had the right idea but your math is messed up. If for example in
f(x) = x(ax + b)
a = even, b = odd then you will have amultiplication of x against an odd.
this is always going to be a permutation mod 2^w. And you talked about a
shift out, but again the multiplication is always odd. So if you had
257x that would be the same as (x << 8) + x. No bits are lost there.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Strengthening passwords against dictionary attacks
Date: Sun, 17 Oct 1999 22:07:24 GMT
In article <7ucue1$3ej$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Strengthening passwords against dictionary attacks
>
> Addressing the problem of dictionary attacks on low entropy passwords in
> October 15, 1999 issue of the Crytpo-Gram, Bruce Schneier states:
>
> "Some have dealt with this problem by requiring stronger and stronger
> passwords, but that is no longer effective. Over the past several
> decades,Moore's law has made it possible to brute-force larger and
> larger entropy keys. At the same time, there is a maximum to the
> entropy that the average computer user (or even the above-average
> computer user) is willing to remember. You can't expect him to memorize
> a 32-character random hexadecimal string, but that's what has to happen
> if he is to memorize a 128-bit key. These two numbers have crossed;
> password crackers can now break anything that you can reasonably expect
> a user to memorize. Good passwords are difficult to memorize, he will
> complain, but this difficulty is precisely why they are considered
> good."
>
> Here is a brief idea to make regular passwords stronger.
The only strong password is the one you don't have to remember. If you have
checked out peekboo you will notice you can engage in secure communications
with many people without any passwords.
> If the amount of salt were dramatically increased, creating an off-line
> dictionary of common passwords would be infeasible. So the first step
> is to increase the salt to 1K bits. Now the password 'weak' can have
> 2^1024 combinations. No effective off-line dictionary could be created.
> The salt is not secret but should be evenly distributed across the
> 2^1024 space.
Why so many bits? You could simply use 32 bits and make dictionary attacks
infeasible.
Basically any login system should work like this
1) Server sends R (random bit string, say 32 bits)
2) Remote sends a = HASH(R + password) and R'
3) Server checks a, and sends b = HASH(R' + password)
4) Remote checks b
Simple as that.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
