Cryptography-Digest Digest #505, Volume #13 Sat, 20 Jan 01 06:13:00 EST
Contents:
Re: Kooks (was: NSA and Linux Security) (Greggy)
Re: using AES finalists in series? ("Douglas A. Gwyn")
Re: Kooks (was: NSA and Linux Security) (Greggy)
Re: 32768-bit cryptography (Richard John Cavell)
Re: Kooks (was: NSA and Linux Security) ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Benjamin Goldberg)
brute force and Moore's law (was Re: 32768-bit cryptography) (Eric Smith)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: 32768-bit cryptography (Mok-Kong Shen)
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
----------------------------------------------------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Sat, 20 Jan 2001 06:10:38 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Greggy wrote:
>
> > Their actions show absolutely conclusively that they knew it was
> > properly ratified.
>
> The primary available evidence of a "ratification"
> action by the Virginia legislature is the publication
> of their civil code booklet in 1819. As has been
> explained by others, in those days of poor
> communication (before the invention of the telegraph)
> there was often confusion about the status of
> amendments. There is nothing in the historical
> record showing a previous ratification action in
> Virginia. And I already explained why even if one
> wanted to interpret the publication of the booklet
> as the act of ratification, (12+1)/21 < 3/4 so it
> still wouldn't result in adoption of the amendment.
The constitution is silent as to whether the additional four states
should have been included.
The standard was left to the people back then, and since there is no
indication from anyone back then that the additional four states should
have been included into the process in any way, their standard of
relying only on the 17 stands as obvious and as the law of their time.
You can change this standard today without violating the constitution,
but you cannot change it retroactively for a ratified amendment.
> Persistence of belief, in the absence of supporting
> evidence or in the face of evidence to the contrary,
> using arguments that fall apart when examined, is the
> hallmark of a kook. Indeed, kooks typically feed on
> opposition to their irrational ideas, so one should
> not expect to change a kook's beliefs -- the best
> that one can do is to expose the kookery so that
> other people don't fall into the trap. It's a pity
> that the energy spent promoting lost causes isn't
> directed instead in a more productive direction.
You deny their actions as proof of what was obvious to them. It may
not be obvious to you, but it was to them, and they published what they
knew to be the law of the land.
Are you trying to say you knew better than they?
--
13th amendment to the US Constitution:
If any citizen of the United States shall accept, claim, receive,
or retain any title of nobility or honour, or shall, without the
consent of Congress, accept and retain any present, pension, office,
or emolument of any kind whatever, from any emperor, king, prince,
or foreign power, such person shall cease to be a citizen of the
United States, and shall be incapable of holding any office of
trust or profit under them, or either of them.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Fri, 19 Jan 2001 15:39:56 GMT
Bryan Olson wrote:
> Yes, the series of all five finalists together should be at
> least as secure as any one. Yes, it probably has a lower risk
> of cryptologic failure. A five hundred cipher chain should be
> safer still.
It should be noted that according to Kerchhoff's principle,
no matter how many components are chained together the
enemy should be assumed to know all about that. As usual,
all the keying material together constitutes the message
key. If you want to use a particular number of key bits,
e.g. 128, then the question you ought to be asking is what
is the most effective way to use them? Dividing them
among several factor stages is certainly not it.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Sat, 20 Jan 2001 06:15:39 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> Greggy wrote:
>
> > - I rely on God for help.
>
> Perhaps you missed the sci. part of sci.crypt.
> God help you.
He does all the time.
He healed my broken foot one day - within seconds.
He healed my wife's body so she could carry our son to term.
He healed my daughter.
He healed my son's lungs of fluid in a matter of seconds.
And the list is nearly endless...
The power of God is real and working in my life. Far be it from me to
try to convince you of him through wise speech. I prefer that the
power of God demonstrate for all to see and hear about. That is the
best testimony, for those that want help will be drawn like a magnet
and will eventually find the help they seek. Those that don't want
help, no one can help, not even God.
--
13th amendment to the US Constitution:
If any citizen of the United States shall accept, claim, receive,
or retain any title of nobility or honour, or shall, without the
consent of Congress, accept and retain any present, pension, office,
or emolument of any kind whatever, from any emperor, king, prince,
or foreign power, such person shall cease to be a citizen of the
United States, and shall be incapable of holding any office of
trust or profit under them, or either of them.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Richard John Cavell <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Sat, 20 Jan 2001 17:50:32 +1100
On Fri, 19 Jan 2001, Paul Pires wrote:
> 1024 bit cryptography (If you are talking symmetric) will never be broken
Pfffft!
Computing power doubles every 18 months or so. Brute force is all you
need if you have enough power. Within your lifetime, 3xDES will be
completely crackable.
=============================================================
Richard Cavell - [EMAIL PROTECTED]
Newsgroups - Please keep any discussion on the group, and copy your
replies to me via email. (Server problems). Sending me bulk email
guarantees a nasty response.
Judge Thomas Penfield Jackson on Bill Gates: "He has a Napoleonic concept
of himself and his company, an arrogance that derives from power"
=============================================================
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 16:01:20 GMT
Greggy wrote:
> Read the material before you comment.
Of course, I did.
> Recently I came across an argument not even you can refute
> that says I am right.
The only reason I can't refute it is because you neglected
to state it.
> Then prove me wrong in the example I gave (that you snipped out).
I already gave a counterargument sufficient to disprove it,
independent of the details.
"Don't bother to examine a folly -- ask yourself
only what it accomplishes."
- Ellsworth M. Toohey
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 20 Jan 2001 07:01:28 GMT
John Savard wrote:
[snip]
> I missed that too on my first reading; a reply to my initial post by
> Emmanual Goldberg got me to look more carefully and see that.
^^^^^^^^
Where'd this name come from? That's not me. And I don't see how my
name, "Benjamin" could be mispelled or confused with "Emmanual," which
probably doesn't even belong to any poster here on sci.crypt.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Subject: brute force and Moore's law (was Re: 32768-bit cryptography)
Date: 19 Jan 2001 23:14:26 -0800
Richard John Cavell <[EMAIL PROTECTED]> writes:
> Computing power doubles every 18 months or so. Brute force is all you
> need if you have enough power. Within your lifetime, 3xDES will be
> completely crackable.
Assuming that:
1) your "doubles every 18 months or so" holds true for more than another
century
2) 56-bit DES is brute-force crackable now
One can conclude that 168-bit triple DES will be brute-force crackable
in about 168 years (112 more bits x 18 months / 12 months/year).
Perhaps more than 56 bits can reasonably be brute-forced today. If
it's 80 bits today, 168 bits will only take another 132 years.
Much though I like to be optimistic, I don't think it likely that I'll
be around that much longer.
I'm doubtful that doubling every 18 months can continue for more than
another century. Ray Kurzweil in _The Age of Spiritual Machines_
demonstrates that Moore's Law can actually be extrapolated back to
mechanical computing devices reasonably well, and he claims that the
approaching limits of semiconductor lithography are unlikely to have
much effect on it for quite a few years. However, unless we discover
ways to take advantage of sub-quantum effects or some other *really*
amazing breakthrough (not just your run-of-the mill breakthroughs), it
doesn't look like there can *possibly* be 26 orders of magnitude of
improvement (for equivalent cost or size).
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 20 Jan 2001 07:33:40 GMT
On Sat, 20 Jan 2001 05:45:57 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>Based on long experience, I do not try to predict what people will or
>will not see. I just present the material. But if the material does
>turn out to gain some acceptance, well, the crypto text authors and
>others who have ignored this published work for more than a decade
>just may have some 'splainin' to do.
Right now, I think that all that will be said is "Yes, transposition
is a valid way to transform the set of N-bit strings containing N/2
one bits onto itself such that any member of that set can be
transformed to any other member...we mathematicians knew it all along,
but found it to be quite trivial".
>Dynamic Transposition is not just another block cipher, and also not
>just an example of a serious transposition cipher.
I have not yet plumbed the depths of your paper deeply enough to see
the truth in this statement. Just by being a 'serious transposition
cipher', it puts out in the open a possible case that no one has
troubled to explicitly mention. That's already of genuine value.
It has provoked some thoughts on my part.
Thought 1:
The NSA could actually have used a degenerate case of Dynamic
Transposition.
Let us take a data stream, and convert it 6 bits at a time to symbols
in a 4 of 8 code.
Let us use a sophisticated stream cipher mechanism to generate
successive permutations of the 8 bits from the set of 8!
possibilities.
The advantage of enciphering our 64 symbols to symbols from a set of
70? The combiner recieves always 4 live signals out of 8, and just
switches the 8 input paths to 8 output paths. This, unlike a
conventional substitution, which converts live signals to dead and
vice versa, could have a much quieter TEMPEST signature.
Thought 2:
What I disliked about Dynamic Transposition is that it seemed to
impose bandwith losses.
If one converts the input data stream once to N-bit blocks, and then
does all one's transposition on N-bit blocks, not larger ones, these
losses are avoided. But it would be nice to transpose between larger
blocks. (I'm fond of fractionation.)
I've thought of a way to do it.
Each N-bit block; divide it into 2-bit symbols.
Leave 11 and 00 alone.
The symbols 01 and 10 found in successive blocks can be pooled
together, and transposed _between blocks_ while keeping each
individual block balanced.
This is *not* particularly strong in itself, I admit. But the N-bit
transpositions can still meet your conditions for perfection.
Of course, when I avoid cumulative bandwidth loss religiously, I am
causing Dynamic Transposition to degenerate into a polyalphabetic
block cipher, which just happens to use blocks of N/2 ones and N/2
zeroes instead of blocks of N arbitrary bits. From your later
comments, it appears I am losing something important by so doing.
>In practice, Dynamic Transposition is stronger than an OTP, yet uses
>keys of reasonable size. That may be of fundamental real interest.
What you mean by this claim may be perfectly true. All I can say,
though, is that it will be read - even if misread - as saying things
that cannot be true.
My main criticism of Dynamic Transposition is that it has certain
minor practical inconveniences that will cause it to be neglected.
But this paragraph is going to inspire some people to say you've
'flipped your lid' - as I think you are perfectly well able to
anticipate. As I don't really believe you enjoy that, I fear I must be
so bold as to remind you that when you make bold claims, it is
incumbent upon you to explain them carefully.
You are well within your rights not to be overly solicitous of those
who spring into action whenever they feel the Great God OTP has been
blasphemed; but since the reputation of the OTP _is_ based on a
mathematically-valid insight, if you do not explain yourself
carefully, it will not be only the ignorant who will be moved to
dismiss what you say.
>And Dynamic Transposition strength arguments are not based on unproven
>assumptions.
Why substituting a block with 2^n values for another of those 2^n
values is unproven, while substituting one with (2n)!/(n!*n!) values
for another of those (2n)!/(n!*n!) values is not is less than clear to
me at this point.
All I see is isomorphism - over universes of possible blocks which
happen to have a less convenient number of elements.
Of course, the algebraic structure of bit-balanced blocks subjected to
transpositions - as opposed to that of regular binary strings XORed
with values - is such that every change nicely propagates through the
whole block. At least, as long as the details of how one's stream
cipher output is converted to a bit-permutation are not specified.
That's the only thing I can think of right now that could be called a
'strength argument' uniquely applicable to Dynamic Transposition.
Of course, Dynamic Transposition does have an advantage over static
block ciphers; and the need to avoid multiple anagramming forces one
to change the cipher with each block. I just don't see why one needs
to be 'forced' in this manner to do something; one can use 8-round
DES, with subkeys generated by a sophisticated stream cipher, and
different for every block, and avoid all the inconveniences of Dynamic
Transposition, and gain all the advantages (64 bits of the 96 bits of
any two successive subkeys - the middle 4 bits of each 6 - meet the
classical OTP condition).
The only thing I see as of *practical* interest in Dynamic
Transposition right now is that the algebra of N-bit bit-balanced
blocks under bit transposition is quite different from the algebra of
ordinary binary blocks, so if one could mix Dynamic Transposition with
more conventional encryption without bandwidth losses, one could
frustrate analysis.
For interest's sake, I will provide the following short table here:
Balanced bit strings
2 2
4 6
6 20
8 70
10 252
12 924
14 3432
16 12870
18 48620
20 184756
22 705432
24 2704156
26 10400600
28 40116600
30 155117520
32 601080390
34 2333606220
36 9075135300
38 3 5345263800
40 13 7846528820
42 53 8257874440
44 210 4098963720
46 823 3430727600
48 3224 7603683100
50 12641 0606437752
52 49591 8532948104
54 194693 9425648112
56 764869 0600760440
58 3006726 6499541040
60 11826458 1564861424
62 46542835 3255261088
64 183262414 0942590534
66 721942843 4016265740
68 2845304147 5240576740
70 1 1218627781 6662845432
72 4 4251254027 6836779204
74 17 4613056433 5626209832
76 68 9262064869 3261354600
78 272 1701486919 9032015600
80 1075 0720873333 6176461620
82 4247 8458084879 1721628840
84 16789 1048621189 1090247320
86 66375 5308502375 5473070800
88 262485 0538168485 1188961800
90 1038274 2128755341 1369671120
92 4107954 4944205914 9332177040
94 16257011 4034517025 0548615520
96 64350670 1386629890 8421603100
98 254776122 5898085690 2730428600
100 1008913445 4556419333 4812497256
Thus: There are 252 strings of 10 bits with five one bits and five
zero bits.
So, take a message composed of binary bytes, selecting four values to
be ignored - skipped for this encryption step.
Convert the other values, and then perform a Dynamic Transposition on
the 10 bit blocks, then convert everything back to normal bytes.
One has performed a distinct kind of combiner operation, something
genuinely different from XOR or modulo-256 add.
That in itself is of some value, although, as you doubtless will note,
it is a woefully degenerate case of what you are presenting.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Sat, 20 Jan 2001 10:59:38 +0100
lemaymd wrote:
>
> To all interested:
> Bermuda Triangle 2001 is an extremely fast, easy-to-use and secure
> cryptography engine. It is based on a new, 32768-bit algorithm of the same
> name. Algorithm details can be found at my site as well as a software
I suggest that you post a succint description of your
algorithm here rather require others to access detailed
informations on your web page for a first-pass reading
and give its advantages in your view. (Maybe there are
others than me who are a bit lazy to access web pages.)
M. K. Shen
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Sat, 20 Jan 2001 02:08:47 -0800
zapzing wrote:
>
> Upcoming versions of windows may have, I
> read, something called "product activation".
> This means that you must call up microsoft
> so that the OS can have permission to run.
> I have a few questions about this. First of
> all, under what conditions will MS
> *refuse* to activate the product. It seems
> to me that if they never refuse activation,
> then putting in product activation code is
> pretty useless. And if they do, they may
> deny legitimate users who reconfigure their
> systems frequently.
>
> Also, what about the possibility of a major
> computer virus that requires many machines
> to restore. This would of course require
> that the OS be reactivated, but in that case
> the product reactivation lines could be
> jammed. This would make me think about it
> very carefully before I bought an OS that
> included product reactivation code.
>
> I understand MS's desire to protect their
> intellectual property, but please try to think
> of something that will not cause the collapse
> of civilization.
>
> --
> Void where prohibited by law.
>
> Sent via Deja.com
> http://www.deja.com/
It MAY not be a MS innovation.
Microsoft Anti-Piracy Feature: "innovation"? It's unpatentable?
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.
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. I signed it, after all, it was MS,
right. I signed it and sent in my software with 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.
And by the way, it had my anti-piracy feature compiled within the
software.
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.
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.
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.
My anti-piracy feature would significantly reduce the casual
unauthorized copying of my software which was my intent.
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.
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.
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.
How long would it take MS to decompile my software and figure it all
out? About three years, I tell you (MAYBE.)
(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.
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.)
Can anyone tell me if I have a case with MS? 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. What about a trade secret case?
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.
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.
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.
The AthNm2Wn.exe file is dated 11/12/98 but the OAP-L3 version I sent
MS is Version 1.11 from 1997. The version I'll be sending you was an
updated version that works on other versions besides only Windows 95.
I know it will work on Windows 95, 98, & I think NT, and probably on
Windows 2000 and Windows ME. The commands to access the hard drive and
OS data are the same API commands today as they were a few years ago.
There should not be any problems.
Here is a sample encrypted output from a PsWrdAut.zip file resulting
from running the AthNm2Wn.exe file:
86484116454482370470876186732445057261599638001917190606203906434
564473550325397261742949726245387890322527732054
And here is a sample password I would send you back in a Passwrd.zip
file:
0639514512707809172150616133882400190597
The .zip file extensions are used only so the data in the files will
remain in an attached file and not print to the email window. They
are not genuine .zip files. You can open them by running WordPad or
NotePad then opening them up from within either of these programs.
Choose All Documents in the Open dialog box to view them so you can
select them.
I can produce my original versions of my anti-piracy feature in
source code and executable in stand alone applications or
incorporated in some of the earliest versions of my OAP-L3
encryption software. I saved them all.
I may even be able to produce my email or snail mail correspondences
with MS and Intel.
Hope to hear from you.
[EMAIL PROTECTED]
Bye.
------------------------------
** 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
******************************
