Cryptography-Digest Digest #553, Volume #13 Fri, 26 Jan 01 03:13:00 EST
Contents:
Re: Durstenfeld Transpositions & ARC4 ("r.e.s.")
Re: What do you do with broken crypto hardware? (Nicol So)
Re: Durstenfeld Transpositions & ARC4 (David Wagner)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation (Anthony Stephen
Szopa)
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Durstenfeld Transpositions & ARC4
Date: Thu, 25 Jan 2001 23:11:02 -0800
"Terry Ritter" wrote...
| "r.e.s." wrote:
| >In 1964 Durstenfeld published his well-known Shuffle algorithm
| >that generates a random N-permutation by means of successive
| >pairwise transpositions, which seems to be the "dynamic" part
| >of Terry Ritter's "Dynamic Transposition" cipher. Has there
| >been substantive improvement in such algorithms since 1964, or
| >does Durstenfeld's remain about as good as any?
|
| There exist other permutation techniques of similar age. Shuffle
| seems about as good as any, and is widely understood. For the
| state of the art up to 1991, see:
|
| http://www.io.com/~ritter/ARTS/CRNG2ART.HTM#Sect6.7
Thanks, I'll take a look.
| >Also, is ARC4's byte-stream generator adequate as a CSPRNG?
|
| The ARC4 state is awfully small for Dynamic Transposition,
| especially
| if we shuffle twice. We want more active state in the RNG than is
| used in a single encryption, and probably do want at least 128 bits
| in
| the block. Since rejection in Shuffle (to achieve variable-range)
| throws away values (and may throw away a lot), probably it is not
| large enough.
I wasn't proposing to use Dynamic Transposition, but what you
say is interesting -- especially since the Ciphersaber FAQ says...
"RC4 is a powerful pseudo-random number generator, with a much
bigger internal state, then [sic] the ones that come with most
programming systems."
| >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.
| >If the answers to these last questions are in the affirmative,
| >then I wonder whether it might be reasonable to have a 2-stage
| >cipher that first uses ARC4 as usual (e.g. as in Ciphersaber),
| >followed by Durstenfeld Transpositions (Shuffles or equivalent)
| >whose rand(1..n) procedure also uses ARC4's stream. (?)
|
| Durstenfeld did not invent bit-permutation ciphers, nor did he
| invent
| the idea of bit-balancing the data for a bit-permutation cipher.
| That type of cipher is called Dynamic Transposition.
The Shuffle algorithm is for generating random permutations
of *anything*, right? So surely you don't consider that
simply using it for bit-permutations is proprietary? (One
could also use Shuffle for byte-permutations, but I believe
both to be non-proprietary uses. NB: I'm specifically *not*
referring to other cipher components such as bit-balancing.)
--r.e.s.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 02:40:10 -0500
Reply-To: see.signature
Nicol So wrote:
>
> Paul Rubin wrote:
> >
> > Nicol So <[EMAIL PROTECTED]> writes:
> > > What you want to do with a failed security module is to retire it--stop
> > > encrypting information for it and obsolete any information stored on it.
> > > What you don't want to do is to store global/shared secrets directly in
> > > the non-volatile memory on a security module. Any such secrets should be
> > > stored off the module in encrypted form and loaded in volatile memory
> > > when they are needed. This way, the security module by itself is not
> > > enough to perform any sensitive operation, and can be sent to the
> > > manufacturer for replacement.
> >
> > 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.
Lest anybody think that I'm proposing doing the above in place of
erasing the keys on the security module, that's not what I have in mind.
Attempts should be made to destroy the secrets on the security module,
using physically destructive means if appropriate.
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.
--
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: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Durstenfeld Transpositions & ARC4
Date: 26 Jan 2001 07:52:08 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Paul Rubin wrote:
>[EMAIL PROTECTED] (David Wagner) writes:
>> Noone knows. But, it is used in >99% of all SSL connections,
>> so if it's not, lots of SSL transactions are in trouble!
>
>Nah. It's already known that you can distinguish an ARC4 stream from
>a random stream by examining about 2**30 bytes of output. That makes
>it fair to say it's inadequate as a CSPRNG; but I wouldn't say any SSL
>transactions are in trouble as a result.
Good point!
You are quite right (as always), and I withdraw my erroneous claim.
Thank you very much for the correction.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: What do you do with broken crypto hardware?
Date: 25 Jan 2001 23:32:04 -0800
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.
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. The encrypted external keys have to be kept
on the host file system so they can be loaded into the module when
needed. That means copies end up on the server backup tapes and end
up who-knows-where; various sysadmins have root access to the host
(e.g. so they can reboot it if needed) and that means they can copy
the files; etc. It's really quite hard to control random disk files.
Getting rid of the need to do so is the purpose of the module.
Am I overlooking something and/or going about this the wrong way?
This is practical stuff that doesn't get enough discussion on sci.crypt
so I'm glad we're having this conversation.
Thanks
Paul
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Mr Szopa's encryption (was Why Microsoft's Product Activation
Date: Thu, 25 Jan 2001 23:49:47 -0800
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
>
> >Like I am still waiting for anyone to come up with a reasonable
> >suggestion on how to break my encryption software.
>
> >One person tried to make a show of it but in effect was demanding
> >the key once removed and then claiming that with it he could break
> >the encryption. I think not. You cannot have the key or the key
> >once removed.
>
> I guess you're talking about me, even though your description is less
> than accurate.
>
> I claimed that the raw digit stream from your pseudorandom digit
> generator is predictable under certain conditions. I was prepared to
> back up my claim by predicting some digits, given a long enough sample
> of the output of the pseudorandom digit generator. I never got the
> challenge sample from you, though, so I presume you aren't contesting my
> claim per se, only its relevance to the strength of your encryption. I
> concede that you may be right, for all I know, but still, IMAO, you
> should address this issue on your Web site and explain your reasons for
> believing that the predictability of the pseudorandom digit stream
> doesn't weaken the encryption.
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOm8B1V+t0CYLfLaVEQL7kgCgl/+SsX6467PCdv0mt6eeWivA+E8An0/L
> +GtL8/5ijjiDBXfA1+AQ+bcO
> =KPYV
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
I already have answered your proposal over a few posts way back when.
There are certain agreed upon criteria upon which an encryption
scheme is to be attacked. Yours is completely different from this
and obviously unacceptable. This criteria is well known and is not
arbitrary. It is a logical set of criteria based upon real world
circumstance and situation.
Answer us this: where are you proposing getting the raw random digit
output from the random number generator to break someone's key?
The answer of why your suggestion doesn't weaken the encryption is
obvious on its face. You'll never get the raw random digit output
from the random digit generator. If you could, then you could
probably get the key, and the final OTPs as well. Why even bother
to attempt to break the encryption under these circumstances.
But let's just say somehow you did get the raw random digit output
from the random number generator and let's say you even got the
entire three MixFiles.
About 28% of the raw random digit triplets are going to be thrown out at
random. Then the remaining 72% or so of the triplets are going to
be divided to get a stream of random numbers from 0 - 255. Then these
several random number streams will be combined in numerous different
ways and finally once again when the final OTPs are generated.
How are you going to get from the raw random digit output from the
random digit generator to the triplets that are kept to the random
number streams containing the numbers from 0 - 255 and then how are
you going to get to the final OTPs?
If you are planning to break the encryption you cannot stop with the
raw random digit output or working backwards to the MixFiles. You
must continue forward to the final process and predetermine the final
OTP files.
You haven't even come close.
Your whole original premise is not thorough or logical. Ultimately,
it has no bearing on the breaking of OAP-L3.
------------------------------
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:05:20 -0800
Richard Heathfield 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
Pointless program where to stop software piracy could increase
revenues by tens of billions of dollars each year? Pointless?
I will not defend copy protection here and now. You slide on this
point.
Some people like the XOR program and have downloaded it. It works
just fine as someone in this news group pointed out. And here you
go again, trying to assail my software's aesthetics. Can't prove
anything negative about the theory of OAP-L3?
Say, you don't want anybody stealing your money: give it away, it's
that simple, too.
You still haven't figured out why I wrote the XOR program and posted
it on my web site for all to download. I guess if you don't get it:
you just don't get it.
I mentioned to a guy once that US laser weapons are only about 10%
efficient. He said who cares, they get the job done.
What are MSs objectives? It matters.
MS is losing a bundle on its software being pirated. You are just
spamming when you ask who would want MSs software. The answer is
just about everybody, especially if its free.
------------------------------
** 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
******************************
