Cryptography-Digest Digest #866, Volume #9 Sun, 11 Jul 99 15:13:04 EDT
Contents:
Re: Windows PWL Files ("Andrew Whalan")
Re: How Big is a Byte? (was: New Encryption Product!) (Huge)
Re: New Encryption Product! (humor) (Christopher)
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: Is Stenography legal? ([EMAIL PROTECTED])
Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day ([EMAIL PROTECTED])
Re: Why this simmetric algorithm is not good? ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) (Eric J. Korpela)
Re: How strong would this algorithm be ? ("Daniel Urquhart")
Re: Electronically Exporting crypto source (legally) ([EMAIL PROTECTED])
Re: randomness of powerball, was something about one time pads ([EMAIL PROTECTED])
How hard is it to find the key in DES? (Keith Reeves)
----------------------------------------------------------------------------
From: "Andrew Whalan" <[EMAIL PROTECTED]>
Subject: Re: Windows PWL Files
Date: Mon, 12 Jul 1999 01:12:36 +1000
Thanks for all the comments ... more info
> It's actually RC4, so the guess isn't *that* bad... It's just that
> Microsoft totally botched the implementation in the original Win95, so
> you could extract the password without even touching the encryption!
...
> There were a stand-alone patch for this, then it was included in
> SP1. Win95B and Win98 has the fix from the start. I *think* I remember
> something about Microsoft increasing the strength of the RC4 crypto
> too, from 32! to 128?
Quote from http://webdon.com/vitas/pwl.htm
"Windows uses the professional RC4 ciphering algorithm with a 128-bit key (a
128-bit key is obtained by converting a password with an unlimited length)."
I need code! Anyone help? I don't know where to start looking ...so many bad
links out there!
> After all, the author of the "Glide" did some successful brute force
> attacks first, to find out more about how the PWL files were built,
> before finding out how to attack them without even touching the
> encryption... (Ref: Original posting to Cyberpunks by Frank Stevenson)
Funny, glide never worked for me.
<snip>
Andrew Whalan
------------------------------
From: [EMAIL PROTECTED] (Huge)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 11 Jul 1999 15:16:21 GMT
Reply-To: [EMAIL PROTECTED]
In article <7ma2g1$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Rob Warnock)
writes:
><[EMAIL PROTECTED]> wrote:
>+---------------
>| ...byte was something that could take between 64 and 100 values.
>|
>| Of course, that fellow had been reading the definition of "byte" found in
>| Donald E. Knuth's description of the MIX computer, not realizing that it
>| was not intended as a general definition of the term.
>|
>| However, AFAIK, that is the *only* place the term byte has ever been used
>| to describe anything other than an (ahem) octet...
>+---------------
>
>*BZZZT!!* Wrong-O!! (How quickly they forget...) The DEC PDP-10 had
>hardware support for *variable*-length bytes for any length of byte from
>1 to 36 bits.
ICL machines had six-bit bytes....
--
"The road to Paradise is through Intercourse."
The uk.transport FAQ; http://www.axalotl.demon.co.uk/transport/FAQ.html
[Substitute "axalotl" for "nospam" to email me]
------------------------------
From: [EMAIL PROTECTED] (Christopher)
Crossposted-To: alt.security.pgp
Subject: Re: New Encryption Product! (humor)
Date: Sun, 11 Jul 1999 13:51:02 -0400
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (wtshaw) wrote:
_ It seems that Usenet allows more than that, since the occasional character
_ pops up in my reader that is not in the lower part of the ascii set. And,
_ sometimes lots of boxes appear on my Mac as characters in the set chosen
_ for viewing does not have these codes assigned display values.
_
_ One problem with using 8 bit characters is that the upper ones are in not
_ universal, with possible exceptions(?).
On the Mac the boxes appear when the current font does not have a display
character assigned to that value, yes that seems to happen with the
non-standard set of 8-bit ascii values. Would they show properly as an
html doc?
Now there's a simple cipher, just change the font to symbol in a text
document! No keys to hassle with.
------------------------------
Date: Sat, 10 Jul 1999 13:39:28 -0400
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
[EMAIL PROTECTED] wrote:
>
> In article <7m3k47$t4o$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> > > [EMAIL PROTECTED] wrote:
> > >
> > > > Tom St Denis's code is not a good example.
> > >
> > > You are not perfect and I will prove it.
> >
> > Of course I'm not perfect. I expect to be a
> > better programmer next year than I am today. I
> > jumped on your sloppy and incorrect code because
> > you used it as an example when giving advice on
> > programming.
> >
>
> Then shut the fuck up.
>
> > I re-included your "can be re-written" above, so we
> > can see that
> > y += state[x++];
> > does _not_ have the same effect. You post-increment
> > where RC4 requires a pre-increment.
>
> It matters not when concerning security issues. Although you are
> correct in saying it's not RC4 (although this slight variation is just
> as secure).
>
> > > You can always use an extra '&255' if you are not sure, but that
> makes
> > > the code slightly longer and slower.
> >
> > You are making groundless assumptions. The extra
> > operation is trivial to optimize away. The choice
> > between correct in all cases and faster in some
> > cases is not a close call.
>
> If I put a &255 the compiler CAN NOT optimize it away.
Of course it can. The whole concept of optimization is to find more
efficient sequences of operations that have indistinguishable behaviors
-- identical results.
You badly need to take a compiler course.
It has to be
> done. So tell me how this is faster? I chose to assume char = 8bits
> because the platforms I have access to and the platforms I have used
> (including HPs) use char=8bit.
>
> > So you want to change RC4 to conform to your code?
> > Why did you change the order of the assignments to
> > x and y?
>
> Because I must have made a mistake. It happends you know. Instead of
> jumping on me like the elitist shit head you are, you could have just
> pointed it out as wrong. I am open to suggestions. In fact I will
> update my code to make these reflections (including the &255).
>
> > Your assumptions are groundless. Code first for
> > correctness, then clarity. Profile before you
> > optimize.
>
> Hmm trivial stuff like char=8bit is a simple optimization that I do a
> lot of times....
I know the feeling. I also know that early optimization leads to more
bugs than any other source.
>
> > I suppose you could say it's harder to track than
> > static storage, but both are trivial. Heap is the
> > only tracking challenge.
>
> Hmm? I am talking about local variables such as temps for RSA
> encryption or temps for PRNGs...
>
> >
> > > All you have todo is
> > > memset the round keys when you are done.
> >
> > Irrelevant. Obviously that works for stack, heap
> > or static.
>
> There is no ANSI standard for clearing the stack. And if you tell me
> just do this
>
> func()
> {
> int array[10000];
> memset(array, 0,sizeof(array));
> }
>
> to clear stack that is wrong as well. There is no standard way to
> clear the stack.
>
> > The only reason "most people" would not know is
> > that most people never program in C. Don't project
> > your own misunderstandings onto other C programmers.
> > Stack storage is not in any way harder to clear than
> > heap, and programs are less likely to lose track of
> > it.
>
> Heap is normally easy to track. As long as there is no virtual memory,
> the pointer you hold should be valid (point to real memory). All you
> have todo is memset before you free. Not really hard.
>
> BTW you don't have to be pushy to get changes. I realize that I made a
> mistake with the RC4 in my code and I will change it. But jumping
> on 'it's sloppy' is rather mean. I am trying to do something
> productive for this group (and for myself). It's people like you that
> give a bad name to cryptography in general.
Wrong. Don't argue this, it's an incredibly bad position to defend.
Just recognize that in this context, sci.crypt, everybody cares about
correctness, and a few care about efficiency. And all of those who care
about efficiency at all, care a lot more about correctness.
If you publish slow code people will criticize your code. If you
publish bad code people will criticize you.
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
Date: Sat, 10 Jul 1999 13:29:45 -0400
From: [EMAIL PROTECTED]
Subject: Re: Is Stenography legal?
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>
> > Sorry, but there are over 20,000 guns laws on the US books. Students
> of
> > self defense are now counseled that it is impossible to keep track,
> much
> > less follow all of the silliness passed in the name of "control".
> > PLease check your facts before you assert such incongruous statements.
> >
>
> Look Mr. NRA your gun polish is getting to your head. this is OT so
> drop the subject.
>
> BTW, do you remember why the NRA was started? Didn't think so.
> BTWx2, What is the second admendment?
There's a logical contradiction in your directive to drop an off-topic
issue followed by your two new threads. Until you resolve this conflict
I think you should leave the topic alone.
FYI: I'm not now, nor ever have been, said, or done anything to do with
the NRA.
------------------------------
Date: Sat, 10 Jul 1999 14:22:19 -0400
From: [EMAIL PROTECTED]
Subject: Re: The Constrained One-Time Pad and the Cryptanalyst's Lucky Day
AllanW wrote:
>
> > "Robert C. Paulsen, Jr." wrote:
> > > But the next thing to consider is that the tiny degree to which
> > > quantum randomness affects the initial conditions may be enough so
> > > that the quantum randomness is magnified to be the primary factor
> > > in the results. (These "initial" conditions get applied at every
> > > bump and bounce the dice take.)
>
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > Rolling dice would be just as random if physics were Newtonian
> > and not quantum. You were right in identifying this as an
> > example of chaos, however. The outcome is determined by many
> > nonlinearly interacting, hard-to-control factors.
>
> Suppose I had the money and inclination to perform an experiment.
> I construct a device which will launch a die with a constant
> force. Another device is responsible for loading the die into the
> first device in an absolutely consistent fashion -- the same
> orientation (1 up, 2 faces forward) and pressure. I bring these
> devices into a small enclosed room which has no living organisms.
> There are also no air currents and constant air pressure -- say a
> partial vacuum -- we can make it a perfect vacuum if that helps.
> The devices do not move, so every time they launch the die they
> shoot in the same direction and the die hits the same spot on
> the floor. The die and the floor are both made from hardened
> steel or something else that resists scratches, dents, etc. The
> room has no windows and is illuminated only by an incandescent
> bulb, hooked up to a voltage regulator to ensure that the bulb's
> brightness does not vary.
>
> Can we expect to "roll" the same number each time?
I do not believe you can. Absent quantum effects, which are not needed
for this explanation, each launch of the device will inject energy. The
collisions will raise the temperature of the device and surrounding by
the amount of energy injected. Since the elasticity of materials is
related to temperature you will have a source of variation.
------------------------------
Date: Sat, 10 Jul 1999 13:33:31 -0400
From: [EMAIL PROTECTED]
Subject: Re: Why this simmetric algorithm is not good?
[EMAIL PROTECTED] wrote:
>
> [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >
> > > Tom St Denis's code is not a good example.
> >
> > You are not perfect and I will prove it.
>
> Of course I'm not perfect. I expect to be a
> better programmer next year than I am today. I
> jumped on your sloppy and incorrect code because
> you used it as an example when giving advice on
> programming.
>
> | > > x = (x + 1) & 255
> | > > y = y + state[x]
> | > > ---
> | > > Can be written as
> | > > ---
> | > > y += state[x = (x + 1) & 255]
>
> > > But definitely not as
> > >
> > > y += state[x++];
> > >
> > > which is what Tom used in his C++ code. If the
> > > increment of x were a separate statement, it would
> > > not matter that it's a post-increment where RC4
> > > requires a pre-increment. Tom's also assuming
> > > (without comment) that unsigned char holds only the
> > > values 0 through 255. ANSI/ISO C requires it to
> > > hold at least that range of values.
> >
> > Well this has the same effect as long as chars are 8-bits. It will
> use
> > x then increment it (which is what you have todo) then add the
> state[x]
> > to y. That's RC4 for you.
>
> I re-included your "can be re-written" above, so we
> can see that
> y += state[x++];
> does _not_ have the same effect. You post-increment
> where RC4 requires a pre-increment.
>
> > You can always use an extra '&255' if you are not sure, but that makes
> > the code slightly longer and slower.
>
> You are making groundless assumptions. The extra
> operation is trivial to optimize away. The choice
> between correct in all cases and faster in some
> cases is not a close call.
>
> > Plus almost every platform I have
> > worked on uses 8-bit chars. It's kinda a standard (people associate
> > chars with ASCII or bytes...)
>
> I recommend ANSI/ISO C - it's not just "kinda" a
> standard. If you must make assumptions beyond the
> standard, you should at least document them.
> Perhaps with something like:
>
> #include <limits.h>
> #if UCHAR_MAX != 255
> #error "Code requires ..."
> #endif
While this works in most cases, I think tests on CHAR_BIT works in all
cases.
Otherwise your comments are on target even if overly restrained.
>
> > > Tom has now given us two implementations of the
> > > simple RC4 algorithm, both of them wrong. He had
> > > an example implementation code to work from, so it
> > > seems that both bugs were the result of his
> > > attempts at optimization.
> >
> > RC4 is hard to get wrong. I don't see what's
> > wrong with my code except
> > for the explitcit use of char=8bits...
> >
> > Here is my understanding of RC4:
> >
> > y = (y + Sx) mod 256
> > x = (x + 1) mod 256
> > swap(Sx, Sy)
> > z = (Sx + Sy) mod 256
> > return Sz
>
> So you want to change RC4 to conform to your code?
> Why did you change the order of the assignments to
> x and y?
>
> [...]
> > I made the 'assumption' that '++x' can be optimized, maybe I shouldn't
> > have. By removing the '++x' and replacing it with 'x + 1' ALL
> > compilers will optimize it by not forcing a second store...
>
> Your assumptions are groundless. Code first for
> correctness, then clarity. Profile before you
> optimize.
>
> [...]
> > > Nonsense. Static storage and the heap are at least
> > > as bad as the stack.
> >
> > Well normally stack usage is harder to track.
>
> I suppose you could say it's harder to track than
> static storage, but both are trivial. Heap is the
> only tracking challenge.
>
> > All you have todo is
> > memset the round keys when you are done.
>
> Irrelevant. Obviously that works for stack, heap
> or static.
>
> > Most people would not know
> > how to clear 4KB of stack space... (well it's not hard but most don't
> > think of it), in fact there is no ANSI standard way to clear stack
> > space...
>
> The only reason "most people" would not know is
> that most people never program in C. Don't project
> your own misunderstandings onto other C programmers.
> Stack storage is not in any way harder to clear than
> heap, and programs are less likely to lose track of
> it.
>
> --Bryan
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Eric J. Korpela)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 11 Jul 1999 17:44:04 GMT
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>However, AFAIK, that is the *only* place the term byte has ever been used
>to describe anything other than an (ahem) octet
I believe that the current C standard uses the term byte to mean the minimum
addressable unit of storage (i.e. the unit of storage in which a "char" will
fit.) Number of bits is only specified by lower bound.
Eric
P.S. "char" the C type, not "char" the fish. I wouldn't put a "char" in
anything smaller than a ziploc bag.
--
Eric Korpela | An object at rest can never be
[EMAIL PROTECTED] | stopped.
<a href="http://sag-www.ssl.berkeley.edu/~korpela">Click for home page.</a>
------------------------------
From: "Daniel Urquhart" <[EMAIL PROTECTED]>
Subject: Re: How strong would this algorithm be ?
Date: Sun, 11 Jul 1999 10:51:26 -0700
Thanks for all of the advice. I think that I am going to look over some
more papers and then try again. The main idea of this algorith anyay was to
keep away the curious (or determined but stupid).
------------------------------
Date: Sat, 10 Jul 1999 14:01:10 -0400
From: [EMAIL PROTECTED]
Subject: Re: Electronically Exporting crypto source (legally)
Put this stuff in talk.politics.crypto. Not sci.scypt.
Dave Hazelwood wrote:
>
> What ever happened to Superman?
>
> Truth, Justice and the American way?
>
> Now...even our President is a criminal who gets away
> with it? Makes me want to puke he does.
>
> They blur the lines between right and wrong so much
> that soon nobody will know the difference.
>
> Then, where are we?
>
> Do we all have to relinquish our our moral and
> legal standards to get what we deserve in modern
> America? I hope not.
>
> EAR is ridiculous regulation and Clinton is a
> ridiculous President. I hope we are rid of BOTH
> of them soon.
>
> I think perhaps there may be a way to use the
> copyright laws to trigger a catch-22 in the courts
> to perhaps challenge the source code exportation
> thing.
>
> Once I have thought it out I'll post my comments
> here but if printed words on paper are somehow
> different than the same words on a disk or a screen
> then somehow I think we have a problem where we
> can't have it both ways. Either it is speech and is
> protected or it is not and can't be copyrighted
> either. Humm.....
>
------------------------------
Date: Sat, 10 Jul 1999 14:16:46 -0400
From: [EMAIL PROTECTED]
Subject: Re: randomness of powerball, was something about one time pads
John Savard wrote:
>
> "Tony T. Warnock" <[EMAIL PROTECTED]> wrote, in part:
>
> >On lotteries: you can help yourself by only selecting numbers greater than
> >31. This means that you won't have to share with people who select
> >birthdays (or other dates). It doesn't improve you chances of winning but
> >it gives you a better expectation. Only works if you select dates.
>
> Yes, that's quite correct. Since all numbers are equally likely to
> win, but the prize is split, one does improve one's expectation by
> choosing numbers others are unlikely to pick.
>
> Of course, the effect is not sufficient to make the expectation
> greater than the prize of the ticket...
Perhaps the best example of this principle if the contest Hofstadter
offer when he was contributing to Scientific American. The deal was to
send a postcard containing a number to SA in order to win a prize of
$1,000,000 divided by the largest integer submitted.
He thought the best answer was a complicated analysis of the
probabilities. In fact it was obvious by inspection that the value of
winning was less than the cost of the postage stamp.
------------------------------
From: [EMAIL PROTECTED] (Keith Reeves)
Subject: How hard is it to find the key in DES?
Date: Sun, 11 Jul 1999 18:47:03 GMT
Hi! I have a question about DES, maybe one of you will be able to
help. Let's say you have the plaintext and the ciphertext, but you
don't know the key. Can you work it out using the plaintext? How hard
would it be?
------------------------------
** 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
******************************
