Cryptography-Digest Digest #30, Volume #13 Sat, 28 Oct 00 22:13:01 EDT
Contents:
Re: BEST BIJECTIVE RIJNDAEL YET? (John Savard)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tom St Denis)
Re: Q: Computations in a Galois Field (Tom St Denis)
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: End to end encryption in GSM (Steve Cerruti)
Re: BEST BIJECTIVE RIJNDAEL YET? (John Savard)
Re: IRC crypto ("Our Man In K-Space")
Re: BEST BIJECTIVE RIJNDAEL YET? (SCOTT19U.ZIP_GUY)
Re: ring homomorphic signature and encryption (David A Molnar)
Re: Psuedo-random number generator (Terry Ritter)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Sun, 29 Oct 2000 00:10:01 GMT
On Sun, 29 Oct 2000 00:59:37 +0100, "Brian Gladman"
<[EMAIL PROTECTED]> wrote, in part:
>No it was not a lie and it most certainly does not depend on how Rijndael is
>implemented.
I can't defend the style of his comments, but he doesn't mean that
Rijndael, the block cipher, isn't bijective over the domain of 128-bit
blocks.
He is talking about bijectivity over the domain of messages. And one
certainly can use Rijndael in one of those block cipher modes which
require an _initialization vector_.
Imagine that! Shock! Horror!
That's what he means when he says it's a "lie" that Rijndael is
necessarily bijective. Since Rijndael is the name of a block cipher,
and not an implementation (i.e., like "PGP") I have no idea what it
was he _expected_...
so the point is that he has a true fact in mind, even if it is not
expressed clearly.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Sun, 29 Oct 2000 00:07:26 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>,
> : [EMAIL PROTECTED] wrote:
>
> :> "Obtained a bijection". Consequently, there are 0 bits of probable
> :> known plaintext added.
>
> : Well if you append random garbage how much of it is "probable"? :-)
>
> If you append random garbage, how you you know where the message ends
and
> the garbage begins?
>
> If "SEND MESSAGE DIRECTLY TO US" is accidently transformed into
> "SEND MESSAGE DIRECTLY TO USENET NEWSGROUP|>(54}:'%$gh8JH", that might
> cause some problems...
>
> :> : Like I said I could use a OFB mode and do that... whoopy-doo.
> :>
> :> Not without compromising security - or signing everything.
> :>
> :> A server spitting out encrypted URLs to a client it has
established a
> :> shared secret with it may not necessarily *want* to sign each
> :> message - since that is likely to bump up the bandwidth and take
> :> longer to process.
>
> : You could use a HASH-MAC or something then.
>
> Adding a MAC to every message has processing requirements at either
end,
> and wastes bandwidth in the middle, and requires either an additional
> shared secret, or a public key system with some sort of
> identity-verification infrastructure.
>
> Why not avoid OFB, and totally avoid the problem arising in the first
> place.
Chances are if you use a block cipher and you are encrypting something
trivial like a url changing a bit of the ciphertext will mess up the
plaintext into some non-ascii block.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Sun, 29 Oct 2000 00:10:04 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Bob Silverman wrote:
> >
>
> > Some polynomials most certainly ARE better than others. In
particular
> > a finite field is isomorphic to the quotient ring Z_p[x]/(g(X))
> > where p is the field characteristic and (g(x)) is an ideal generated
> > by a primitive polynomial. This is the polynomial you are looking
> > for. It is much faster to choose a polynomial of low Hamming weight
> > when choosing g(x) as this can make the arithmetic quite a bit
> > faster.
> >
> > And optimal normal bases are even better (when they exist).
>
> I have a question of ignorance. If one uses the same
> formulae, e.g. as in Rijndael, to define substitution,
> would different primitive polynomials lead to substitutions
> that have different desirable properties such as avalanche
> etc.? If yes, would the computationally best polynomial also
> be the best with respect to these properties? Thanks.
Rijndael uses multiplicative inversion and all moduli of equal length
which are irreducible will make sboxes of equal cryptographic
properties. The sboxes will be different.
You could always just use F(x) = ax^-1 + b in GF(2)^n to get a family
of "cryptographically equivalent" sboxes with the same modulus.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 29 Oct 2000 00:20:29 GMT
[EMAIL PROTECTED] (Brian Gladman) wrote in
<TFJK5.2889$zO3.78678@stones>:
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> [EMAIL PROTECTED] (Tom St Denis) wrote in
><8tdl3e$v03$[EMAIL PROTECTED]>:
>>
>> >> >Of course Rijndael is bijective it's a friggin block cipher. You
>> >might
>> >> >as well qualify it as a Square-Based Symmetric Keyed Bijective
>> >> >Invertable Permutation Cipher.
>> >> >
>> >>
>> >> Tom you always shot your mouth off with out little thought,
>> >> What other implementaion of Rijndael is really bijective.
>> >> Example the cipher text output file is one bye 0x13 decrypt
>> >> that with a the key of your choice using CBC. You can't unless
>> >> you hava similar program to MATTS I doubt you really understand
>> >> the concept.
>> >
>> >Rijndael is not defined for 1-byte blocks so technically what "matt"
>> >did is not Rijndael. Of course I could use Rijndael in a feedback
>> >mode (OFB) to get a keystream and encode 5-bit msgs if I like.
>> >
>> >So what?
>>
>> It means when you said Rijndael was bijective by itself
>> it was a fucking lie, It depends on how it is implimented.
>
>No it was not a lie and it most certainly does not depend on how
>Rijndael is implemented.
Yes it does depend on how it is implemented. And Tommy and
any one else knows what I meant by bijectine for Matts program.
It means that any 8bit byte type of file can be thought of as
either a compressed encrypted file or a uncompressed nocrypted
file. There is not gaps or empty spots on other side.
For any file X then compressed-encrypted( uncompressed-decyrpted(X))=X
and likewise uncompressed-decrypted( compressed-encrytped(X))=X
>
>The domain and co-domain for Rijndael (in its AES form) are both the
>sets containing 128-bits and it is most certainly bijective with respect
>to these domains. It seems that you don't understand the concept of
>bijection since you want to claim that this has to be capable of
>operating in arbitrary domains of your choosing, which is incorrect.
>
Matts program uses pure Rijndael and the domain/range is whole set
of 8bit per byte file. That is what I think TIM and I mean for
most of these arguements. You sir don't seem to understand how
it was implemented your mind is stuck in old false concepts
most likely fostered by the NSA's guiding hand in the dumming down
of people. I take it unless your false crypto god explains and blesses
the concept it is closed to your mind.
>I researched compression techniques some years ago from the perspective
>of minimising the statistical difference between their outputs and
>random streams of bits and I did find that artihmetic compression was
>quite a bit better than most other techniques in this respect.
>
>In view of this past work I might have taken your work more seriously if
>you had displayed any ability to present it coherently without
>continuing technical errors, bad language and insults to others. I can
>only assume that you don't want to be taken seriously.
>
If your so stupid to bases the validity of claims on the language
of some one who trys to explaine it to you then. Your not smart
enough to understand the concept. I will give you a clue no matter
who many times I call an sshole an asshole it will not change the
real facts one way or the other, If you belive my words can change
facts if there sugar coated then I agree go look some where else.
Becasue I see no reason to baby your whiny whims.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: Steve Cerruti <[EMAIL PROTECTED]>
Crossposted-To: alt.cellular.gsm
Subject: Re: End to end encryption in GSM
Date: Sun, 29 Oct 2000 00:30:59 GMT
Does this scheme of yours work without modifying the switching equipment
at the service providers facility.
Basically any call that was switched to another network couldn't be
converted to a common form for exchange could it?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Sun, 29 Oct 2000 00:21:04 GMT
On 28 Oct 2000 16:45:01 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote, in part:
>[EMAIL PROTECTED] (John Savard) wrote in
><[EMAIL PROTECTED]>:
>>http://home.ecn.ab.ca/~jsavard/crypto/mi060303.htm
> I am flubergasted it is much more than I expected.
>However I may have given Matt some of the idea but He
>is the one who incorporated in to arithmetic coding
>not me.
I'll look this up. I thought you discussed applying the bijective
principle to arithmetic coding very shortly after your first posts
about bijective Huffman. Of course Matt coded his own program.
> I will have to take a closer look at your stuff.
>But what I fail to understand is you only seem to talk
>of code. Why don't you write the actual code?
Well, I haven't had a great deal of time. And I don't think that what
I would write would be so much better than what is already available,
such as PGP, that my writing code would fill a real need.
Sure, I could write a *really* secure encryption program that depended
on a shared secret key. But as long as people need public keys to get
started, nothing I do would be more secure than PGP. (And there would
be scads of junk in the swap file after it finished anyhow, too, but
that is not _always_ an issue.) And I haven't invented a way to get
people to memorize better passphrases either.
Much more important than details like better compression, in my
opinion, is addressing the public-key versus passphrase problem. There
is a great way around that, that allows people to have real security.
Unfortunately, it's patented. EKE. Until that patent expires (although
there are alternatives, but none are quite as good), I know of no way
to combine security with practicality that *really* adds something to
what the regular programs already do.
Instead, my web page _does_ fill a real gap. There are lots of
encryption programs out there - and many of them are quite good. There
are also a number of nice encryption pages, but mine does add some
content that otherwise most people wouldn't even be able to find even
if they went to the library in addition to using the Internet - a
"getting off of one's seat" type of activity I heartily endorse.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Our Man In K-Space" <[EMAIL PROTECTED]>
Crossposted-To: alt.slack
Subject: Re: IRC crypto
Date: Sun, 29 Oct 2000 01:37:04 -0000
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
lo, ime the guy who wrote that. anyone interrested should note that
the beta had a few bugs, all of which surfaced have gone, maybe a few
more added in... but hey :) latest build is beta 15, and beta 3 for
the additional ssl enhancements.
thanks :)
http://noomorph.virtualave.net/mirc_dev/
Lost
0xDD7D8EE0
=====BEGIN PGP SIGNATURE=====
Version: PGP 6.5.8
iQA/AwUBOft/P2ECkjbdfY7gEQIkRACdFuwfwf6xch1AbxJBhc0HRpBgemcAoIh/
4is1hLO7HayLonE6t/kt4Kfr
=/6cU
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: 29 Oct 2000 01:31:04 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On 28 Oct 2000 16:45:01 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote, in part:
>>[EMAIL PROTECTED] (John Savard) wrote in
>><[EMAIL PROTECTED]>:
>
>>>http://home.ecn.ab.ca/~jsavard/crypto/mi060303.htm
>
>> I am flubergasted it is much more than I expected.
>>However I may have given Matt some of the idea but He
>>is the one who incorporated in to arithmetic coding
>>not me.
>
>I'll look this up. I thought you discussed applying the bijective
>principle to arithmetic coding very shortly after your first posts
>about bijective Huffman. Of course Matt coded his own program.
But discussing and write code are two diferent things. Which
is one reason I don't like arguing with you. Since I like to
see code. I misunderstood what you wrote. I thought you implied
I coded the arithmetic one first. I coded the huffman one first.
>
>> I will have to take a closer look at your stuff.
>>But what I fail to understand is you only seem to talk
>>of code. Why don't you write the actual code?
>
>Well, I haven't had a great deal of time. And I don't think that what
>I would write would be so much better than what is already available,
>such as PGP, that my writing code would fill a real need.
>
>Sure, I could write a *really* secure encryption program that depended
>on a shared secret key. But as long as people need public keys to get
>started, nothing I do would be more secure than PGP. (And there would
>be scads of junk in the swap file after it finished anyhow, too, but
>that is not _always_ an issue.) And I haven't invented a way to get
>people to memorize better passphrases either.
>
>Much more important than details like better compression, in my
>opinion, is addressing the public-key versus passphrase problem. There
>is a great way around that, that allows people to have real security.
>Unfortunately, it's patented. EKE. Until that patent expires (although
>there are alternatives, but none are quite as good), I know of no way
>to combine security with practicality that *really* adds something to
>what the regular programs already do.
>
>Instead, my web page _does_ fill a real gap. There are lots of
>encryption programs out there - and many of them are quite good. There
>are also a number of nice encryption pages, but mine does add some
>content that otherwise most people wouldn't even be able to find even
>if they went to the library in addition to using the Internet - a
>"getting off of one's seat" type of activity I heartily endorse.
If you like to wrote but I see little point designing without
codeing since when one codes that is when one really sees the
detail and can test it. I hate writting.
>
>John Savard
>http://home.ecn.ab.ca/~jsavard/crypto.htm
>
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: ring homomorphic signature and encryption
Date: 29 Oct 2000 01:31:12 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
> (There _is_ a group homomorphism, in fact isomorphism, between
> (Z_p^*,*) and (Z_{p-1},+), namely f : Z_p^* -> Z_{p-1} given by
> f(x) = log x. However, you need to be able to compute the discrete
> log in Z_p to compute f, so it is unlikely to be useful.)
Yes - it's maddeningly close and yet so far. (to use a cliche)
> And I suspect what David Molnar is asking for is a ring homomorphism
> on Z_N, i.e., a map which is simultaneously a group homomorphism with
> respect to both (Z_N,+) and (Z_N^*,*).
Yes, that's what I was looking for. I am still interested in
encryption schemes which are ring homomorphisms, though. As I expect are
a number of other people, since it seems like something which might be
useful.
Right now, however, I would settle for a signature scheme which is a
group homomorphism with respect to (Z_N, +) (not (Z_N^*, *) )...
-David Molnar
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Psuedo-random number generator
Date: Sun, 29 Oct 2000 02:08:18 GMT
On Sat, 28 Oct 2000 16:05:57 -0700, in
<[EMAIL PROTECTED]>, in sci.crypt David Schwartz
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>
>> > This may be true for some theoretical definition of computer, but it is
>> >certainly not true for real computers. As a trivial counterexample,
>> >remember that all computers are subject to quantum effects and have
>> >small but finite probabilities of making unpredictable errors. For a
>> >more realistic counterexample, consider true quantum randomness in the
>> >offsets between the CPU oscillator and the clock oscillator on a network
>> >card. This can be measured in software.
>>
>> I deny that any software-detectable "true quantum randomness" exists
>> between crystal oscillators. Almost the only unpredictable thing
>> about crystal oscillators is their phase with respect to some absolute
>> reference after power-on. Subsequently, excepting minor and generally
>> predictable thermal drift effects, there is no phase change. That is
>> the whole point of having a crystal oscillator.
>
> Not at all. When an uncompensated quartz crystal oscillator is about to
>flip between a zero and a one, the exact instant of the flip is due
>primarily to microscopic thermal effects inside the oscillator. This can
>be measured by comparing one quartz oscillator against another that is
>far enough away to experience dissimilar thermal effects.
The oscillation part of a crystal oscillator is linear and runs on
sine waves, not flips. When a crystal oscillator is used as a digital
clock, a linear to digital conversion is applied, and, as usual, noise
can affect the exact instant of that clocking. This is a sort of
"phase noise," and, because it is based on thermal noise, is indeed a
"quantum" effect.
However, this sort of "phase noise" is typically on the order of
picoseconds, while the main clock is on the order of nanoseconds.
This "phase noise" can of course be measured with special equipment.
But such measurements are vastly, vastly below what can be measured by
conventional software, which was the original claim, now conveniently
recalled for us here:
>>>For a more realistic counterexample, consider true quantum randomness
>>>in the offsets between the CPU oscillator and the clock oscillator
>>>on a network card. This can be measured in software.
> Pinging a router and capturing the timestamp of the ping return with a
>500Mhz Pentium's TSC gets you about 4 bits of entropy.
Network operation timings have absolutely nothing to do with "true
quantum randomness in the offsets between the CPU oscillator and the
clock oscillator."
>That is, there is
>massive unpredictability involved in the offset between the processor's
>clock, the network card's clock, the router network card's clock, and
>the router CPU's clock.
First of all, those are not quantum variations.
Next, the "massive unpredictability" is at best a single phase
difference resulting from unknown power-on timings. Where it is
possible to measure the phase of one high-speed clock against another,
this can be detected and measured. After that, clock phase variations
are generally predictable.
Last, the network system circuit design specifically works to
synchronize, re-time or ignore phase differences in high-speed clocks,
so it is generally *not* possible to measure phase differences in
high-speed clocks.
> The amount of true quantum randomness is very small. The major source
>of the randomness is classical, due to micro-thermal variations in the
>components.
The major source of network operations variations is the nature of
network communications itself. Unfortunately, network traffic is
generally exposed, and so is less than ideal as a source of entropy,
and in any case certainly is not a quantum effect.
>> Asynchronous clock signals, especially of different frequency, may
>> produce a random-like interaction, but most of that is not random at
>> all, but is instead deterministic based on starting phase and
>> frequency, thus giving predictable results.
>
> Grossly predictable results. But the low-order bits are not.
No. In general, the entire interaction is predictable, including
low-order bits. What unpredictability remains is largely in "phase
noise" effects, in the picosecond range. So if we assume a mean phase
noise value as high as 100 ps and a 10 MHz sample rate, then about 1
out of 1000 samples may be changed due to a/d conversion noise. But
each change, of course, simply represents an advance version of the
state which will occur in the next sample. Under these assumptions,
the difference is a single bit, 1 time in 1000.
>> In general, crystal oscillators are one of the worst possible choices
>> for exposing quantum effects.
>
> If done wrong, anything is a bad choice.
Hey, I have an idea: Why don't you just show us your design for
pulling random bits out of crystal oscillators? But no, wait, you
said "software," didn't you? Well, I can hardly wait.
In general, the use of crystal oscillators is one of the worst
possible ways to expose quantum effects.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
