Cryptography-Digest Digest #29, Volume #13 Sat, 28 Oct 00 20:13:01 EDT
Contents:
sqrt correlations (Benjamin Goldberg)
Re: DATA PADDING FOR ENCRYPTION (Bryan Olson)
Find Your Family Tree ([EMAIL PROTECTED])
Re: Psuedo-random number generator (Bryan Olson)
Re: how i decode this?? (Andre van Straaten)
Re: Q: Computations in a Galois Field ("Brian Gladman")
Re: ciphertext smaller than blocksize (Tim Tyler)
Re: DATA PADDING FOR ENCRYPTION (Tim Tyler)
Re: DATA PADDING FOR ENCRYPTION (Tim Tyler)
Re: Rijndael and PGP (JPeschel)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tim Tyler)
Cracking of MasterKey Completed (JPeschel)
Re: Psuedo-random number generator (David Schwartz)
Re: Cracking of MasterKey Completed (SCOTT19U.ZIP_GUY)
Re: DATA PADDING FOR ENCRYPTION (SCOTT19U.ZIP_GUY)
Re: ring homomorphic signature and encryption ("John A. Malley")
Re: BEST BIJECTIVE RIJNDAEL YET? ("Brian Gladman")
Re: Is OPT the only encryption system that can be proved secure? ("Trevor L.
Jackson, III")
----------------------------------------------------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: sqrt correlations
Date: Sat, 28 Oct 2000 21:05:38 GMT
Could someone tell me where (on the web) I could find a paper, or
papers, describing how correlations in the digits of a square root can
allow an attacker to learn the original number?
Also, does anyone know if a sqrt stream is made more secure by
decimation? (decimation is various forms of shrinking, most commonly
discussed with LFSRs). The eriko-chan cipher uses a decimated sqrt
stream as a keystream.
--
"Mulder, do you remember when I was missing -- that time that you
*still* insist I was being held aboard a UFO?"
"How could I forget?"
"Well, I'm beginning to wonder if maybe I wouldn't have been
better off staying abo-- I mean, wherever it was that I was
being held." [from an untitled spamfic by [EMAIL PROTECTED]]
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: Sat, 28 Oct 2000 20:56:27 GMT
Tim Tyler wrote:
> The idea is to encrypt the last full block *again* truncate
> this to the size of any short block at the end and XOR this
> with the plaintext of the short block (rather than encrypting
> that with the cypher).
That constitutes encrypting the last partial block with CFB
mode. CFB mode handles plaintext of any size without
padding. It expands the message only by the size of the IV.
There's also ciphertext-stealing, which is adaptable to CBC
mode. Again it only expands by the size of the IV.
> This means that the OFB-like bit-flipping attacks can only
> be applied to the short block at the end. (2nd e. p. 195
> for details).
Page 195 does not discuss attacks, only errors. None of the
standard block chaining encryption modes detect
modification. Use a MAC for authentication.
> This method gets a bijection - at the expense of not
> encrypting the end of the file very securely.
When using an authentication mechanism, there's nothing
wrong with the last partial block. Without the
authentication, the entire file is vulnerable.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Find Your Family Tree
Date: Sat, 28 Oct 2000 21:08:01 GMT
http://www.nvo.com/addis
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 21:17:52 GMT
slak- wrote:
> Would it not be feesable to use your sound blaster to
> scan a number of radio-frequencies and do a series of
> calculations based on the results to generate a seed?
> I've been thinking about it, but my mediocre
> programming knowledge doesn't let me do too much,
> although I'm learning :)
A microphone is probably cheaper and better than a radio.
Be sure and test that you're really getting the audio. For
random noise you could hang it at the power-supply fan vent.
Sample as fast as you can, and I'd suggest a cryptographic
hash as the "series of calculations".
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Andre van Straaten <[EMAIL PROTECTED]>
Subject: Re: how i decode this??
Date: Sat, 28 Oct 2000 22:06:17 GMT
> Eduardo Hernandez <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>> how i decode or decrypt this kind of messages???
>>
>> eg.
>>
>> MQ'(E<H8.=8"AKS*7C$$KTGXXF_-D:M+&![;'PY61C0<B$-?E1B.^XKPMT,:T
>> MI38V9-JN7+H/[C2^9*R1&X`4;HUTLE$7D4D].B7JPZMTA2Z?;U9,^N$C8_C8
>> ME?!/K?>7ZBM]H\OAPIPI+OR<S>::]>K<ESP$9RULS>)*[[@DAV:#LU\;+:'C
>> MQH#&RZW06I'F7I^>QHD[!(_\_?DPX%&I`Y@NV9MZ!\%JD)8#%&YML5L>VG[6
>> MCL^M[2!5+;[U\[?&[R%KO^T/&=V9,OV6-VI7G`K-Z&<-,.6_$VJZ&[#XE"6`
>> M`:G/;Q3+T]+K8Q3^+KYQGEU-.2@A\IM6_E9Y)+&G!QO<];U:5P4/OC,E$TU]
>> M`*@:H4DZVY?`B!&5%^OL_'O039X;>T[&K/U^7;E"&QPS$[.8R:[R:NI&)>/>
>>
>>
Looks like uu encoded. If your mail or news program doesn't encode it, name the file
*.uue
on MS Windows and double-click on it if you have WinZip installed, or look for a uu
decode
program (freeware at www.tucows.com or simtel or ...).
BTW: uuencoded has nothing to do with encryption.
If the file uu decode properly, but is still unreadable, don't post this
presumably
encrprypted file again. Most people don't like this kind of pointless homework.
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
______________________________________________
flames please to [EMAIL PROTECTED]
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Q: Computations in a Galois Field
Date: Sat, 28 Oct 2000 23:14:39 +0100
"Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Bob Silverman wrote:
> >
> > In article <8t9t5f$tf2$[EMAIL PROTECTED]>,
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > >
> > > No polynomial is "better" then another. There are about 25
> > > polynomials of nine bits (8-bit fields).
> > >
> > > I suggest you read the Rijndael paper about manipulating the
> > > elements. If you have any specific questions please ask.
> >
> > Yes. Please ask. But don't ask Tom.
> >
> > Once again Tom finds it necessary to make assertions based upon his
> > ignorance. Do us all a favor, Tom, and stop misleading others.
> >
> > 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.
>
> Although it's true that some polynomials are faster than others, that
> does not necessarily make them better -- especially since, in most
The basic problem here is that contributors have had their own (initially
unstated) view of what 'better' means to them.
> cases, the polynomial is only used to create some global variables, or
> in the key setup (to make tables of some kind). Suppose that Rijndael
> used a different poly than 0x11B. After all the long term tables are
> created (which may be done before the main compile, and stuck into an
> include file), how much speed difference is there because of the
> different poly? Unless I'm mistaken, 0.
In terms of implementation there are real situations in which the field
representation used can have a big impact on efficiency in terms of the
speed achieved in finite field operations.
The fact that there are situations, such as those you describe, where this
efficiency advantage is not achieved does not in any way change this.
Given without careful caveats, the answer that 'all polynomials are equal'
is an incorrect generalisation since they are equal in some respects but
unequal in others.
Brian Gladman
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: ciphertext smaller than blocksize
Reply-To: [EMAIL PROTECTED]
Date: Sat, 28 Oct 2000 22:06:13 GMT
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
[messages shorter than the block size]
: Use either OFB (output feedback mode) or CFB (cipher feedback mode).
: The problem with these, is if you're not using an IV, there are
: weaknesses.
There are problematical weaknesses - even with an IV.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ ILOVEYOU.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Reply-To: [EMAIL PROTECTED]
Date: Sat, 28 Oct 2000 22:12:39 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
:>Here's what Applied Cryptography has to say about padding:
:>
:>``Pad the last block with some regular padding - zeros, ones, alternating
:> ones and zeros - to make it a complete block. If you need to delete the
:> padding after decryption, add the number of padding bytes as the last
:> byte of the last block.'' -2nd ed. p. 190.
:>
:>So far, not very good (from the known-plaintext POV). However,
:>we also have a method which does not change the size of the message.
:>
:>The idea is to encrypt the last full block *again* truncate this to the
:>size of any short block at the end and XOR this with the plaintext of
:>the short block (rather than encrypting that with the cypher).
:>
:>This means that the OFB-like bit-flipping attacks can only be applied to
:>the short block at the end. (2nd e. p. 195 for details).
:>
:>This method gets a bijection - at the expense of not encrypting the end
:>of the file very securely.
: Tim I may by wrong but I don't see how it gets a bijection of all
: 8 bit file to all 8 bit files. Example if the encrypted file is one
: byte long, If the method above that you mention is bijective how
: did this encrypted one byte file occur?
The case of a single block is not explicitly mentioned.
It can be dealt with (for example) by encryping a block of zeros
and XORing that with the plaintext.
I.e. "encrypt the last full block *again* (or encrypt zero if there
is no full block in the first place)...".
I believe this method gets a bijection - though any fractional last
block is susceptible to bitflipping attacks - and such problems would
not normally be tolerated.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: DATA PADDING FOR ENCRYPTION
Reply-To: [EMAIL PROTECTED]
Date: Sat, 28 Oct 2000 22:34:44 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Bryan Olson wrote:
:> : [...] can you imagine someone so clueless as to expect his message
:> : space won't have enough redundancy to cover a couple hundred (or
:> : several thousand) bits of key equivocation?
:>
:> Surely it is *very* easy to imagine such a case.
:>
:> What about the man sending short messages, for example?
: "Message" yes, that's what the OTP is all about. "Messages"
: sounds he doesn't really have a grasp of the requirements for
: information theoretic security.
Your implication that someone sending some short messages with a block
cypher has a screw loose appears to be unwaranted.
I suppose you are suggesting he should be using an OTP, and not bothering
with a padding scheme?
Using an OTP may require significantly more key material. Note that
the redundancy you mentioned arises with messages longer than the unicity
distance. This may be significantly greater than the length of the
normal block cypher's key. Consequently, using an OTP may require
far larger keys than are on the cards.
It's probably simpler to use a padding scheme that adds zero bytes of
known plaintext to the message, thus avoiding the problem completely.
:> What about the man who forwards an encrypted message he has
:> intercepted back to his HQ for decipherment?
: Then he normally wouldn't even have a way to estimate the redundancy.
So he won't know "whether it has enough redundancy". Why should he be
so clueless as to /expect/ that it doesn't have such a redundancy when he
doesn't know much about his message.
The attacker that intercepts his message may be unable to distinguish a
correct decrypt from a random stream (without lots of work).
Consequently adding up to 127 zero bits to the file might make
finding a termination criteria much easier for him.
Redundancy is only useful to attackers if they can detect it.
It's not a case of whether /I/ can imagine someone so clueless as
to have such expections - it's why /you/ can't see that a perfectly
intelligent and rational person could have such expectations.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Rijndael and PGP
Date: 28 Oct 2000 22:47:48 GMT
Richard Heathfield [EMAIL PROTECTED] writes:
>"SCOTT19U.ZIP_GUY" wrote:
>>
>> [EMAIL PROTECTED] wrote in <8tciik$31q$[EMAIL PROTECTED]>:
>>
>> >In article <[EMAIL PROTECTED]>,
>> > [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> >> I disagree strongly.
>> >Right there you've given enough information for a reasonable person to
>> >strongly agree. Of course it doesn't hurt that you have contradicted
>> >the statements of every major cryptanalyst, made a mockery of yourself,
>> >and been a pretender to the thrown for as long as I've been around.
>> >
>>
>> I'm retired so I don't have to kiss ass. I am still allowed
>> to tell the truth. I have never been a pretender to the throne
>
>That's not what he said. He said "thrown", not "throne". It was a pun,
>which is a kind of joke based on homophones which have distinctly
>different spellings and meanings.
>
A pun? I'd say Ashwood accidentally misspelled throne, as "pretender
to the thrown" doesn't make any sense. Doesn't seem to qualify
as a humorous non-sequitur, either.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 28 Oct 2000 22:45:21 GMT
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.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Cracking of MasterKey Completed
Date: 28 Oct 2000 23:08:42 GMT
All parts of Casimir's essay, "The
Cracking of MasterKey v1.02/1.05"
are now up on my site. Part C
is a batch file that fetches the
encrypted password from the Windows
Registry. Part D is the source
code (.cpp). I've included a zip
file that's a home for the executable,
the batch file, the original text
of the essay, and a sample password
to crack.
Find it on the "Key Recovery Resources"
page.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 16:05:57 -0700
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.
Pinging a router and capturing the timestamp of the ping return with a
500Mhz Pentium's TSC gets you about 4 bits of entropy. 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.
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.
> 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.
> In general, crystal oscillators are one of the worst possible choices
> for exposing quantum effects.
If done wrong, anything is a bad choice.
DS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking of MasterKey Completed
Date: 28 Oct 2000 23:22:59 GMT
[EMAIL PROTECTED] (JPeschel) wrote in
<[EMAIL PROTECTED]>:
>All parts of Casimir's essay, "The
>Cracking of MasterKey v1.02/1.05"
>are now up on my site. Part C
>is a batch file that fetches the
>encrypted password from the Windows
>Registry. Part D is the source
>code (.cpp). I've included a zip
>file that's a home for the executable,
>the batch file, the original text
>of the essay, and a sample password
>to crack.
>
>Find it on the "Key Recovery Resources"
>page.
>
>Joe
>__________________________________________
>
>Joe Peschel
>D.O.E. SysWorks
>http://members.aol.com/jpeschel/index.htm
>__________________________________________
>
>
JOe I know you and Casmir enjoy cracking weak
code. Though he was never capable of doing anything
agains scott16u or scott19u, But I would like your and
or his opinion of Matts bijective bicom program.
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: DATA PADDING FOR ENCRYPTION
Date: 28 Oct 2000 23:27:32 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>
>:>Here's what Applied Cryptography has to say about padding:
>:>
>:>``Pad the last block with some regular padding - zeros, ones,
>:>alternating
>:> ones and zeros - to make it a complete block. If you need to delete
>:> the padding after decryption, add the number of padding bytes as the
>:> last byte of the last block.'' -2nd ed. p. 190.
>:>
>:>So far, not very good (from the known-plaintext POV). However,
>:>we also have a method which does not change the size of the message.
>:>
>:>The idea is to encrypt the last full block *again* truncate this to
>:>the size of any short block at the end and XOR this with the plaintext
>:>of the short block (rather than encrypting that with the cypher).
>:>
>:>This means that the OFB-like bit-flipping attacks can only be applied
>:>to the short block at the end. (2nd e. p. 195 for details).
>:>
>:>This method gets a bijection - at the expense of not encrypting the
>:>end of the file very securely.
>
>: Tim I may by wrong but I don't see how it gets a bijection of all
>: 8 bit file to all 8 bit files. Example if the encrypted file is one
>: byte long, If the method above that you mention is bijective how
>: did this encrypted one byte file occur?
>
>The case of a single block is not explicitly mentioned.
>
>It can be dealt with (for example) by encryping a block of zeros
>and XORing that with the plaintext.
>
>I.e. "encrypt the last full block *again* (or encrypt zero if there
>is no full block in the first place)...".
>
>I believe this method gets a bijection - though any fractional last
>block is susceptible to bitflipping attacks - and such problems would
>not normally be tolerated.
I am not saying thats its not possible, It is just that the
procedure is incomplete and can't be directly bijective unless
it tells explicitedly how to create an ecnrypted file shorter than
a block. That is if it really is bijective for every possible file
as an encrypted or plaintext file.
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: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: ring homomorphic signature and encryption
Date: Sat, 28 Oct 2000 16:54:37 -0700
David Wagner wrote:
>
> John A. Malley wrote:
> >I thought Z_p and Z_p^* ARE already homomorphic to each other when p is
> >a prime.
>
> No, they're not. You're probably getting confused about what the
> group operation is; under traditional conventions, when you say
> "the group Z_p" this is typically taken to refer to addition as
> the group operation, whereas the group operation in Z_p^* is
> multiplication.
Yes! That's it. When looking for a homomorphism between a group with
addition as its operator and a group with multiplication as its
operator, I must look for a mapping phi() such that phi(x+y) =
phi(x)*phi(y).
And going the other way, when looking for a homomorphism between a group
with multiplication as its operator and a group with addition as its
operator, I must look for a mapping psi() such that psi(x*y) =
psi(x)+psi(y).
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Date: Sun, 29 Oct 2000 00:59:37 +0100
"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.
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.
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.
Brian Gladman
------------------------------
Date: Sat, 28 Oct 2000 20:08:59 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Is OPT the only encryption system that can be proved secure?
Richard Heathfield wrote:
> That's the marvellous thing about the ISO C Standard. If you write your
> programs as ISO C conforming programs, you can be /sure/ of one of two
> things:
>
> a) your program will port correctly to another ISO C conforming
> implementation, even on a completely different operating system, or
> b) if it doesn't, you have a valid complaint against the compiler
> vendor.
>
> I've never had to resort to b).
This belongs in another news group with the rest of the enclosing thread. NTL,
this statement amounts to the claim that you've never encountered a bug in a C
compiler claiming ISO conformance. There could be many reasons why this claim
might be true. Lack of bugs in C compilers claiming conformance is not one of
them.
------------------------------
** 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
******************************
