Cryptography-Digest Digest #950, Volume #10 Fri, 21 Jan 00 18:13:01 EST
Contents:
Re: simplistic oneway hash (Michael Wojcik)
Re: Intel 810 chipset Random Number Generator (Guy Macon)
Re: Combination of stream and block encryption techniques (John Savard)
Re: Combination of stream and block encryption techniques (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: Wagner et Al. (Guy Macon)
Re: Transposition over ASCII-coded text (Guy Macon)
Re: McDonald's claims Nobel peace fries [off-topic] (Jerry Coffin)
Re: Wagner et Al. (Guy Macon)
Re: Combination of stream and block encryption techniques (Terry Ritter)
Re: simplistic oneway hash (John Myre)
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
Re: Calculating A^-1 Mod P ("Michael Scott")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: simplistic oneway hash
Date: 21 Jan 2000 21:02:23 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, John Myre <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > I have what is probably a rather unusual request. I need a very simple
> > to code and understand one-way hash. I don't care a great deal as to
> > whether it is truly secure at all, as long as it can be implemented
> > in no more than a couple dozen lines of code in Fortran 90.
> If you really want a hash function, a real one, maybe MD2 would
> do for you. I don't know what it looks like, actually; but it's
> by Rivest, and is a precursor to his MD4 and MD5. Given how simple
> a lot of his algorithms are, maybe MD2 is easy, also. Of course,
> it's been declared "broken", but that's not the same thing as
> saying a programming class can do anything about it.
MD2 is indeed very simple - I've implemented it (or rather something
quite like it) in C and 370 assembler, and it was trivial.
It's mostly table lookup and XOR. See _Applied Cryptography_, 2nd
ed., 441. Full details can be found in RFC 1319 (try
<http://www.cis.ohio-state.edu/Services/index.html> if you don't
already have a favorite source for RFCs).
Schneier says "no weaknesses in MD2 have been found", and cites a
1993 study. Has something been discovered since then? AFAIK, MD2
is out of favor only because it is (relatively) slow.
Just FYI, my MD2-alikes (used for a software licensing scheme,
where obviously security requirements are minimal - the assumption
with software licensing is that anyone who cares enough to really
try will break the scheme by patching the code) used my own
permutation table (I didn't bother getting the real one from RFC
1319), skipped the checksum, parameterized the number of rounds
in the outer loop, and truncated the output to 64 bits. (Again,
I wasn't worried about anyone finding collisions. A CRC-64
would have worked just fine; coding this was more fun.)
--
Michael Wojcik [EMAIL PROTECTED]
AAI Development, MERANT (block capitals are a company mandate)
Department of English, Miami University
Advertising Copy in a Second Language Dept.:
The precious ovum itself is proof of the oath sworn to those who set
eyes upon Mokona: Your wishes will be granted if you are able to invest
it with eternal radiance... -- Noriyuki Zinguzi
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 21 Jan 2000 16:56:55 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning) wrote:
>The error of a crystal oscillator comes from a number of components.
>First of all there's the manufacturing tolerance of the crystal,
>typically 0.01%. Note that in practice this means the error is
>close to -0.01% or +0.01%, a bimodal distribution. It's a bad
>mistake to think of crystal frequencies as normally distributed!
Resistor values, capacitor values, and many other electronics
parts have an interesting distribution caused by the fact that
manufacturers make a large number of parts that vary in value
in a wery wide gaussian fashion, then they sort them by value,
picking out all of the 0.001% values, then 0.01%, 0.1%, 1%,
etc. Thus 1% resistors tends to be equally distributed in the
-1% to -0.1% and +1% to +0.1% ranges.
>Then there's drift, caused by temperature variations of the
>crystal, and also by parameter changes in other components of
>the oscillator (which might include things like power supply
>voltage). Since you mention "thermally random" it sounds like
>you're assuming temperature-induced drift is a random function.
>I'd challenge that. In a typical temperature-controlled environment
>(e.g., a building) it will have a significant periodic component
>because the temperature control system is a servo system.
We often build a little heater servo to keep the crystal at a
constant temperature (but even so the temperature control is
always imperfect - especially when it is optimized for constant
average temperature instead of constant instantanious temperature!)
>There probably is a random component in the frequency variation.
>If you're hard up for a challenge I suppose you could try to
>extract that from underneath all the other components. But for
>goodness sake, WHY? It would be vastly harder, and the bit rate
>vastly slower, than sensible solutions such as a regular noise
>source.
I can see the logic behind trying, but not if you are looking for
a good RNG. But what if you are looking for a cheap RNG?
a cheap crystal (or, better yet, ceramic) oscillator costs very
little, and hooks up to a serial or parallel port easily, and is
pretty much immune to 60 Hz electrical noise. I agree with
everything said about the lack of randomness, though. You really
are just measuring fine differences in the time between reads
of your serial/parallel port. Such a circuit, if Von Neuman
compensated and exlusive or'ed with the output of the best PRNG
you can program, would seem to be, on a practical level, much
superior to the PRNG alone.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Combination of stream and block encryption techniques
Date: Fri, 21 Jan 2000 15:03:23 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>No, sorry. There supposedly is a class of stream cipher which appears
>to function somewhat like a digital filter (input plaintext, output
>ciphertext), and thus does not need or use a key stream, nor do they
>generate a keystream internally. Unfortunately, I have not seen a
>real example, and cannot imagine how any such approach could hope to
>be secure. Others who have seen actual designs have been convinced,
>however.
Well, I agree with your main point.
The most fashionable kind of stream cipher certainly does have the
keystream as its fundamental component; a PRNG's output is just XORed
to the plaintext. This approach, of course, has its problems.
One can do better, by, for example, having two keystreams, and XORing
those keystreams to the message between three substitutions, making a
kind of rotor machine. Then, the "combiner" part of the cipher is part
of cipher as well, and has some importance. This, of course, isn't
something I need to tell you about, as it's a feature of several of
your own cipher designs.
I'm not sure what kind of cipher you are referring to in the quote;
the closest thing I can think of, while it does not have an _internal
state_, does generate a keystream, but from the output ciphertext. An
example would be a block cipher, being used in CFB mode. And that
would be as secure as the block cipher involved, I would think.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Combination of stream and block encryption techniques
Date: Fri, 21 Jan 2000 15:11:47 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>In the attachment below, which is extracted from a recent issue
>of Crypto-Gram,
quoting Bruce:
>But it will be
>a
>lot harder to break for two reasons. One, the internal state is a
>moving
>target and it is a lot harder for an attacker to build model of what is
>going on inside the state.
I may note that, in some of my Quadibloc designs, starting with
Quadibloc III and its Mishmash component, I've tried to take this
virtue of stream ciphers, which I think is very important, and give it
to pure block ciphers.
The basic idea is this:
In a Feistel round, one takes one (unchanged) half of the block, and
uses an f-function and a fixed subkey to determine what is XORed to
the other half of the block.
I divide the block into more than two pieces, so that while a Feistel
round is taking place between two of them, the subkey fed into it is
modified in a very nonlinear fashion based on one of the other pieces.
Of course, since this still depends on other parts of the block,
rather than an internal state which could be completely invisible, so
it can be compared to other methods of making differential
cryptanalysis harder by complicating a block cipher.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Fri, 21 Jan 2000 15:24:10 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote, in part:
>On Thu, 20 Jan 2000 07:41:14 GMT, in <866e6o$i0e$[EMAIL PROTECTED]>, in
>sci.crypt Hammer <[EMAIL PROTECTED]> wrote:
>>One of the interesting things I took from the talk was, in my opinion,
>>they are nearly BEGGING for cryptanalysis of the AES finalists.
>First of all, *OF* *COURSE* they are *begging* for cryptanalysis; they
>certainly are not *paying* anything!
>It was first of all wrong and secondly unwise to base the future of a
>networked society on ciphers acquired by begging and contribution.
Without getting into that specific question here, I might note that
there is a very limited number of mathematicians in the academic
community specializing in cryptography-related matters. A goodly
proportion of them have involved themselves with the AES effort in
some way or other.
Aside from the results so far achieved against some of the candidates
that did not become finalists, however, I'm not surprised that, given
the current state of our knowledge, little useful can be done to show
weaknesses in the AES finalists. As Bruce Schneier noted, they're all
submitted by teams which include some of the world's top cryptanalysts
in the open community, so it's hardly surprising they don't have
weaknesses that even their colleagues could easily find.
Whether NIST puts some money on the table or not, they're not suddenly
going to turn up a rock, and find under it cryptanalysts whose
expertise is decades ahead of those who have already subjected the AES
candidates to the scrutiny that, so far, has had little to say about
the finalists. Leaving out of consideration the rock marked "NSA", of
course.
Also, given the general Administration climate on encryption issues,
it is hardly surprising that NIST was not permitted to spend much in
the way of public funds on an effort that is, to put it mildly,
swimming somewhat against that current.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 21 Jan 2000 17:25:16 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ]
>
>> > IIRC, no. When a user requests access to a secured object, the first
>> > security check the system does is to find whether the user has the
>> > ability to take ownership of the object. If they do, the user is
>> > immediately granted access without any other checks being done.
>>
>> Do you have a reference for this? Under NT v4 sp3-5 removing both local and domain
>> administrator from a file system ACL prohibits access. Note that many resources
>have
>> default access privileges for OWNER/CREATOR and Administrator. The latter would be
>> superfluous if access were automatically granted.
>
>Inside Windows NT, Second Edition, page 313, bullet number 2 (in the
>first set of bullets at the top of the page).
>
>I haven't tested this personally, but David Solomon is _usually_
>pretty dependable, so perhaps I'm misinterpreting what it says...
I am sitting at an NT server 4.0 box, and I just logged on as
Administrator, created a text file, and set the security so that
I have no access (this works on a file by file basis on NTFS
partitions - FAT partitions can only do this to entire volumes.)
I checked and I do have ownership. I cannot read it, move it,
copy it, edit it, or rename it. All that I can do is change the
permissions. I am now logged on as an ordinary user, and now I
have lost the ability to change permissions or take ownership
as well as all the previous restrictions. ( I know from doing
this before that the Admin must take ownership before he can
change permissions).
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Transposition over ASCII-coded text
Date: 21 Jan 2000 17:37:24 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mok-Kong Shen)
wrote:
>
>Markus Eiber wrote:
>>
>> Mok-Kong Shen wrote:
>
>> >(1) Does one use in 'normal' transmission a 'scrambler' to improve
>> > 'error correction'?
>
>> Yes. First of all the data gets scrambled and then redundancy for error
>> correction is added. During transmission there often occur burst errors
>> (several neighbouring bits get falsified) which cannot be corrected (common
>> codes can correct only up to two bits per codeword). So several codewords of
>> information get lost. One can avoid this by scrambling the data, because
>> with descrambling the falsified bits get distributed to a lot of codewords,
>> that is the quantitity of false bits per codeword gets reduced.
>
>I am a bit surprised to know this. The books on error-correcting
>codes don't seem to mention that the data has first to be 'scrambled'
>in some way and then the specific error-correcting code is applied.
>Or do you mean that using an error-correcting code IS by itself doing
>'scrambling'? (The redundancy needed for correction is contained in
>the error-correcting code.) Could you please name a book and the
>page number where one can find that this (i.e. first 'scrambling'
>and then applying a code that has redundancy) is indeed the case?
I am an engineer who manufactures CDs and DVDs. It is part of the
official Red Book CD Spec to take a single chunk of data that has
an error correcting code and splash it all over the CD so that
a bit of dirt will kill 1 bit out of 1000 error corrected blocks
rather than 1000 bits out of 1 error corrected block.
You can drill a 1/8 inch hole in a CD and it will play without
error. At 1.6 uM track spacing and 0.83 minimum pit length,
that's a lot of bits you just destroyed!
[ http://www.sel.sony.com/SEL/consumer/dvd/about_feat.html ]
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: McDonald's claims Nobel peace fries [off-topic]
Date: Fri, 21 Jan 2000 15:41:35 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Either we all die, or we quit fighting :-)
That's not an either/or situation: if we all die, we'll surely quit
fighting.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Wagner et Al.
Date: 21 Jan 2000 17:45:03 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John E. Kuslich) wrote:
>
>There is a subtile point that is being missed here, I think.
>
>It is best illustrated if you read the security faq for the Access
>database on the Microsoft web site. It has all kinds of talk about
>rights and ownership and access denial etc. That is the way it is
>*SUPPOSED* to work.
>
>Just one thing though, our AXcrak program bypasses all this security by
>making relatively small changes to the executable code in the Access
>security dll after it is loaded in memory. Since the DLL is loaded under
>the same privileges as the Access executable, if the user has the
>capability to execute Access code, he *SHOULD* be able to bypass Access
>security.
>
>Now NT is *MORE* secure against this kind of attack, but if a hacker is
>able to gain access to kernel code by any means, the system will do
>anything the hacker can imagine.
>
>I have not actually tested this with a really locked down NT system and
>it may be possible to put a more fine grained control under NT user
>accounts to stifle this process. I don't know for sure.
>
>JK http://www.crak.com Password Recovery software
Does it work on a standard installation of NT when logged on as
a user in the class "Authenticated Users"? and no other class?
How about the classes "Users", "Everyone", and "Guest"?
I am guessing that it won't work because these classes can
execute but not modify the DLL, either on NTFS disk or in memory.
I am an Ethical Hacker and LAN Admin who is very experienced in NT
security, and would welcome the chance to help you to find out if
you can do what you do without Administrator rights. The only
condition is that I believe that security holes should be publicized
so that they get fixed, and that I tell the software's owner before
I publicize the hole so that he can close it before the word gets out.
Not that Microsoft listens, but I still try to warn them.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Combination of stream and block encryption techniques
Date: Fri, 21 Jan 2000 22:50:53 GMT
On Fri, 21 Jan 2000 20:56:23 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>> [...]
>> No, sorry. There supposedly is a class of stream cipher which appears
>> to function somewhat like a digital filter (input plaintext, output
>> ciphertext), and thus does not need or use a key stream, nor do they
>> generate a keystream internally. Unfortunately, I have not seen a
>> real example, and cannot imagine how any such approach could hope to
>> be secure. Others who have seen actual designs have been convinced,
>> however.
>
>Your information is rather vague for me. Could you please give
>literature references so that one could find more concrete stuffs
>about that? I suppose one has to look into that 'black box' to see
>what it really is.
If I had a literature reference I would be citing it.
>> We could of course subdivide stream ciphers into keystream and
>> filtering approaches. But in my view the reason for making categories
>> is to provide insight into consequences of design, and I don't know
>> the consequences here. So at this point the distinction seems rather
>> meaningless.
>
>I don't yet fully understand your sentences. You said on the one
>hand that making a distinction 'provides insight into consequences
>of design ' and on the other hand that you don't know the
>'consequences'. Was that simply a paraphrase of 'making a distinction
>is nonsense' or did you mean something quite different? (Sorry for my
>poor English comprehension capability.)
My purpose in making distinctions between ciphers is to support
comparison and contrast for the purpose of understanding operation.
Seeing a block cipher as a form of Simple Substitution, and, thus,
having all the potential weaknesses of Simple Substitution, is a case
in point.
We can propose any number of new categories, up to and including a
different one for each and every cipher, as is often done, but that is
also analytically unrewarding. The ideal situation is to find a
Boolean distinction which inherently leads to different consequences
on each side. Then we can relate the ciphers on each side as
variations on a theme, with similar essential weaknesses and, perhaps,
strengths.
Since I have no knowledge of the "other" stream cipher category --
other than it exists -- I have no consequences for it, and so find the
use of that category currently unrewarding.
One sort of design like this might be to feed plaintext into a LFSR
with arbitrary feedback taps and an initial state. A plaintext bit
goes in, a ciphertext bit comes out. We might see this as more of a
"scrambler" than a cipher, but it is certainly a form of stream
"ciphering" without a keystream. Now we wonder if it could be made
secure.
It seems to me that a purely linear system should be directly solvable
with known plaintext. Thus I would suppose that in a real system a
good deal of it would be nonlinear, with an appropriate math basis to
somehow support deciphering.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: simplistic oneway hash
Date: Fri, 21 Jan 2000 15:47:16 -0700
Michael Wojcik wrote:
> Schneier says "no weaknesses in MD2 have been found", and cites a
> 1993 study. Has something been discovered since then? AFAIK, MD2
> is out of favor only because it is (relatively) slow.
Well, I don't know why I thought that. Obviously I'm confused;
maybe I misread something or maybe I just dreamed it up.
Anyway, thanks for the correction.
John M.
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 15:06:59 -0800
"CLSV" <[EMAIL PROTECTED]> wrote ...
: "r.e.s." wrote:
: > It's simple to use a 4x13 card layout to implement the *exact* ARC4
: > logic with state-vector length 52 (and modular addition combiner.)
: > The only card-movement is the swap, which takes about 1 second, and
: > the pointer(coin)-movement takes about 10 seconds for both pointers
: > total. I can easily run off 14-15 letters per minute this way, so
: > I think this version of "52 card ARC4" is faster than any other
: > secure card cipher.
:
: Please try it out before you make such claims
: (as Paul Crowley remarked it *is* fun to do).
Please don't be so presumptuous.
I was speaking from hands-on experience.
: I think it can be fast given enough practice but
: 14-15 characters a minute, no way. That is 4
: seconds for one encryption! On my first try I
: achieved a speed of about one char in 50 seconds.
We must be doing something differently.
Here's the routine for the stream generator of "52-card ARC4"
with 4x13 card-layout, placing the coins adjacent to the cards
they point to:
1) start with the x-coin and y-coin at the upper-left card
2) move the x-coin to the next card
3) read the card at the x-coin and move the y-coin that
many cards ahead
4) swap the cards at the x- and y-coins
5) output the modulo sum of the cards just swapped
6) return to step 2
Only step 4 involves moving cards -- it takes ~1 sec --
and moving the coins is now *very* fast because of the mod13
significance of the rows.
--
r.e.s. "Mistr Typo"
[EMAIL PROTECTED]
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: Calculating A^-1 Mod P
Date: Fri, 21 Jan 2000 23:08:55 -0000
HRook <[EMAIL PROTECTED]> wrote in message
news:86a6rp$[EMAIL PROTECTED]...
> I'm trying to teach my self the rudiments of Elliptic Curves. I noticed
that
> when adding two points together, one of the calculations is x3=
> ((y2-y1)/(x2-x1))^2 - x1 - x2 MOD P
>
> This leads to the question, "How does one divide by (x2-x1) MOD P. I
assume
> the answer to that is "multiply by (x2-x1)^(-1) mod P.
>
> So, how do you calculate A^-1 Mod P. I have a vague memory that the
Extended
> Euclidian algorithm can do this, but I can't remember the details of this
> algorithm. Any help would be appreciated.
>
An alternative to the Euclidean algorithm, albeit a much slower alternative,
is to calculate A^-1 mod P as A^(P-2) mod P (assuming that P is prime, which
it is in this context.).
Mike Scott
> Thanks,
> Harv.
> [EMAIL PROTECTED]
>
>
>
>
>
------------------------------
** 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
******************************
