Cryptography-Digest Digest #368, Volume #12 Sun, 6 Aug 00 22:13:01 EDT
Contents:
Re: A non-linear extension of the Hill cipher (Benjamin Goldberg)
Re: OTP using BBS generator? (Benjamin Goldberg)
Re: Q: CD ([EMAIL PROTECTED])
Re: Secure Operating Systems ([EMAIL PROTECTED])
Re: Software package locking ([EMAIL PROTECTED])
Re: New William Friedman Crypto Patent (filed in 1933) (John Savard)
Re: Note on text compression (John Savard)
asymmetric encryption for my keycode generator ("eboy")
Re: Secure Operating Systems (Eric Lee Green)
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: A non-linear extension of the Hill cipher
Date: Sun, 06 Aug 2000 23:10:17 GMT
Mok-Kong Shen wrote:
> Benjamin Goldberg wrote:
> > Some of what you are describing sounds very like Mark Wooding's
> > "Storin" cipher. Enciphering is as follows:
> >
> > X[i], Y[i], Z[i] = intermediate values.
> > K[i] : Round keys.
> > Ma : a 4x4 matrix, invertable under integers mod 2**24
> > Mb : the inverse of Ma; used for decryption
> >
> > Z[-1] = Plaintext, split into a vector of 4 24-bit values.
> >
> > For i = 0 to 7
> > X[i] = Z[i-1] XOR K[i]
> > Y[i] = (X[i] * Ma) MOD (2**24)
> > For j = 0 to 3
> > Z[i][j] = Y[i][j] XOR (Y[i][j] >> 12)
> > end For j
> > End for i
> >
> > Ciphertext = Z[7] XOR K[8]
>
> K is used as whitening and can be excluded from the present
> discussion. The computation of Y is the orginal Hill cipher
> step.
K is expanded from the key. Ma and Mb are fixed and known.
> Then Z is computed from Y as given above, i.e. post-
> processing of the output from Hill.
The calculation of Z is non-linear. The matrix transformation, by
itself, is linear.
> I am not sure that there is a 'very like-ness' that you indicated,
> excepting of course the Hill cipher step. Could you please elaborate a
> little bit?
> Thanks.
>
> M. K. Shen
Umm, well, I'm not sure about 'very' like, myself. 'Sorta' like, maybe?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: OTP using BBS generator?
Date: Sun, 06 Aug 2000 23:10:25 GMT
Terry Ritter wrote:
>
> On Thu, 03 Aug 2000 07:01:49 -0700, in
> <[EMAIL PROTECTED]>, in sci.crypt lordcow77
> <[EMAIL PROTECTED]> wrote:
>
> >Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >>BBS has been a recurring topic in this group. I have little
> >>knowledge in that but I have the impression that discussions
> >>about it never led to unanimously accepted results. You
> >>may try to look into old postings of this group.
> >
> >Wrong. Practically everyone accepts that choosing the factors of
> >the modulus to be congruent to 3 mod 4 and picking a random
> >starting point are enough to ensure that the resulting BBS
> >sequence will be secure, based on the computational equivalence
> >of predicting BBS and deciding quadratic residuosity (and
> >therefore factoring).
>
> That is false on its face. You can accept if you want, however.
>
> It is true that using a short cycle would be extremely unlikely. But
> *when* that event occurs, all the math proofs you have will not save
> you, since the resulting system is insecure.
I'm confused...
a) If the factors of the modulus ARE congruent to 3 mod 4, then are
short cycles likely, unlikely, possible, or impossible?
b) If the factors of the modulus AREN'T congruent to 3 mod 4, then what?
That is, what does that conguency gain, if not (complete?) avoidance of
short cycles?
> Using a short cycle is unarguably insecure. And, unless we
> specifically prevent it, using a short cycle is an unarguable
> possibility.
Makeing the factors congruent to 3 mod 4 isn't a specific prevention of
short cycles?
> The only valid argument here is that using a short cycle would be
> extremely unlikely, and that is no conflict, because I agree.
>
> >Terry Ritter is the only proponent of the
> >position that one must take elaborate steps to ensure that one
> >falls into a guaranteed long cycle on the basis of a
> >misunderstanding of the security proof given by Blum, Blum, and
> >Shub and a desire to assert that no cipher can be proven to be
> >secure under reasonable assumptions, such that he can promote
> >his own products that "stack" multiple patented algorithms
> >together.
>
> Alas for the attempt at a personal attack, I have no current
> "products" in that sense. I do hold current patents which represent
> fundamentally new cryptographic technology. You can like that or you
> can hate it, but I own the technology anyway.
>
> Does the fact that I might make money out of improving technology
> somehow make me suspect for pointing out the problems in other
> approaches? Finding the problems is why I have better approaches.
> But I may be one of the few authors and designers who actively seeks
> negative comments and then publishes those on my pages, as readers can
> attest.
>
> My stuff is not intended to replace BB&S or PK, but if they have
> problems that I see, I'm going to say so, independent of whether I can
> profit from that or not.
>
> I have been doing this for the better part of a decade, and I don't
> need to have my motives questioned. By pointing out problems, others
> can make their own informed choices about how to solve those problems
> or perhaps use something else. My patented technology provides
> alternatives which others may weigh against the price of its use.
>
> For free, I offer a 400K Crypto Glossary, plus a free Introduction to
> Cryptography, Literature Surveys also free, plus lots of other stuff.
> You don't have to buy a book to read my stuff, but if you want to read
> it in a library, you can do that too, on any Web terminal.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q: CD
Date: Sun, 06 Aug 2000 23:08:29 GMT
>From what I understand, retail CDs are made by stamping them, like a
vinyl record. CD-Rs have some type of chemical that reacts to the laser
that burns data onto it.
I would think that the problem isn't the writing of the cd data, but the
reading of it. If you take 2 "rips" of the same audio data, chances are
the bits are never exactly the same, due to vibrations in the cd reader,
scratches on the surfaces, etc.
Is this for that CD-one-time-pad topic that came up earlier?
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> "Douglas A. Gwyn" wrote:
> >
> > Mok-Kong Shen wrote:
> > > Is there an easily obtainable software with which one can
> > > conveniently read out bits from a CD at any specified (hardware)
> > > position? Thanks.
> >
> > If you mean the encoded "pits", you'd need special hardware
> > support. By the time the information reached the computer
> > bus it has already been decoded.
>
> I like to pose a supplementary question: How good are the
> manufacturing and recording process for (data and autio) CDs?
> That is, what is roughly the order of magnitude of the probability
> that 2 CDs have identical 'pits'? Thanks.
>
> M. K. Shen
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Secure Operating Systems
Date: Sun, 06 Aug 2000 23:45:23 GMT
CMan <[EMAIL PROTECTED]> wrote:
> The problem is a difficult one as is evidenced by the fact that the original
> security goals have not yet been reliably achieved.
> The problem may just be too hard!
It may be worse than that, it may be impossible to design a provably
secure operating system. (In fact, I for one remain convinced it is,
but don't know of any proof of that fact either)
Going back on topic, filesystem encryption seems to crop up alot in
these kinds of discussions. But, we don't even have a provably secure
cipher that could be used.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Software package locking
Date: Sun, 06 Aug 2000 23:51:44 GMT
Trevor, a couple of questions/comments:
1) You mention that there are certain tricks you can do that will foil
debuggers, like overwriting the breakpoint interrupt address, etc.
Which operating system are you talking about? It doesn't seem like this
would work for Win32 programs where the user-level programs don't have
the privileges that you're talking about. Since everything is
practically virtualized, you wouldn't have the control that you
ultimately require. It might work for DOS, but who cares?
If you, yourself, implemented this type of "anti-debugging" protection,
how would you, as a software provider, implement bug fixes? It seems as
though you wouldn't be able to debug your own program effectively.
2) Numega makes their living making quality programs such as Soft-ICE.
If someone comes up with a "way" of foiling them, do you honestly
believe they would stake their reputation and not try to find a way
around it? This is their bread and butter.
I'm not sure how old you are, but I was around for the dawn of the PC
from the earlier 80's onward. Game copying was the biggest problem, and
no technique, ever, has ever been able to foil crackers from copy
protection. Programs such as Copywrite and CopyIIPC would always be
able to crack the latest and greatest software programs, because it was
their specialty.
I'm no cracker, but I do know that running software on untrusted
machines is one of the oldest and most unmanageable problems today. No
matter what trick you may have up your sleeve, there is nothing,
absolutely nothing you can do to stop a determined cracker. No one has
been able to solve it, not by making software "undebuggable", not by
having it check for network card MAC addresses, not by checking for BIOS
info, etc. What if the entire machine is virtualized, down to the BIOS?
These crackers today can read assembly code like they're reading a book.
I don't think anything you can throw at the good ones will be able to
foil them for very long. The only question is whether or not your
software is worth their time and effort.
In article <[EMAIL PROTECTED]>,
"Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote:
> This is a good example of the ego involvement that I previously
mentioned. It
> makes the threat very serious (credible) and quite humorous at the
same time.
>
> Ian Dichkovsky wrote:
>
> > "Trevor L. Jackson, III" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > >blah-blah-blah
> > >......
> > >int 1
> > >......
> > >blah-blah-blah
> > >int 3
> > >......
> > >blah-blah-blah
> > >......
> > >breakpoints
> > >....
> >
> > Guy Do You Know - WHAT IS Soft-ICE ?
>
> Yup. NuMega makes Really Good Stuff.
>
> >
> > It's the powerful debugger, it's the AXE, every cracker MUST have.
> > I have ;-)
> > It runs in DOS, WINDOWS and spit on
> > the interrupt vectors. I tell you - I crack a LOT of programs
> > even with HASP dongle.
>
> Let me phrase this in a way you'll understand:
>
> "This CPU ain't big enough for the both of us!"
>
> Your machine can run soft-ICE or undebuggable software -- not both.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Mon, 07 Aug 2000 00:46:07 GMT
On Sun, 06 Aug 2000 21:03:22 GMT, [EMAIL PROTECTED] (Mike Andrews)
wrote, in part:
>Even the "CATEGORY 1 - NOT SUBJECT TO AUTOMATIC DOWNGRADING"
>material? If _that_ is the case, then the NSA is going to be
>going through files for a _very_ long time.
Precisely that material, because most classified cryptographic
material was not subject to automatic downgrading; this is why it has
to be manually reviewed. Stuff that is *automatically* downgraded gets
shoved out the door without a second look (well, almost...there may be
a check of sorts for the agency involved to request some sort of
waiver).
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Note on text compression
Date: Mon, 07 Aug 2000 00:49:01 GMT
On Sun, 06 Aug 2000 14:32:16 -0700, tomstd
<[EMAIL PROTECTED]> wrote, in part:
>However, you won't be able to edit the file in text editors
>without decoding it first...
>So... You might as well compress the file normally...
That may well be true, but not for that reason. If one is going to
optimize around compressing text, there is no reason to stop at this
simple step, and then feed into a general-purpose compressor of the
LZW type.
The question isn't that the pre-processed text will be treated as
uncompressed; rather, the efficiency of the compound process would
need to be studied.
John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "eboy" <[EMAIL PROTECTED]>
Subject: asymmetric encryption for my keycode generator
Date: Sun, 6 Aug 2000 18:31:31 -0700
I'm a budding shareware author who'd like to code my registration
keycode generator to use asymmetric encryption (like RSA, with private
and public keys, but not necessary RSA per se). I figure I shouldn't
have to worry about keycode generators popping up on cracker sites
within months of release of my product if I can implement this. One
shareware FAQ said doing this wasn't that hard a thing to do. (?)
Anyway, while I know a little about the math theory behind this
encryption, programming it is in another ballpark from where I'm
playing. Can anyone point me to some reference that would be helpful for
a non-math-genius, non-super-geek programmer to accomplish this? (I have
PGP's source code - there isn't enough time in the universe for someone
like me to decipher it) (without help).
I guess what I'm looking for is a basic programming algorithm (perhaps
in pseudocode to just illustrate each step) for encoding and decoding
some plain text using the primes, plus some details about how to
generate the monster primes themselves. I was thinking I could just use
PGP to generate a couple of 2048 bit primes and use those but I can't
find a way to get PGP to tell me what *both* primes are when it
generates a public and private key pair for me. If anyone can guide me
just in this, it would still be a big help...
thanks,
ed
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Secure Operating Systems
Date: Mon, 07 Aug 2000 01:59:39 GMT
Mok-Kong Shen wrote:
> > Actually the original unix was derived from the disenchantment with of multics
> > which was supposed to be a secure OS in addition to all things to all people.
>
> Could you give a reference to that fact? Thanks.
Dennis Ritchie's web site http://www.cs.bell-labs.com/who/dmr/
The problem with Multics, as explained by DMR, was not that Multics was
secure. The problem was that Multics was slow, bloated, and
uneconomical, and was not released as an actual commercial product until
1975, long after interest had died down regarding the system. In some of
his history notes DMR notes that he liked using Multics, but five
million dollars worth of hardware running the Multics simulator on a
G.E. mainframe (since no real hardware was available until 1975) would
barely support 8 users. When Multics was actually released with the
"real" hardware, a triple-processor Level/68 installation would only
support 100 users before slowing to a crawl (by the time you got to 120
users, it was unbearably slow, with often a 5 second response time
between hitting the ENTER key and something happening). By comparison,
IBM mainframes of the same generation in the same price range (around
$6M in 1975 dollars, when that was real money) would support several
hundred users with reasonable response times.
At multicians.org they have some interesting anecdotes from old Multics
developers and users. The anecdotes from the Building M people (Building
M was the converted department store in Phoenix where Honeywell exiled
the Multics development team) are especially interesting. For example,
one guy once proposed to Honeywell higher-ups that they include a $5
time-of-day clock chip in the Multics console to get rid of the errors
where the tape monkey/operator put the wrong time of day at bootup. The
response he got back was that once the change was spec'ed, approved, had
fifteen reams of design documentation written for it, etc., it would add
over $10,000 *per console* to fit a $5 time of day clock into Multics.
He commented that Honeywell's ability to create outrageously slow and
expensive hardware that was outdated the moment it hit the streets was
as astounding as their unwillingness to market those things they had
that WERE innovative -- like Multics.
Anyhow: One reason Multics was slow was its elaborate and rich security
model, which was enforced by a "bag on the side" MMU unit. But that was
by far not the only reason it was slow. I got to read the Multics
architecture manual and was astounded at just how kludged-up this
hardware was. For example, there was a bag-on-the-side decimal
arithmetic unit that would do BCD (Binary Coded Decimal) math for COBOL
and PL/1. There were dedicated index registers that you could not do
math upon, and dedicated math registers that you could not do indexing
with. The architecture was word-addressed, not byte-addressed, so there
was also a bag-on-the-side character operations unit. The MMU unit
itself had pointer registers in it, which were 80 bits even though the
total address space (18 bit segment + 18 bit address) was 36 bits,
because it used the miscellaneous bits for an indirect bit, 2 bits for a
byte address for character operations (Multics was word-addressed), and
assorted other miscellaneous. Pointers in memory were 80 bits also, with
the same cruft, and had to be addressed via a pointer register with the
indirect bit set. I am undoubtedly forgetting some of the idiocies of
this architecture in the haze of 20 years since I last looked at it, but
it is clear that the security baggage was the least of the reasons why
Multics was slow -- the general insanity of the old G.E. architecture
that it was bagged onto was at least as responsible for its astounding
price and lack of performance. Alas, as the Multicians site
remonstrates, Honeywell, given the chance to build hardware for Multics
rather than a bag on the side of inherited G.E. hardware, decided they'd
rather not be in the computer business and cancelled Multics, milked the
GECOS unit a few more years for cash without making any investments into
it, then sold the GECOS unit to Bull.
In any event: Not only does DMR specifically say on his web site that
Unix was a response to the loss of Multics access and that its design
was in part a reaction to the complexity of Multics, design decisions
within Unix clearly show that certain aspects of Multics were being
explicitly rejected. For example, Multics took a long time to start up
processes -- as you'd imagine, with a half-dozen bag-on-the-side units
each of which had registers to flush etc., and with the need to create a
new virtual address space for the new process (which was mapped onto
hard drive, BTW -- Multics did not properly have the concept of a
"file", everything was a segment, and file access was a case of mapping
a segment into the address space and then doing normal loads/stores...
but creating an address space in turn required creating files on disk to
swap that segment to!). It is clear that Unix was designed to take a
short time to start up processes, by having a dedicated swap file rather
than one (or more) per process. It is also clear that certain aspects of
Unix, such as pipelines, were designed around the notion of having
lightweight processes that were chained together to create larger
systems. By contrast, the Multics way of doing things was much like the
Windows DLL way of doing things, where if you needed to access some
functionality, you called it as a subroutine call and waited for the
result. Almost all Multics commands were a thin "wrapper" around the
shared libraries that made up the Multics system, much as Internet
Explorer is a thin "wrapper" around the various DLL's that implement the
HTML widget, the HTTP protocol stack, etc. By contrast, the original
Unix did not have even the concept of a shared library, components were
expected to be stand-alone programs on their own right that used their
stdin and stdout for communicating between each other. I wonder how much
of the animosity between the Windows and Unix crowds stems from this
ancient and long-standing philosophical difference?
--
Eric Lee Green There is No Conspiracy
[EMAIL PROTECTED] http://www.badtux.org
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
