Cryptography-Digest Digest #522, Volume #9 Mon, 10 May 99 06:13:03 EDT
Contents:
Re: DES cracked in hardware? ("Keith Brodie")
Re: DES cracked in hardware? ("Keith Brodie")
HASH and XOR (Neonnate2)
Re: HASH and XOR ("Brian Hetrick")
SCOTT19U available in the FREE world!! (SCOTT19U.ZIP_GUY)
Re: Factoring breakthrough? (wtshaw)
Re: Factoring breakthrough? (David A Molnar)
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: Netscape Encryption Algorithm (Gurripato [x=Nospam])
Re: Scramdisk: Security flaw in VxD? (Shaun)
IP encryption: stream cipher or block cipher? ("Cairus")
Re: Pentium3 serial number is based on who you [server/exterior] claimed to be
(Eric Smith)
DES and SKIPJACK for Microchip PIC microcontrollers (Eric Smith)
----------------------------------------------------------------------------
From: "Keith Brodie" <[EMAIL PROTECTED]>
Subject: Re: DES cracked in hardware?
Date: Mon, 10 May 1999 00:34:22 GMT
You are right, I assumed too much from the name, thanks
--
Keith Brodie KF6QEK
[EMAIL PROTECTED]
Andrew McDonald wrote in message ...
>Keith Brodie <[EMAIL PROTECTED]> wrote:
>> Triple DES has been cracked by networked general purpose processors,
>> see, for example, www.distributed.net.
>
>Distributed.net/EFF didn't crack Triple DES.
>What you are probably confused by is that fact that the last DES
>cracking challenge was 'DES III', ie. the third of the DES Challenges
>set by RSA Labs.
>
>
>Andrew
>--
>Andrew McDonald
>andrew at mcdonald.org.uk
>http://ban.joh.cam.ac.uk/~adm36/
------------------------------
From: "Keith Brodie" <[EMAIL PROTECTED]>
Subject: Re: DES cracked in hardware?
Date: Mon, 10 May 1999 00:50:31 GMT
Well I think that is interesting but unlikely to have been a motiovating
factor in choosing the key size because the use of differential
cryptanalaysis involves so much known plaintext that it could be applied
only in the most favorable circumstances. I think the policy goal would be
to publish a federal standard with a cryptographic algorithm that could be
broken even when used by an adversary who would not provide any known
plaintext, changed keys frequently, etc.
--
Keith Brodie KF6QEK
[EMAIL PROTECTED]
CT Franklin wrote in message <[EMAIL PROTECTED]>...
>Keith Brodie wrote:
>
>> I think you can take it as a given that a DES cracker existed at the
>> time it was introduced, that is why the key length was limited to 56
bits.I
>
>I know people thought this way at one time. But, another hypothesis
suggests
>itself. We now know that DES is susceptible to differential cryptanalysis
>attacks with a complexity of about 2^56 steps. If such attacks (or attacks
>with similar levels of complexity) were known at the time the DES was
adopted
>as a federal standard, dropping the effective key size to 56 bits could
have
>been a form ot truth in labelling. Even a naive analyst can identify an
attack
>on DES with 2.^56 complexity. If NSA at the time knew about the
differential
>attack on DES, it might have been imprudent for them to publish that fact.
>But, shortening the key space sent the same message --- without revealing
any
>thing about methods.
>
>Any thoughts?
>
>Regards
>CT
>
------------------------------
From: [EMAIL PROTECTED] (Neonnate2)
Subject: HASH and XOR
Date: 10 May 1999 01:15:20 GMT
Hello, I am a newbie to strong cryptography. Sure, I've done a few simple
one-key XOR loops in my silly assembler programs. You know the drill...Anyhow,
I've since become intrested in getting started in a strong cryptographical
background. Now, I read, and heard from my friends that are further in crypto
that a fairly strong (not crack-proof, but still strong enough) alogorythm
could be formed by a simple XOR loop, and a strong HASH routine. Well, what I'm
wanting to ask, is does anyone have an example of this in pure Assembler?
QBasic code would be fine, but I understand Assembler a *LOT* better.....it'd
be of much help to me, thanks!!!
p.s: in the meantime, I'll be trying it on my own...if I can find a descent
HASH routine....or learn how to write one.
------------------------------
From: "Brian Hetrick" <[EMAIL PROTECTED]>
Subject: Re: HASH and XOR
Date: Sun, 9 May 1999 21:42:14 -0400
Neonnate2 wrote ...
>Hello, I am a newbie to strong cryptography. Sure, I've done a few
>simple one-key XOR loops in my silly assembler programs. You know the
>drill...Anyhow, I've since become intrested in getting started in a
>strong cryptographical background. Now, I read, and heard from my
>friends that are further in crypto that a fairly strong (not crack-
>proof, but still strong enough) alogorythm could be formed by a
>simple XOR loop, and a strong HASH routine. Well, what I'm wanting
>to ask, is does anyone have an example of this in pure Assembler?
Firstly, a simple XOR against any finite-length fixed string or simple
(e.g., affine) pseudo random number generator (PRNG) is easily broken.
Secondly, a simple XOR against a "cryptographically secure" pseudo
random number generator is called a stream cipher, and it is as secure
as a block cipher. Thirdly, assembler for what machine? Cyber 6000?
IBM 370? Digital VAX? Compaq Alpha? Motorola 680x0? You may want
to learn C, which appears to be the most popular language in crypto
circles.
------------------------------
From: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]>
Subject: SCOTT19U available in the FREE world!!
Date: Mon, 10 May 1999 02:17:33 GMT
Thank YOu James!
I down loaded the scott19u.zip from your site
and it matches the file on my hard drive. So I
hope the people of the FREE WORLD can get a copy.
One thing it is very slow on a 486 33mhz machine
so if it runs to slow you need either a faster
machine or scott16u.zip which is much faster but
the scott19u.zip allows for million + byte keys
the user option.
www.jim.com/jamesd/Kong/scott19u.zip
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
to email me use address on WEB PAGE
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Factoring breakthrough?
Date: Mon, 10 May 1999 00:07:29 -0600
In article <7h3sgu$68n$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (wtshaw) wrote:
> >
> > Waves are analog and particles are digital, so to speak. Either approach
> > at this level is just one view of what cannot be fully described in a
> > unified manner.
>
> I see others approaching the unification. Are you are aware
> of some fundamental law which forbids this unification ?
The operative word is approaching. In several areas of physics, there is
a continuing quest to unify explanations, and it is a good thing. In a
mathematical sense, scientists look for common factors in what seemed to
be disparate approaches.
>
...
>
> Assuming what the NSA publishes is what isn't considered secret,
> with sufficient publication one can infer somethings about what
> it does know, if one already knows what it can know. Picking
> a needle out of a haystack is easy when you understand what
> the needle's properties are or must be that distinguish it from
> the background.
>
> I imagine this statement applies to any ciphertext as well.
> If one knows the constraints of encipherment, one can extract
> a plaintext from the background noise of the ciphertext.
This is the type of thing you should work against in writing algorithms.
Supposedly, the noise can become more prevalent than the message which is
indistinguishable from variations in the noise. Actually, this is quite
easy to do.
>
> > > The physical aspects being relevant to cryptography at the
> > > theoretical level seem to suggest many things on a practical
> > > level which is why I think analog/digital is as important
> > > to crypt as wave/particle is to quantum physics.
> >
> > The new optical inspection breaking routine is surely a combination of
> > analog and digital modes of handling information, but the reality of
> > seeing through feet, much less a few layers of transparencies seems to beg
> > the very usefulness of the suggested technique, laws of optics, including
> > limitations of the behavior of light, being a significant problem to take
> > from desired simple design into the real world.
>
> At the most fundamental level, I see little difference between
> crytography and quantum physics. Since all constaints on
> encryptions are based on the difficulty of analysis the
> problem reduces to a physical and not a mathematical one.
We are working with principles more unified than any of those disciplines
alone. The more you look at even more disciplines, the more that you see
unification in new ways. It is in trying to think that crypto is somewhat
set aside from the rest of science that so many err, and you might get
some unusual insights from rather rather strange quarters.
>
> The mathematics seems to only define a relative and subjective
> magnitude of how hard, while the physics/technology determines
> the absolute magnitude of that hardness.
>
> Perhaps there is some technique that I am unaware of which
> addresses physical complexity as well as mathematical complexity ?
>
I see it all blending together, so trying to speak from a single viewpoint
is likely to be insufficient; knowledge is best used when compounded.
Take the wisecrack: Chaos always wins, it's better organized as a
subjective reaction to inadequate or impossible pondering.
Mere mortals are destined to view reality as a self-serving set of
circumstances, and judge when it seems to be for them or against them as
either reward or punishment dished out by some higher authority. Try not
to put any specific collection of humans too high as faults bedevil us
all. You can only discover what is, and create what is possible, but you
cannot recover what isn't or destroy what is impossible.
--
What's HOT: Honesty, Openness, Truth
What's Not: FUD--fear, uncertainty, doubt
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Factoring breakthrough?
Date: 10 May 1999 07:23:23 GMT
> At the most fundamental level, I see little difference between
> crytography and quantum physics. Since all constaints on
> encryptions are based on the difficulty of analysis the
> problem reduces to a physical and not a mathematical one.
I am a bit sceptical of this, if only because it is true but
unhelpful that everything eventually reduces to physics --
represented today most ably by quantum physics.
It would be nice to be more precise about how exactly to
reduce crypto to QPhys. This is not a challenge, just a
reservation. Frankly I don't yet know enough physics to be
comfortable with that statement...
...and I'm sorry, but I don't understand why the difficulty of
analysis reduces the problem of using cryptography to a physical
problem. It is true that we need to use physical means to perform
computation, classical or quantum. It is also true that we can
calculate how much physical stuff is required to perform an amount
of computation, how much heat is given off, etc. etc. given a
computational model. That's where the brute-force calculations
in Applied Crypto and otherwise come from.
This does not yet, in my mind, encompass or even speak to
"analysis" in the sense of finding the ways to apply that
computation. Are you using "analysis" to refer solely to
the running of the actual algorithm, instead of the
sense of "analysis" which means finding flaws in the
cryptosystem under attack ?\
what am I missing? :-\
> The mathematics seems to only define a relative and subjective
> magnitude of how hard, while the physics/technology determines
> the absolute magnitude of that hardness.
This statement is much more to my liking. Your sentiment here
is a lot like that expressed in a talk by John Preskill (Caltech
prof with excellent course notes and references on quantum
computation) -- when he discusses the impact of quantum comp,
even without practical implementation
"On the theoretical front, it is important to emphasize that the
work of the past few years has already established an enduring
intellectual legacy. A new classification of complexity has been
erected, a classification better founded on the fundamental laws
of physics than traditional complexity theory."
(p.11-12 of http://xxx.lanl.gov/abs/quant-ph/9705032)
Unfortunately I am not personally clear on what exactly he means
by a new classification of complexity, unless he's just talking about
BQP...in which case I thought that most problems involving BQP were
still open (except BQP includes P).
> Perhaps there is some technique that I am unaware of which
> addresses physical complexity as well as mathematical complexity ?
What do
physical "information" and "entropy" refer to ? Do they cover physical
complexity at all? I'm asking an honest question, even though it reads
like I'm baiting. :-)
What would be a good place to look for an explanation of physics
"information" ?
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 04 May 1999 11:28:21 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 03 May 1999 08:14:48 -0400, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>> Would you characterize the process of electromagnetic radiation from
>> just one measurement of the speed of light?
>No, I'd make 20,000 of them.
So now you appear to be saying that each bit in the sequence is a
separate measurement of the random generation process.
This is getting weirder and weirder as time goes along.
> Then you'd complain that the 20,001st
>might be different, and that the speed of light should not depend on a
>single measurement.
Are you trying to put words in my mouth again. Shame on you.
>Go read what you posted!
You go read what you posted, starting with what you just said above.
Bob Knauer
"There is much to be said in favour of modern journalism. By giving us the opinions
of the uneducated, it keeps us in touch with the ignorance of the community."
-- Oscar Wilde
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Tue, 04 May 1999 11:31:14 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 03 May 1999 08:14:59 -0600, "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>It would help if you would inhale.
You have been silent for the most part - why not weigh in and give us
your take of these experts' comments, which I have posted several
times here.
Bob Knauer
"There is much to be said in favour of modern journalism. By giving us the opinions
of the uneducated, it keeps us in touch with the ignorance of the community."
-- Oscar Wilde
------------------------------
From: [EMAIL PROTECTED] (Gurripato [x=Nospam])
Subject: Re: Netscape Encryption Algorithm
Date: Mon, 10 May 1999 08:03:11 GMT
On Fri, 7 May 1999 20:51:15 +0200, "Majestic"
<[EMAIL PROTECTED]> wrote:
>Hi
>
>The recent flaw in Netscape Navigator allows a user to decrypt the password
>stored in the preferences file. I would like to know which encryption
>algorithm is used in Netscape, since that DES is not used.
>
First new I had about it. Can you add some url, please?
------------------------------
From: Shaun <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.misc
Subject: Re: Scramdisk: Security flaw in VxD?
Date: Mon, 10 May 1999 09:51:42 +0100
If you can get a program to run on the system, there are
many ways you could obtain the password or plaintext data (especially
on Win95/98). For instance you could use a keyboard hook, windows
message hook, a torjan, intercept all file I/O (after decryption),
etc, etc.
The point is that the only way to stop this type of attack is
to prevent any unauthorized program from running at all. This
would of course defeat your "sniffer" program, since it wouldn't
be authorised.
Shaun
In article <7h4eao$hlm$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
writes
>While looking at ScramDisk, I came accross what appears to be a significant
>flaw in the way it handles (caches) passwords.
>
>In particular; it is possible to write an application that can interrogate the
>driver for the (plaintext!) passwords it has cached.
>
>Normally, to mount a SVL file, the user performs the following steps:
>
>1) Launch ScramDisk
>2) Enter passwords
>3) Mount the SVL (scrambled) file
>4) Exit ScramDisk (or anything else)
>
>The security flaw occurs between steps 2 and 3: at this time, the password is
>stored in the ScramDisk driver's cache in plaintext, and can be read easily by
>a covert "sniffer" program.
>
>To demonstrate this problem, I've written a short Delphi program that displays
>the passwords entered as a volume is mounted, which is availble (with source)
>from:
>http://www.fortunecity.com/skyscraper/true/882/ScramDiskFlaw.htm
>
>Looking at it, it should be (as the application stands at the moment) fairly
>trivial to write a program to quietly run itsself at startup and monitor the
>passwords to be collected (emailed off?) at a later date.
>
>This flaw is due to GETPASSWORDBUFFER in the VxD, and appears even you
>enter your passwords using the RED screen; defeating the object of using
>this otherwise pretty neat feature.
>
>(This anomoly affects v2.02h, and presumably earlier versions)
>
>--
>Sarah Dean
>http://www.fortunecity.com/skyscraper/true/882/
>
>-----------== Posted via Deja News, The Discussion Network ==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Cairus" <[EMAIL PROTECTED]>
Subject: IP encryption: stream cipher or block cipher?
Date: Mon, 10 May 1999 05:49:52 +0200
Hi.
I want to encrypt the IP protocol and I would like to reinitialise
the key (through an IV) at each IP packet.
I would like to understand if block ciphers fit better than stream
ciphers and why. The fact that IP is a connectionless protocol
seems to be not significant, since a new IV is used for each
packet.
Thank you very much for any answer.
Best regards,
Cairus
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Crossposted-To: alt.security
Subject: Re: Pentium3 serial number is based on who you [server/exterior] claimed
to be
Date: 10 May 1999 01:16:58 -0700
Paul Koning wrote:
> I think a more accurate statement would be "tamper-resistant software
> is non-existent".
>
> The whole concept is utterly nonsensical.
[EMAIL PROTECTED] writes:
> What is the basis for your conclusion?
Software consists of a formal specification of an algorithm. A computer
is not necessary to "execute" the software; for instance, a human can
"play computer" and follow the same instructions. Of course, that may
be tedious and error-prone, but there's no denying that it's possible.
Generally it is possible to use a computer to assist in this process, but
for the sake of argument we'll ignore this possibility.
So if a human can execute the software, don't you imagine that a human
can track down the correct location to make a desired modification (such
as, perhaps, removing a processor serial number check)?
What mechanism could you possibly use to produce software (algorithms) that
are not subject to this type of attack?
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: DES and SKIPJACK for Microchip PIC microcontrollers
Date: 10 May 1999 01:10:48 -0700
Some time back I wrote implementations of the DES and SKIPJACK cryptographic
algorithms for the Microchip PIC microcontrollers, to illustrate some
techniques that I've seen overlooked in some other microcontroller
implementations. Unfortunately I have not had time to document the code in
great detail, but the details should be clear enough to anyone already
familiar with the DES and SKIPJACK standards.
The code is now publicly available under the terms of the FSF
General Public License from my web site:
http://www.brouhaha.com/~eric/pic/
If you have any interest in this, I'd suggest getting a copy while the
getting is good. :-)
Potential commercial users should note that the GPL does not prohibit
commercial use of this code. However, many companies find the GPL's
requirement to distribute source code of anything combined with GPL'd code
to be onerous. If you want to use this code commercially without being
bound to the GPL terms, contact me by email to negotiate a different license.
I'd appreciate feedback from anyone who actually gives this code a try.
Eric
[For email replies, remove the obvious spam-proofing from my address.]
------------------------------
** 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
******************************
