Cryptography-Digest Digest #554, Volume #13      Fri, 26 Jan 01 07:13:00 EST

Contents:
  Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
  Re: What do you do with broken crypto hardware? (Paul Rubin)
  Re: What do you do with broken crypto hardware? (Nicol So)
  Re: Durstenfeld Transpositions & ARC4 (Benjamin Goldberg)
  Re: Durstenfeld Transpositions & ARC4 (Mok-Kong Shen)
  Decode Algorythim ("Yeah")
  Re: Some Enigma Questions ("Yeah")
  Re: Steak Stream Cipher ([EMAIL PROTECTED])
  Re: Durstenfeld Transpositions & ARC4 (Mok-Kong Shen)
  Paranoia (Simon Jenkins)

----------------------------------------------------------------------------

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 26 Jan 2001 00:10:54 -0800

Splaat23 wrote:
> 
> He doesn't consider XORing two files together to be significant. That's
> easy! He considers XORing two files together, one of which happens to
> be generated by a PRNG to be significant. Innovation, what a sight! I
> wish I had his foresight to create a slow, unwieldy stream cipher that
> has no market to acquire and no use.
> 
> He was not stupid for showing it to Microsoft. He's stupid for
> believing that not a soul could think it up independently! I love his
> lack of understanding of the laws of causation: "I sent my [simple,
> bad] program [that could be thought up by any 9-year old reading _AC_]
> to Microsoft, and years later they come out with something remotely
> similiar, therefore they are liars and thieves!"
> 
> Note, I think Microsoft's patenting of this, if that's what they really
> intend to do, is silly, like most tech patents, but that's OT.
> 
> Enough bashing of Mr. Szopa. From his past posting history (which I had
> the urge to view and regret my stupidity), Mr. Szopa will disregard
> anything we say here and continue to believe his own superiority over
> us mere mortals.
> 
> - Andrew
> 
> In article <[EMAIL PROTECTED]>,
>   Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > [Sorry to reply to Joe's post when I'm really addressing the issues
> > raised by Mr Szopa. Mr Szopa's article hasn't hit my newsfeed yet and
> > may not do so for some time...]
> >
> > > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]...
> > > > Richard Heathfield wrote:
> > > > >
> > > > > Anthony Stephen Szopa wrote:
> > > > > >
> > > > > <snip over 200 lines>
> > > > > >
> > > > > > So that's all I have to say for a while.
> > > > >
> > > > > Is that a promise?
> > > >
> > > >
> > > > Here is a guy who spits on the souls of anyone for no damned
> reason.
> >
> > I guess it wasn't a promise after all. (sigh)
> >
> > > >
> > > > I told you that I am the inventor that will save people tens or
> > > > hundreds of billions of dollars in lost revenue and you verbally
> > > > shit on me with your sarcasm.
> >
> > You do a good line in invective. Perhaps you should switch from crypto
> > to politics.
> >
> > > > Did you develope an anti-piracy computer software module that will
> > > > prevent perhaps half at a minimum of the illegal copying of
> > > > computer software in the world?
> >
> > Certainly not. I wouldn't dream of writing such a pointless program.
> >
> > > >  Do you know how important a contribution this is?
> >
> > It's completely insignificant to those who have already realised that
> MS
> > has, for years, been using the very best copy protection of all - i.e.
> > products that don't work, products that corrupt files, products that
> > hang the machine... Why would anyone with the slightest semblance of
> > common sense *want* to copy programs like that?
> >
> > > > I can prove that I did this.  And if I eventually do prove it
> > > > publicly everyone will know you are a fool.  But most importantly
> > > > you will know.  I think you probably already know you are a fool.
> >
> > If you really were conned by MS, I sympathise (like Joe), but am
> stunned
> > by your naivete.
> >
> > 1) Copy protection doesn't work. sci.crypt already knows this. Why
> don't
> > you?
> > 2) Microsoft is well-known for exploiting anything it can exploit.
> >
> > > > I am certainly one of a very very few and perhaps the only person
> in
> > > > the world who can prove that they did it before MS.
> >
> > You're the guy with the proprietary no-source-code-provided technique
> > for XORing two files together, yes? The one with the front end that
> > looks like something the cat dragged in? The one you said was so
> > innovative?
> >
> > > > I am not going
> > > > to divulge my thought processes here or my plans or my actions
> > > > regarding the implications of this situation at this time, as I
> have
> > > > said.
> >
> > Excellent.
> >
> > > > I am actively pursuing my interests.
> > > >
> > > > I think I read that there is about $50 billion dollars worth of
> > > > computer software piracy going on every year.
> >
> > Well, people will play those games, I suppose.
> >
> > If you don't want people to steal your software, give it away. It's
> that
> > simple.
> >
> > > > You must be a real high achiever to top this.  Tell your friends
> > > > what a proud soul you are and give them the example you posted
> here
> > > > and explain to them why you are the one to be so sarcastic.
> >
> > Righty-ho, I'll do that.
> >
> > > > What are your qualifications?
> >
> > I can write a program to XOR two files together. Does that count? (It
> > seems to be a significant achievement from your point of view, if I
> > correctly recall your proud boasts of about three months back.)
> >
> > > > I would tell them that you are a high risk gambler and that they
> > > > should stay as far away from you as possible.
> >
> > Interesting. I have made exactly two serious bets in my entire life.
> In
> > each case, I calculated the probability of my winning to be 1.0. In
> each
> > case, I won the bet. If the probability of victory is < 1.0, I don't
> > bet.
> >
> > > > You just can't believe that I did what I say I did, can you?
> >
> > Yes, I can believe that you could design a copy protection protocol
> > (albeit an inherently flawed protocol, as all such schemes are). What
> I
> > was having difficulty with was your stupidity in showing it to
> > Microsoft.
> >
> > > > You think you can
> > > > make the jump and take the leap to ridicule me.
> >
> > You're doing fine all by yourself.
> >
> > > > You have no proof that I am lying.
> >
> > "The wicked flee when no man pursueth." (Prov 28:1)
> >
> > I have not accused you of lying. I am quite prepared to believe that
> you
> > have invented a copy protection protocol. I can even take a guess as
> to
> > how it might work. The potential software pirate has to shuffle some
> > cards, yes?
> >
> > The fact that you deny lying without being accused of it, however, is
> in
> > itself deeply suspicious.
> >
> > > > Yet you risk your reputation.
> >
> > That's all right. My reputation on sci.crypt is "cute and fluffy, and
> > has at least quarter of a brain, if not slightly more, but can't
> > cryptanalyse anything harder than Vigenere", and I'm certainly
> prepared
> > to risk that. Strangely, your reputation on sci.crypt seems to be even
> > worse than mine. Odd, that.
> >
> > > > As I said, you have
> > > > poor judgment although you have calculated that you are on solid
> > > > ground.  Quicksand, yes.  You are in quicksand and there will be
> no
> > > > one to come to your aid.  Just wait and see.
> >
> > /me checks his immediate environment...
> >
> > Aarrgghh! You're right! Quicksand! I'm sinking! Quick, somebody...
> SAVE
> > ME! SAVE ME! Don't leave me to a horrible death!!!
> >
> > Oh, hang on, it's okay, it's just carpet. Panic over.
> >
> > > > If and when the proof comes out I hope someone brings it to you
> > > > attention.
> >
> > Well, you could always post the source to alt.sources.crypto. I'll see
> > it there, I expect. Oh, can you make sure it works in Linux please?
> > Thanks.
> >
> > > > I was waiting for a worm to show their slime.  You finally showed
> up.
> >
> > It is not surprising that a purveyor of snake oil should see the world
> > in terms of long thin creatures.
> >
> > > >
> > > > What is a fool?  A fool is a person who plays an Eric Clapton song
> > > > on their own guitar. He plays the song perhaps even as good as
> Eric
> > > > Clapton.  And then he thinks he is as great an artist as Eric
> > > > Clapton.
> >
> > By that definition, Eric Clapton is a fool - which I don't believe.
> > Therefore, the definition is wrong.
> >
> > > > You are an even greater fool than this because you would play the
> > > > air guitar while listening to Eric Clapton and really believe you
> > > > are as great a musician and artist as Eric Clapton.
> >
> > Actually, I play a pretty mean "Layla", but I wouldn't claim to be in
> > the same league as EC.
> >
> > > >
> > > > Can you feel your heart literally shrinking?  You will.
> >
> > Do you literally mean "literally" literally?
> >
> > > > Gee, you didn't get any more significant information from me about
> > > > my claim?
> > > >
> > > > Too bad.
> >
> > Ah! You caught me out! Yes! I was trying to do industrial espionage
> over
> > Usenet, like all the best spies, but the ever-clever Mr Szopa was too
> > smart for me, and foiled my cunning plan. I am exactly as chagrined,
> > chastised, and chastened as I ought to be.
> >
> > I sometimes wonder what planet you're on. On my home account (not this
> > account, you understand), I killfiled you well over a year ago. That
> may
> > have been a mistake, as you are proving to be a plentiful, albeit
> > unwitting, source of humour. Mind you, I suppose sci.crypt can live
> > without regular flame battles between us, so perhaps it's just as
> well.
> >
> > --
> > Richard Heathfield
> > "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> > C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> > K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
> >
> 
> Sent via Deja.com
> http://www.deja.com/


I know.  You could have thought of it just like a bunch of monkeys
banging away on a typewriter would eventually write Shakespeare's 
plays.

It is no big deal?  MS just loves wasting its time and money?  They
wouldn't be promoting this if they were not serious.

They are trying to have their anti-piracy feature accepted as the
industry standard, by Jove!

A nine year old?

Sounds like you are ready for your first Eric Clapton air guitar.

------------------------------

From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: 26 Jan 2001 00:15:20 -0800

Nicol So <[EMAIL PROTECTED]> writes:
> I doubt a manufacturer would insist on verifying that the module died of
> "natural causes" before they would give you a replacement. Unless it
> happens with suspiciously high frequency, it may very well be acceptable
> for you to drill a hole in the module before you ship it to them.

That's an idea.  I'd have to ask the manufacturer for the right place
to drill to kill the flash chips, and believe what they told me.  But
I guess that's ok.  The FIPS 140-1 testing lab might be able to supply
or confirm the placement info.  Thanks.

------------------------------

From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 03:32:23 -0500
Reply-To: see.signature

Paul Rubin wrote:
> 
> Nicol So <[EMAIL PROTECTED]> writes:
> > > This doesn't make sense--the whole point of the tamper resistant
> > > module is to securely store keys internally.  Any keys stored outside
> > > the module are vulnerable to copying and therefore must be encrypted;
> > > but then in order to load them into the module, the decryption key
> > > must be stored inside the module.  So if the module is sent back to
> > > the manufacturer, all the keys are potentially compromised.
> >
> > You're assuming that encrypted versions of these keys are easily
> > obtainable, which need not be true. Note that these keys are uniquely
> > encrypted for a particular security module, there's no reason for the
> > encrypted keys to be floating around. These encrypted keys can and
> > should be placed under tight control.
> 
> Maybe I'm overly paranoid but the encrypted external keys are in disk
> files on the application host, and I'm going by the assumption that
> the online application host is completely insecure.  If I had a way to
> securely control the encrypted keys outside the module, I wouldn't
> need the module.

I'm not familiar with your application, but it sounds dangerous if the
application host is completely insecure. Besides preventing someone from
extracting secrets from the security module, don't you want to control
how the module's functions are exercised, and who can exercise it? I
suspect that you need to provide some level of security to the host
anyway.

> Also, at least at present, all my modules have to share a secret key
> (loaded from smart cards when the module is placed into service) so
> they can talk to each other.  I guess I could have separate internal
> module keys and encrypt the shared keys separately for each of them,
> but that makes the configuration a lot more complicated, and I still
> don't see what it gains.

Whether the above configuration buys you anything depends on whether it
makes the adversary less likely to succeed, and whether the benefit
exceeds the cost. If you assume the encrypted keys are available to just
anyone, then the above won't do you any good. But there are reasonable
assumptions under which the above may be beneficial.

Let's assume that the encrypted keys are fairly well protected so that
there's a low but non-zero probability that an adversary can get to it,
but without physical access it is impossible to extract the secrets from
the security module. For adversaries coming in from a network, their
lives are not made easier. For insiders such as bad admins, their
attacks are not made harder, but not easier either. For the module
manufacturer as an adversary, who's best positioned to defeat/bypass the
module's physical security, they now have an additional barrier to
overcome. That may be an improvement.

-- 
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.

------------------------------

From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 26 Jan 2001 09:21:21 GMT

r.e.s. wrote:
> 
> "Terry Ritter" wrote...
[snip]
> | >If so, is there a straightforward way to adapt such a byte-stream
> | >to generate PRNs uniformly distributed on 1..n?
> |
> | The conventional technique is "rejection."  I have described this
> | many times.  See, for example:
> |
> |    http://www.io.com/~ritter/KEYSHUF.HTM
> |
> | in "The Shuffling Subsystem" section.
> 
> Ah, well...  I had hoped there might be something more efficient
> than rejection methods -- they can be so inefficient that I had
> ruled them out without saying so.

Although the particular rejection method Ritter used is particularly
innefficient (intentionally so, to increase unpredictability), it is
possible to do so with much more efficiency.  One of the posts I made to
this thread (The one at 1:13am) describes two kinds of rejection methods
which are much more efficient.

The first method I suggested there is the most efficient (in terms of
bits used) possible for selecting in a range, but has the drawback that
it must use one bit at a time from the stream.  If your PRNG is not
built for 1 bit at a time, you must either buffer a word to take a bit
at a time, or discard all but one bit of a PRNG call.

The second method I suggested there is the most efficient (in terms of
number of PRNG calls, assuming that the PRNG produces a many bit word
for each call) possible, but has the drawback that many more bits are
discarded.

There is, however, a third method of selecting a number in a range,
which discards no bits *at all*.  To do this, initialize a static
arithmetic decoder, such that each of the values in the range are
equiprobable.  Now, using your PRNG as the "compressed data" source,
decode one value.  There is a [miniscule] chance of underflow, but this
can, in practice, be ignored.

Be warned, I am not absolutely certain that the arithmetic encoder's
output will be absolutely unbiased within the range.  I suspect (gut
feeling) it might not be, but I'm not sure.

-- 
Most scientific innovations do not begin with "Eureka!"  They begin with
"That's odd.  I wonder why that happened?"

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 26 Jan 2001 10:31:01 +0100



David Wagner wrote:
> 
[snip]
> Any CSPRNG can be used to generate random value uniformly
> distributed on 1..n.  Many algorithms have been posted here
> before.
> 
> Here's a simplistic one.  Choose k so that 2^k > n.
> Let l = n*floor(2^k/n).  Using k random bits, generate a
> random number from 0..2^k-1; call it x.  If x<l, then use
> x mod n as your next output value.  If x>=l, then repeat
> (i.e., keep choosing x until you find one less than l).

Sorry, I don't understand. If the CSPRNG is very non-uniform,
you meant that using this processing the result is uniform? 
I doubt that could be the case. I suppose the technique
is for using a uniform PRNG of a different range to produce
an output uniform in the desired range 0..n-1.

M. K. Shen
=============================
http://home.t-online.de/home/mok-kong.shen

------------------------------

From: "Yeah" <[EMAIL PROTECTED]>
Subject: Decode Algorythim
Date: Thu, 25 Jan 2001 20:55:00 +1100

Ok i am writing a program now that uses the encryption key:

Message^13(Mod C)=Encrypted

C bind the key

Only problem is that I have lost my notes as to what the decryption
algorytim is and ideas??



------------------------------

From: "Yeah" <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
Date: Thu, 25 Jan 2001 21:13:42 +1100

> Q5:  If properly used (e.g. few messages, good mixing of rotor settings,
no
> obvious rotor settings (e.g. QWE), varying messages to avoid obvious
cribs,
> having all rotor increment the next rotor at the same position, not
sending
> the same message in more than one cipher system, changing of rotors more
> often than once a war, etc), say along the lines of the German Navy, would
> an Enigma today be reasonably secure?  Put another way, would it be easily
> crackable today by a single person with some cracking tools and a
computer,
> or would it require a high level team like that assembled during the war?

Didn't the British Government invent the worlds first programmable computer
to crak the enigma code. (Suck that America, IBM more precisely)
I think i once heard the lead designer on TV commenting that it too about 5
minutes to crack the code on their computer and that he once got the paper
reel spinning at 3 times the RPM of usual before it broke.



------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Steak Stream Cipher
Date: Fri, 26 Jan 2001 11:14:56 GMT

In article <94r0d7$9cl$[EMAIL PROTECTED]>,
  "Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
> If you have any expectation of any kind of realistic analysis done, I
> suggest you specify the cipher a bit better.  You give some rather
vague
> block diagrams (e.g. what does "Permute" do?  It's never explained
AFAICT),
> and the only other description is the source, which is largely in x86
> assembly language.  A mathematical description would be best.  Clean
> reference code (emphesis on clean) might be acceptable (ANSI C would
be my
> preference).

Of course. A mathematical description it will be. (We don't do C. For
mathematical purposes, we only use assembly and pascal.)

For immediate reference: Permute does not "do" anything. It is a
predefined process which is implemented by pre-calculation and the
result has already been merged into the "Steak_Data" table.

Yes, this predefined process is inadequately described: What I did was
to sort the 256 columns of the 4 rows, 256 columns TwoFish data,
extract the 32 columns which might generate this matrix under the XOR
operation, and then according to some frequency tests, rotate each of
these values one position right and reorder them. The result was:

($8080F8C4,$88084AB1,$31CA8808,$51B2C040,$813D8145,$90631021,$024B2682,$
0422CD04,$810145BD,$02023FFB,$C4F88080,$42FF0404,$2072A043,$C051C032,$08
452E88,$103EDD10,$84047F42,$C04032D1,$3DC58101,$63219010,$827B023F,$8831
884A,$80C8A480,$207D0EA0,$101021E3,$A0204372,$7B3F8202,$72C32020,$80C480
F8,$0442847F,$0125C901,$404E9D40)

The resulting matrix promotes equal probability distribition (in its
context) instead of maximum separation. Without "permute" the first
cipher-text byte past an error would always have been incorrect. Now
the probability is 1/256 that it will be correct. This should divert
some chosen cipher-text attacks, although such attacks will still
reveal that they are dealing with a PCFB-cipher.

I only mentioned it tributarily to state the relation between
Steak_Data and the MDS matrix of TwoFish, and thereby somehow
substantiate our claim that the main function of Steak is bijective.


Sent via Deja.com
http://www.deja.com/

------------------------------

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Fri, 26 Jan 2001 12:26:22 +0100



Mok-Kong Shen wrote:
> 
> David Wagner wrote:
> >
> [snip]

> Sorry, I don't understand. If the CSPRNG is very non-uniform,
> you meant that using this processing the result is uniform?
> I doubt that could be the case. I suppose the technique
> is for using a uniform PRNG of a different range to produce
> an output uniform in the desired range 0..n-1.

Apology for the absolute nonsense that I wrote above.
A CSPRNG must of course be uniform.

M. K. Shen

------------------------------

Date: Fri, 26 Jan 2001 11:53:25 +0000
From: Simon Jenkins <[EMAIL PROTECTED]>
Subject: Paranoia

I have just read Stven Levy's book 'Crypto' and was again struck by the
description of the meeting between Whitfield Diffie and James Ellis.
Ellis' parting comment has him saying to Diffie, "You did more with it
than we did."

As an Englishman, this is an interesting phrase - it implies that GCHQ
don't bother with RSA any more. If they were still using it, Ellis would
have said, "You've done more with it than we have."

Paranoia now sets in. If GCHQ aren't interested any more, it means they
can break it. If they can break it, they've cracked fast factoring. My
question is, what other uses would fast factoring have and would it be
economically viable to keep the method secret rather than release it
into the public domain?


------------------------------


** 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 by posting to sci.crypt.

End of Cryptography-Digest Digest
******************************

Reply via email to