Cryptography-Digest Digest #517, Volume #13 Sun, 21 Jan 01 18:13:00 EST
Contents:
Re: Differential Analysis ("David Thompson")
Re: A Small Challnge (Bryan Olson)
Re: cryptographic tourism in Russia (Eric Lee Green)
Re: Why Microsoft's Product Activation Stinks (Matthew Montchalin)
Re: using AES finalists in series? (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Differential Analysis (Tom St Denis)
----------------------------------------------------------------------------
From: "David Thompson" <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Sun, 21 Jan 2001 21:25:08 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote :
...(in C code)
> > unsigned int table[256][256] = {0};
...
> I would memset the table first. I dunno if = { 0 } will set all the
> elements. ...
It will. In fact this is something of an idiom.
An automatic (stack) variable with _no_ initializer
is indeterminate, but with a partial initializer list
"all subobjects that are not initialized explicitly
shall be initialized implicitly the same as
objects that have static storage duration."
which is to zero, including floating point 0.0
and null pointer if those are not all-bits-zero.
C99 6.7.8p10,19; C90 6.5.7 wording was
"the remainder of the aggregate" since it
didn't have to deal with designated initializers.
To be really pedantic, the standard allows
trap representations in integer types other than
unsigned char and C90 arguably signed char,
so all-bits-zero theoretically could fail,
but not on any platform you'll be using.
More substantively, unless I misunderstand,
you want to tabulate output difference
versus input difference. That would be
++table[x^y][sbox[x]^sbox[y]]
if x and y are the two inputs, or
++table[x][sbox[y]^sbox[y^x]]
if y is one input and x the input difference.
This is not the same as either your code
or Benjamin's as posted.
--
- David.Thompson 1 now at worldnet.att.net
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: A Small Challnge
Date: Sun, 21 Jan 2001 22:03:48 GMT
IFrog2000 wrote:
> "Bryan Olson" wrote
> > rosi wrote:
> > > Correct. Again randomization is not QP otherwise QP embraces
> > > some very uninteresting things.
> >
> > I don't think you understood. My modification (to any PK
> > cipher) required no randomness.
>
> It's easier to crack. Randomness, although pseudo, is
> much harder to reverse engineer.
What is the "it" that's easier to crack?. My modification is
no more or less easy to crack that the PK scheme on which it's
based.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Eric Lee Green)
Subject: Re: cryptographic tourism in Russia
Reply-To: [EMAIL PROTECTED]
Date: Sun, 21 Jan 2001 22:23:05 GMT
On Sun, 21 Jan 2001 18:59:57 GMT, JimD <[EMAIL PROTECTED]> wrote:
>On Sun, 21 Jan 2001 14:00:59 GMT, [EMAIL PROTECTED] wrote:
>>As a high-tech person interested in cryptography, espionage,
>>telecommunications, internet, satellite systems and a related gamut of
>>topics, I would like to visit interesting places in Moscow and St Petersburg
>>on my impending tourist jaunt there. For instance, visiting buildings that
>>were or are, the equivalent of the NSA and GCHQ, or whatever other relevant
>>sites. Can readers offer me suggestions ?
>
>I wish you luck. We'll send your food parcels to the
>Lubiyanka in Moscow, shall we?
Hmm... a point there, given that the government there is now run by a
former intelligence officer and that they've a nasty habit of
imprisoning Americans that they think are nosing around in the wrong
place...
A friend of a friend spends time in Russia from time to time (he
supposedly is a school teacher, but has this strange habit of turning
up wherever things are heating up... e.g. Columbia during the worst of
the drug wars, Poland when Solidarity kicked out the Communist
government, Russia during the failed coup, ...). The stories I hear
are pretty bad -- things apparently got pretty lawless for a while,
the old government had virtually collapsed into meaninglessness, and
the new government apparently is overreacting by attempting to clamp
down harshly on all the lawlessness. I'm not sure I'd be adventurous
enough to plan a trip to Russia right now.
--
Eric Lee Green Linux Subversives
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism,us.issues
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sun, 21 Jan 2001 14:23:54 -0800
On Sat, 20 Jan 2001, Anthony Stephen Szopa wrote:
|Did Microsoft do it again?
|
|I read in MicroTimes a week or so ago that Microsoft has added a
|"new" anti-piracy feature to their soon to be released new Operating
|System.
|
|In the article it said that the user would have to contact Microsoft
|and run a registration program, the output of which would send a
|message to MS, whereupon MS would use this information to generate
|a password and send it back to the user unlocking or enabling the
|OS software.
Why stop there? Wouldn't MS provide itself with a backdoor to any
OS they offer to the public?
|What really caught my eye was that if the user made any major change
|to their system, SUCH AS REFORMATTING THEIR HARD DRIVE, they would
|need to get another password.
|
|MS is hoping that other software manufacturers will adopt their
|anti-piracy feature.
|
|!!!!!
|
|I think that MS cannot patent this anti-piracy feature because maybe
|they did not invent it.
|
|I DID. Or maybe I may have certainly invented it before MS.
|
|Got your attention?
|
|Yes, I sent MS my encryption software, called OAP-L3: Original
|Absolute Privacy - Level3, back in 1997. I had contacted them and
|they sent me a release agreement.
Can you post a copy of the release agreement?
|I signed it, after all, it was MS, right. I signed it and sent in
|my software with it.
Why did you sign it?
|I can tell you the name of the person I sent it to, the day and
|month and year, the version of the software I sent them and the
|serial number of the software.
What was his name?
|And by the way, it had my anti-piracy feature compiled within the
|software.
And you didn't have the presence of mind to insert a feature that
is readily identifiable as yours under the right circumstances?
(For instance, repeating your name 1,997 times, and which is never
called because it is outside the execution path of the processor
- surely you aren't writing this in C - and which, if XOR'd by
a known value restores your name to its pristine elegance?)
|Here is what they got along with the executable software: a separate
|Password Authorization executable that was to be run on the user's
|computer that generated a 113 digit output file that contained
|data from the user's computer that would uniquely identify the user's
|machine. This data was encrypted within this 113 digit number.
Okay.
|The user would then email me this file containing this string.
|
|I would then decrypt this string of 113 digits to generate a 40 digit
|password based upon the user's unique computer data and email a file
|containing this password back to the user.
And for this MS sent you a release?
|The user would then copy this file to their computer.
|
|Every time the user ran the program, the software would generate
|this same user's unique computer data then using an algorithm, the
|password would be applied to this unique data. If the result was
|an enabling number the software would run. If the password was
|incorrect the enabling number would not be generated and the
|software would not run.
Okay.
|My anti-piracy feature would significantly reduce the casual
|unauthorized copying of my software which was my intent.
Exactly!
|This is also MS's intent.
|
|But what got my suspicions up was that MS has stated that if the
|user makes any significant changes to their computer system that
|they would have to get another password.
|
|This is what I said in my license agreement: that if a new password
|was needed by a user a new password would not be unreasonably
|withheld.
|
|But here is the kicker: MS gave an example of one such major
|computer system change that would require a new password --
|
|MS said that if the hard drive were reformatted, for instance, then
|the user would need a new password.
MS should be broken up.
|One of the parameters that my anti-piracy feature used was the
|volume serial number from the hard drive. This is accessible using
|the API system services and the thing about it is that every time
|you reformat the hard drive, the hard drive is given another
|RANDOM volume serial number.
|
|So MS is using the hard drive volume serial number just like I was.
Okay.
|So, I send MS my software with its anti-piracy feature installed and
|they don't ever get back to me. And here it is MS coming out with a
|new anti-piracy feature that they hope the industry will adopt.
Why did you sign that release, way back when, without installing
a readily identifiable feature in your code?
|How long would it take MS to decompile my software and figure it
|all out? About three years, I tell you (MAYBE.)
Interesting. It was in assembly language, wasn't it?
|(What is really a bust is at the same time I was contacting MS
|I was also contacting Intel. I told them that I had heard that
|they or people in their industry were saying that one of the
|reasons that chip prices are so high is because so many of these
|expensive chips are being stolen and they have to make up the
|cost somehow.
That's possible.
|So I told them that they should put ID numbers in their expensive
|CPU chips. Then these chips could be reported stolen and this
|information could be collected centrally with Intel so anyone
|buying a computer could check their CPU serial number against
|the list of stolen CPUs. (Actually I told them more but no sense
|getting any further along this side track now.)
|
|Well, we now have the Pentium IV with an ID serial number. Just
|coincidence, I guess.)
Would a jury believe that it was "just a coincidence?"
|Can anyone tell me if I have a case with MS?
A case, sure. But a winning case? Maybe.
|Has MS attempted to patent their anti-piracy feature they hope
|the industry will adopt? I will have to check to see if I even
|applied for a patent on this. I may have but I can tell you
|that if I did that the provisional patent has certainly expired.
Some patents are issued for ongoing processes in development.
The US Patent Office receives 'certificates of correction' in
that case. I think you should talk to a patent atty.
|What about a trade secret case?
Hmmmmm.... Did you insert a readily identifiable feature in
your code?
|Did I blow it or what? MAYBE BIG TIME???!!!
|
|I can make the Password Authorization executable available to anyone
|who would like a copy. I spent an hour looking for my old files.
|They are as good as new on floppies. I even tested it out on my
|Windows 98 OS computer. It works fine and generates the 113 digit
|encrypted output that contains the unique data that uniquely
|identifies my computer.
Interesting.
|If you get the executable you can run it and I will tell you what
|your hard drive volume number is, what your Windows 95/98 OS ID
|number is and when you ran the program. Email me the file it
|outputs as an attachment and I will email you back this
|information so you can see that I am not BSing.
Oh, I'll take you on your word that you are being honest.
|Of course, since you don't have the version of OAP-L3 that had
|the anti-piracy feature installed, there is no need for me to
|send you the 40 digit password either, but I will just the same.
|
|The file you want is AthNm2Wn.exe.
|
|Email me and let me know you want the AthNm2Wn.exe file and I'll
|email it back to you. I can prove what I say.
<technical details snipped>
|I may even be able to produce my email or snail mail correspondences
|with MS and Intel.
|
|Hope to hear from you.
|
|[EMAIL PROTECTED]
Please keep us all abreast of developments.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: using AES finalists in series?
Date: Sun, 21 Jan 2001 22:42:35 GMT
On Sun, 21 Jan 2001 18:43:53 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt William Hugh Murray
<[EMAIL PROTECTED]> wrote:
>[...]
>I do not understand why AES. I do not think that is for the same reason
>as DES. I do not agree with Terry that it is to limit cipher
>development. Indeed, early in the AES effort, Bruce Schneier argued
>that one of the benefits was that it encouraged cipher development.
Bruce Schneier was at best only partially right -- which also means
that he was at least partially wrong.
Even a contest with no payoff can encourage some entries.
However -- and in marked contrast to theory and guessing -- I can
personally attest that I was prepared to enter the competition, until
it became apparent that I could not do so and retain my intellectual
property rights. Now, I had no illusions about actually winning; no
tiny company is going to win such a contest. But the promise to hand
over the property rights would have compromised my ownership until the
contest was over, at some vague time in the future.
In the end, I did not participate, so *my* development did not occur.
Thus, I can personally testify that AES did in fact *discourage* my
cipher development, since it was clear to me that there would be even
less of a market for new ciphers in the future than there was at the
start. I find it hard to imagine that I am the only one who was in
that position and who felt that way -- I'm just the only one foolish
enough to spend my time telling people about it.
When there is no payoff, there is no financial basis for a business.
There is no way to hire people, no way to pay them so they can have
food, homes and family, just like everybody else. When a cipher is
free, and apparently "certified" by the government, why pay for
anything else?
I note that AES did not guarantee free encryption software so that all
society could use encryption; it instead removed the economic basis
for an industry of cipher *development*. It also failed to provide an
economic basis for cipher *evaluation*; the ad-hoc "please donate your
time" approach is just sad.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sun, 21 Jan 2001 22:43:08 GMT
I am trying hard to keep up, but that is very difficult if I am to
take time to consider what I am saying. /tfr
On Sat, 20 Jan 2001 22:47:26 GMT, in
<2Aoa6.127512$[EMAIL PROTECTED]>, in sci.crypt "Matt
Timmermans" <[EMAIL PROTECTED]> wrote:
>"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> You need to be more explicit. In Dynamic Transposition, each block is
>> ciphered independently under a running keystream starting from a
>> random message key.
>
>Each block is ciphered independently only if the RNG sequence for multiple
>blocks is independent. Otherwise, there will be correllations between
>blocks in the permutation chosen.
Yes, there will be correlations between *the* *permutations* of
successive blocks.
But the permutation used is not known; it is hidden by the structure
of the bit-balanced data. Many different permutations will take the
exact same plaintext to the exact same ciphertext. The particular
permutation involved is thus hidden, and so the sequence of
permutations is also hidden.
>> Dynamic Transposition is about building an unbreakable cipher
>> *without* needing an unbreakable RNG. This is done by hiding the
>> breakable sequence behind multiple levels of haystack, each so massive
>> that they cannot be searched. So the sequence in question cannot be
>> revealed, which makes it somewhat difficult to attack.
>
>Are you using "unbreakable" in two different senses, here? OTP can be
>provably
>unbreakable, because there is as much key as message. No cipher is
>unbreakable when you have more message than key.
Yes, I probably am using "unbreakable" in two senses, now that I think
of it. I need to meditate on that.
On the other hand, in practice, the OTP is not -- and generally cannot
be -- proven secure, despite endless old-wive's-tales to the contrary.
The fact that this is accepted can only mean that "proof" has somewhat
less meaning in cryptography than one might expect.
No OTP can be secure if the keying sequence is predictable. Here,
"predictable" does not refer to whether or not *we* can predict the
sequence, or whether someone we know can predict the sequence, but
rather whether the opponent can predict the sequence. We cannot know
what the opponents can do.
[ Let me remind everyone that we are talking about *proven*, or
*guaranteed* unbreakability. In practice, it is quite likely that a
well-engineered random sequence will be sufficiently unpredictable to
be very secure. The issue is that we generally cannot *prove* that a
sequence is unpredictable, or measure how unpredictable it is -- we
have no such test, and there can be no such test. As a matter of
fact, new tests keep being developed as additional types of
predictability are found. ]
So unless the OTP keying sequence is *proven* unpredictable in
practice (something which is normally impossible), no practical OTP
can be *proven* secure.
Only the theoretical OTP can be proven secure, and that is only good
for protecting theoretical data (or, perhaps better: "theoretically
protecting data.")
>> >If you don't know anything about the RNG, then there's no such thing as a
>> >known-plaintext attack.
>>
>> Allow me to teach what a known-plaintext attack is:
>>
>> Known-plaintext is nothing more than the situation of the opponent
>> having one or more ciphertext blocks with the associated plaintext
>> blocks. It is quite possible to have that situation without knowing
>> anything of the RNG. A known-plaintext attack is any attack which
>> capitalizes on this information situation (as opposed, say, to
>> ciphertext-only).
>
>Yes, I know what known plaintext is, and the condescension is unnecessary.
>I
>said there were no known plaintext _attacks_ if you know nothing about the
>RNG. If you know nothing about the RNG, then it could be perfect (i.e., OTP
>perfect), no matter what bits you have in your known plaintext/ciphertext
>pair. A perfect RNG is not attackable (i.e, no way to do the _capitalize_
>part of your paragraph above), because nothing you know about it can be used
>to make predictions about its future behaviour. Therefore, a
>known-plaintext attack against Dynamic substitution or an XOR stream cipher
>is impossible when you know nothing about the RNG, because you cannot gather
>any information that would allow you to distinguish the RNG from a perfect
>one.
OK, it becomes apparent that there is serious confusion here.
There is a ciphering technology which I created and named "Dynamic
Substitution." There is another, different, technology which I also
created and named "Dynamic Transposition." Here we discuss Dynamic
Transposition.
Dynamic Substitution is the idea of enciphering data through a keyed
Simple Substitution table, and then changing the contents of that
table. When a character is enciphered through a table, that
particular table transformation may be exposed. We can prevent that
by changing the just-used table entry to some entry in the table (even
itself), selected at pseudo-random. We thus get a state-based,
dynamic, combiner of data and RNG confusion, which is nonlinear and
yet reversible. Dynamic Substitution is a stream cipher combiner.
Dynamic Transposition is mainly the idea of bit-balancing a data
block, and then bit-permuting that block from a confusion stream. It
is thus also a combiner of data and RNG confusion, but it is
definitely a block cipher combiner, and not a stream cipher combiner.
The unexpected advantage of Dynamic Transposition is that a plethora
of different permutations produce exactly the same ciphering result.
This would seem to hide the exact permutation used, and thus also hide
any attempt to define the shuffling sequence by moving back from a
known permutation.
We are discussing block ciphers based on the Dynamic Transposition
combiner.
It is true that in the "Revisited" article, some links showed details
of Dynamic Substitution ciphers. Those links were offered for the
description of example components which, frankly, should be considered
well-known cryptographic technology. Those include: key hashing, a
large-state RNG, nonlinear filtering ("jitterizing"), and permutation
via Shuffle, all of which are needed for Dynamic Transposition. The
bit-balancing process itself was described in the "Revisited" article.
Dynamic Transposition is not a particular cipher; it is instead an
entire class of ciphers which is not covered in the crypto texts. A
cipher designer must choose what sort of RNG to use, how to key it,
how to protect it, and how to shuffle. There are various options, the
details of which are not particularly relevant to the Dynamic
Transposition technology itself, which is the issue.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Sun, 21 Jan 2001 22:48:58 GMT
In article <UsIa6.5680$[EMAIL PROTECTED]>,
"David Thompson" <[EMAIL PROTECTED]> wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote :
> ...(in C code)
> > > unsigned int table[256][256] = {0};
> ...
> > I would memset the table first. I dunno if = { 0 } will set all the
> > elements. ...
>
> It will. In fact this is something of an idiom.
> An automatic (stack) variable with _no_ initializer
> is indeterminate, but with a partial initializer list
> "all subobjects that are not initialized explicitly
> shall be initialized implicitly the same as
> objects that have static storage duration."
> which is to zero, including floating point 0.0
> and null pointer if those are not all-bits-zero.
> C99 6.7.8p10,19; C90 6.5.7 wording was
> "the remainder of the aggregate" since it
> didn't have to deal with designated initializers.
> To be really pedantic, the standard allows
> trap representations in integer types other than
> unsigned char and C90 arguably signed char,
> so all-bits-zero theoretically could fail,
> but not on any platform you'll be using.
>
> More substantively, unless I misunderstand,
> you want to tabulate output difference
> versus input difference. That would be
> ++table[x^y][sbox[x]^sbox[y]]
> if x and y are the two inputs, or
> ++table[x][sbox[y]^sbox[y^x]]
> if y is one input and x the input difference.
> This is not the same as either your code
> or Benjamin's as posted.
I used the former in my sboxgen.c code. I must have posted incorrectly.
Thanks for the notice.
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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
******************************
