Cryptography-Digest Digest #494, Volume #13 Thu, 18 Jan 01 23:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Where can I find software tools for Known-text decryption ("Matt Timmermans")
Light Computers (Greggy)
Re: Comparison of ECDLP vs. DLP (DJohn37050)
Re: [H] one-way hash functions ("Joseph Ashwood")
Re: Comparison of ECDLP vs. DLP (Roger Schlafly)
Re: Differential Analysis (Benjamin Goldberg)
Re: SAC question (Benjamin Goldberg)
Re: Comparison of ECDLP vs. DLP (Wei Dai)
Re: using AES finalists in series? (Benjamin Goldberg)
Re: Membership Signature Scheme (Splaat23)
Re: using AES finalists in series? (Bryan Olson)
Re: Dynamic Transposition Revisited (long) (Benjamin Goldberg)
Re: Light Computers (Benjamin Goldberg)
Re: block algorithm on variable length without padding? ("Scott Fluhrer")
AES sbox generating code. (Benjamin Goldberg)
Re: Differential Analysis (Tom St Denis)
Re: Any good source of cryptanalysis source code (C/C++)? (Glide)
Re: SAC question (Tom St Denis)
Re: Kooks (was: NSA and Linux Security) ([EMAIL PROTECTED])
Re: Kooks (was: NSA and Linux Security) ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 19 Jan 2001 01:07:18 GMT
I thank you for an interesting post.
Some people will be quite shocked at the unconventional nature of
transposition, though.
I will just content myself with noting that, particularly if the units
being transposed are larger than a bit, if one relies exclusively on
transposition, some aspects of the plaintext are preserved in the
ciphertext. (Even if one transposes single bits, the output has the
same number of 1 bits as the input.)
Hence, I am going to recommend what you probably realize quite well in
any case for the benefit of other readers: that while transposition is
a worthy encipherment method that is unjustly neglected, it should not
be used completely alone; it is worthwhile to use it in combination
with substitution.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Where can I find software tools for Known-text decryption
Date: Fri, 19 Jan 2001 01:33:34 GMT
Oh. You're looking for a "known plaintext attack" on the cipher. There is
no way to do this algorithmically in the general case -- a known plaintext
attack against a cipher is something that is designed specifically for that
particular cipher, usually by cryptographers who know what they're doing.
Do you have a particular cipher in mind? Both CSS, and the PKZIP stream
cipher have famous known-plaintext attacks implemented in public-domain
software. I don't know of any others that have actually been implemented
and distributed.
<[EMAIL PROTECTED]> wrote in message news:946lft$tgq$[EMAIL PROTECTED]...
> It is my understanding that when you know some of the test in a file,
> the rest of the file can be decrypted.
>
> don c
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Light Computers
Date: Fri, 19 Jan 2001 01:30:56 GMT
http://dailynews.yahoo.com/h/nm/20010118/sc/light_dc_1.html
Scientists Hold Light Particles Captive
By Maggie Fox, Health and Science Correspondent
WASHINGTON (Reuters) - It may be impossible to grasp a sunbeam, but
physicists said on Thursday they had managed to capture light, play
with it a while, and then let it go.
They said their achievement could speed the development of quantum
computers, which would calculate millions of times faster than present-
day computers, and inventions that no one has yet dreamed of.
The secret was slowing down atoms of rubidium so they would not absorb
the photons, as atoms usually do, the team at the Harvard-Smithsonian
Center for Astrophysics in Cambridge, Massachusetts said.
Instead, they report in the Jan. 29 issue of Physical Review Letters,
the atoms change their magnetic spin just slightly -- a change that
allows them to store information from the photons. Hitting the cloud of
hot rubidium gas with another laser pulse releases the first pulse,
they said.
Usually, when a photon hits an atom -- even an atom in a highly
reflective mirror -- it gets absorbed and heats up the atom, putting it
into what physicists call a higher energy state.
``Here, the light pulse does get dimmer and dimmer and slower and
slower,'' Ben Stein, a spokesman for the American Institute of Physics,
said in a telephone interview.
``The light does disappear but instead of getting absorbed in the usual
way as it heats up atoms, it goes to storing its information in the
atoms in the form of something called spin.''
This little change could work just like the switches in computers.
``You could store zeros and ones just like they are stored in
computers,'' Stein said. But it would happen much faster and, using the
sometimes weird laws of quantum mechanics, one photon could have more
than one ``on-off'' position at the same time.
Ultra-Fast Quantum Computers
This property could be used to make ultra-fast quantum computers.
Even better, the physicists were able to get the light back out of the
rubidium.
``Later on, you can shine another light pulse which coaxes the atoms
into spitting out the original light wave,'' Stein said. ``The beam of
light will come out again.''
Stein said the applications, beyond the use of light in a quantum
computer, are not clear. But the same was true of lasers when they were
first invented.
``No one foresaw their use in supermarket scanners and so on,'' he
said.
In a second paper, to be published in next week's issue of the journal
Nature, Lene Hau and colleagues at the Harvard/Rowland Institute of
Science said they had done a similar experiment using ultra-cold gas.
They used sodium atoms for their experiment, and were also able to
store the light and get it back out again.
``We believe that this system could be used for quantum information
transfer,'' they wrote in their report.
Light travels in packages called photons, which have properties
resembling both waves and particles. In nature it moves at 186,000
miles (300,000 km) per second, the fastest speed possible according to
Einstein's theories
--
13th amendment to the US Constitution:
If any citizen of the United States shall accept, claim, receive,
or retain any title of nobility or honour, or shall, without the
consent of Congress, accept and retain any present, pension, office,
or emolument of any kind whatever, from any emperor, king, prince,
or foreign power, such person shall cease to be a citizen of the
United States, and shall be incapable of holding any office of
trust or profit under them, or either of them.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 19 Jan 2001 01:51:23 GMT
Subject: Re: Comparison of ECDLP vs. DLP
Wei Dai wrote:
"In article <[EMAIL PROTECTED]>, djohn37050
@aol.com says...
> DJ: Again you think there is no RSA PKV, but there is, how much to use of it
is
> a cost/benefit decision.
Ok, I should have expected that a ZKP would exist for RSA public key
validity. But certainly it's not in common use, and your point was that
no signature should be considered valid unless the signing key has been
validated. You seem to have changed your mind by talking about a
cost/benefit decision.
Thanks for the reference to the paper, BTW. Here's the URL for everyone
else: http://grouper.ieee.org/groups/1363/StudyGroup/KeyVal.html.
I question the usefulness of the non-repudiation aspect of PKV (as
opposed to the aspect of defense against subgroup attacks). Bob's paper
is motivated by the consideration that someone might be able to
repudiate an RSA key that's not the product of nearly equal primes. But
if someone is allowed to repudiate such an RSA key, what prevents him
from repudiating an RSA key with low entropy? As far as I know there is
no way to prove that a key has sufficient entropy.
The paper also talks about a way to prove that a DL private key is
sufficiently large. That also seems to be of limited use because a DL
private key can be large and still have low entropy.
BTW, I think we need a new term for validating a public key for the
purpose of non-repudiation. For DL, there are now at least two tests,
and when you say PKV most people will only think of testing that the
public key is in the right subgroup. Since the title of the paper is "A
Statistical Limited-Knowledge Proof for Secure RSA Keys", I suggest PSK
for "Proof for Secure Keys"."
DJ: Here is what I did say, I said use of an invalid key should be assumed to
void all security objectives. This is different from saying everyone should
validate another's key. If you do not validate, you accept the risk that the
key might be invalid. That is why I see it as a cost/benefit decision.
Security is all about assurance. For some scenarios the cost is less than the
benefit and therefore you should do it, for others the cost is greater and you
should accept the risk.
DJ: Regarding low entropy private keys, I see this as a bit of a canard. First
off, you assume the adversary knows all about your system, Kerchoff's
assumption, except for the secrets. Now if the adversary can introduce a low
entropy key, he is playing with your RNG or key gen or some such. So you must
assume he cannot do that. And how does he know about the low entropy key. But
in any case this is a different problem which would be addressed via different
means.
Don Johnson
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: [H] one-way hash functions
Date: Thu, 18 Jan 2001 18:05:52 -0800
> only an
> "absolute" collision-free necessity
That is very much a problem. You are not dealing with absolutes in this
case, but instead you are dealing with probabalistic collision-free.
Normally with MD5, the odds of a collision are on the order of 1/2^64 ~=
1/16000000000000000000 which is close enough to zero to matter little.
However this is a very different matter from 0 chance of collision. By
decreasing the size to 64-bits, you have a collision resistance of no more
than 1/2^32 ~= 1/4000000000 which is generally not close enough. The matter
is greatly worsened by the assumption that you are stroring a large number
of these values, and by the advance of compute power. For example, is a 1GHz
machine performs the MD5 operation in 1 clock cycle (including trimming and
comparing), it will take only 4 seconds to find a collision of the reduced
64-bit cipher.
Normally we just say to ignore the these values, because they are so
difficult to meet. However I assume that you knew what you were saying when
you said you need the result to be absolutely collision-free. The only
possibility for that is to store the actual original information (or some
perfect equivalent), all others are probabilistic, with hash functions
having well known limits. All you can do is weight the odds far enough in
your favor that you are comfortable.
Joe
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Thu, 18 Jan 2001 18:53:41 -0800
DJohn37050 wrote:
> DJ: Regarding low entropy private keys, I see this as a bit of a canard. First
> off, you assume the adversary knows all about your system, Kerchoff's
> assumption, except for the secrets. Now if the adversary can introduce a low
> entropy key, he is playing with your RNG or key gen or some such. So you must
> assume he cannot do that. And how does he know about the low entropy key. But
> in any case this is a different problem which would be addressed via different
> means.
Maybe no one can mess with your RNG, but a bad RNG can give you
lousy keys. If you cannot guard against this, then why bother
with less serious threats?
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Fri, 19 Jan 2001 03:08:00 GMT
Kenneth Almquist wrote:
>
> > Hmm. What I've been doing for finding XOR pairs is this:
> > for (x = 0; x < 256; ++x) {
> > table[256] = { 0 };
> > for (y = 0; y < 256; ++y)
> > ++table[sbox[x]^sbox[x^y]];
>
> ++table[sbox[y]^sbox[x^y]];
>
> > for (z = !x; z < 256; ++z) {
> > if( table[z] <= 4 ) continue;
> > fprintf(f,"%02x->%02x ",x,z);
> > fprintf(f,"(%d/256)\n",table[z]); }
> > }
> >
> > Is this correct or incorrect?
>
> It is incorrect. For each possible value of x and z, you are counting
> the number of values of y such that:
>
> sbox[y] ^ sbox[y ^ x] = z
>
> Therefore, when you the expression sbox[x] in your code, you know that
> you made a mistake.
> Kenneth Almquist
Yes, thank you for point that out. Actually, that mistake was made when
copying from my c code to something more psuedo-code-ish to post to
usenet.
Anyway, using that structure, I get 23 XOR difference pairs with
probability of 6/256. Using the structure Tom suggested, I wasn't able
to get anything; it seems that ++table[x^y][sbox[x][sbox[x^y]] simply
doesn't work.
Considering that Tom asserted that my AES_sbox calculation code was
right, and my DP_max code was wrong, I think I ought to re-examine my
AES_sbox calculation code.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: SAC question
Date: Fri, 19 Jan 2001 03:20:35 GMT
Tom St Denis wrote:
[snip]
> Given a function F, of size 2^n.
>
> Table A[n][n] initialized to zero
>
> for x = 0 to n
> for y = 0 to n
> for z = 0 to 2^n
> if flipping bit 'x' of 'z' causes bit 'y' of the output to flip
> (i.e (F(z) ^ F(z^(1<<x))) & (1 << y))
> add one to A[x][y]
> else
> sub one from A[x][y]
> next z
> next y
> next x
>
> If all the entries of A[][] are zero it's SAC.
I would like you to present me with any 2x2 table which is SAC.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Thu, 18 Jan 2001 19:26:02 -0800
In article <[EMAIL PROTECTED]>, roger_95073@my-
dejanews.com says...
> And with good reason. All it does is:
>
> We give an interactive protocol for proving that a number such
> as an RSA key, which is the product of two primes, is the product
> of nearly equal primes.
>
> Furthermore, it is not ZKP but "Statistical Limited-Knowledge".
There's another paper by Wenbo Mao on the same page at the URL I gave
earlier, which appears to present a ZKP for the same property. I
haven't read it carefully though.
--
http://cryptopp.com - free C++ cryptography and compression library
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Fri, 19 Jan 2001 03:26:53 GMT
Terry Ritter wrote:
[snip]
> If one could make a cipher weaker simply by adding another ciphering
> layer, that would be a way to attack the cipher. Yet we don't see
> such attacks. Why?
Sliding attack?
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Membership Signature Scheme
Date: Fri, 19 Jan 2001 03:19:01 GMT
Sorry for the duplicate. Please ignore this one - Deja !$#@$'ed my
posting.
In article <947juo$qdt$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> For a project of mine I am in need of a signature
> scheme that allows a signature to be verified
> offline as to whether it had been signed by a
> member of a group (network) of people, without
> having to know anything specific about that
> person. Essentially, the following would
> constitute the protocol:
>
> 1) A trusted arbiter of the group generates his
> secret key, and uses that secret key to generate
> unique secret keys for every member of the group,
> which he then distributes securely.
> 2) With his secret key, a user can sign a message
> and send that message plus the generated
> signature to any other member. He has no
> information at this point as to who is will be
> sending the signature + message to.
> 3) That member can, using only some global public
> data (and possibly his own secret key), verify
> that the signature matches the message and was
> generated by a member of the group.
>
> Obviously, each member�s signature of identical
> messages must be unique.
>
> Most crucial is the size of the signature. It
> must remain small (bandwidth is at a premium),
> and the best solutions I can think of right now
> involve sending a standard RSA signature of the
> message hash + a (trusted arbiter) signed RSA
> public key that generated the signature.
> Obviously, for large key sizes this could be a 1K
> signature.
>
> I have been searching as much math as I can find,
> but I can't seem to find anything quite like what
> I want. If anyone out there has a solution as to
> how I could do this or something very close, that
> help would be greatly appreciated!
>
> Sent via Deja.com
> http://www.deja.com/
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Fri, 19 Jan 2001 03:20:23 GMT
Gary Watson wrote:
> If one had sufficient CPU power or minimal throughput
> requirements, is there any reason why one couldn't use
> all five AES round two finalists in series? This would
> guard against a weakness being found in one of them, or
> if one or two of the candidates were deliberately weak
> systems promulgated by sinister government forces.
Sci.crypt is where people debate chaining three ciphers versus
five ciphers, while their data passes in the clear.
Yes, the series of all five finalists together should be at
least as secure as any one. Yes, it probably has a lower risk
of cryptologic failure. A five hundred cipher chain should be
safer still.
Where AES shines is the real world, where crypto has to be
integrated into the systems people actually use, and where the
budget for encryption is not set by the cryptographers. For
every system that has one competently deployed cipher, there's
a cryptographer who fought hard.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 19 Jan 2001 03:41:40 GMT
John Savard wrote:
>
> I thank you for an interesting post.
>
> Some people will be quite shocked at the unconventional nature of
> transposition, though.
>
> I will just content myself with noting that, particularly if the units
> being transposed are larger than a bit, if one relies exclusively on
> transposition, some aspects of the plaintext are preserved in the
> ciphertext. (Even if one transposes single bits, the output has the
> same number of 1 bits as the input.)
You seem to be ignoring that before shuffling, the data is accumulated
into bit-balanced blocks. Did you read the whole paper?
> Hence, I am going to recommend what you probably realize quite well in
> any case for the benefit of other readers: that while transposition is
> a worthy encipherment method that is unjustly neglected, it should not
> be used completely alone; it is worthwhile to use it in combination
> with substitution.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Light Computers
Date: Fri, 19 Jan 2001 03:45:21 GMT
Very interesting. I wonder, if the light was split first, and both
resulting photons were stored in this manner, would they retain their
polarization properties, and be usable in the same way as entangled
atoms?
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Thu, 18 Jan 2001 19:40:41 -0800
N. Weicher <[EMAIL PROTECTED]> wrote in message
news:rUJ96.5688$[EMAIL PROTECTED]...
> I'm not sure I follow you. Let's say that you have N blocks, but the Nth
> block contains less than 8 bytes (for convenience we'll assume N > 1 so we
> know we have at least one full block).
>
> Are you saying that the final block is computed as follows? I.e., the
> partial final block is XORed with the next to last encrypted block?
>
> C(N) = P(N) ^ C(N-1)
>
> In this case, all you need to do to recover the final partial block is to
> XOR it with the encrypted next-to-last block. You don't even need to know
> the key.
That doesn't work: You don't need to know the key to get the final partial
block, and *neither does the attacker*. Doing:
C(N) = P(N) ^ E(C(N-1))
would work, but that's not what's Don's suggesting.
>
> If this is not what you mean, how are you encrypting the final partial
> block?
Simple: Then, you first encrypt the first N-1 blocks as normal. Then, you
append the final partial block to the ciphertext, and then encrypt the last
8 bytes (i.e. full block) of the result to form the message.
To decrypt, the receiver decrypts the last 8 bytes of the message, and then
decrypts the first N-1 blocks as normal. This reconstructs the original
message.
--
poncho
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: AES sbox generating code.
Date: Fri, 19 Jan 2001 03:47:59 GMT
I've written some code to generate the sbox used in AES. I'm not
certain if it's correct. Would someone check it for me?
unsigned char AES_sbox[256], AES_sibox[256];
void AES_setup() {
unsigned char pow[256], log[256];
int i, j;
for( i = 0, j = 1; i < 256; ++i ) {
log[pow[i] = j] = i;
// The above line does pow[i] = 3**i % 0x11b
// and of course it's inverse.
j ^= (j << 1) ^ ((j & 0x80) ? 0x11b : 0);
// The above line does j = j * 3 % 0x11b
}
for( i = 0; i < 256; ++i ) { int k;
j = i ? pow[255 - log[i]] : 0;
// j is now 3**(-i) % 0x11b
k = ((j >> 7) | (j << 1)) ^ ((j >> 6) | (j << 2));
j ^= 0x63 ^ k ^ ((k >> 6) | (k << 2));
// j now is an affine transform of what it was.
AES_sibox[AES_sbox[i] = j] = i;
}
}
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Differential Analysis
Date: Fri, 19 Jan 2001 03:39:48 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Kenneth Almquist wrote:
> >
> > > Hmm. What I've been doing for finding XOR pairs is this:
> > > for (x = 0; x < 256; ++x) {
> > > table[256] = { 0 };
> > > for (y = 0; y < 256; ++y)
> > > ++table[sbox[x]^sbox[x^y]];
> >
> > ++table[sbox[y]^sbox[x^y]];
> >
> > > for (z = !x; z < 256; ++z) {
> > > if( table[z] <= 4 ) continue;
> > > fprintf(f,"%02x->%02x ",x,z);
> > > fprintf(f,"(%d/256)\n",table[z]); }
> > > }
> > >
> > > Is this correct or incorrect?
> >
> > It is incorrect. For each possible value of x and z, you are counting
> > the number of values of y such that:
> >
> > sbox[y] ^ sbox[y ^ x] = z
> >
> > Therefore, when you the expression sbox[x] in your code, you know that
> > you made a mistake.
> > Kenneth Almquist
>
> Yes, thank you for point that out. Actually, that mistake was made when
> copying from my c code to something more psuedo-code-ish to post to
> usenet.
>
> Anyway, using that structure, I get 23 XOR difference pairs with
> probability of 6/256. Using the structure Tom suggested, I wasn't able
> to get anything; it seems that ++table[x^y][sbox[x][sbox[x^y]] simply
> doesn't work.
>
> Considering that Tom asserted that my AES_sbox calculation code was
> right, and my DP_max code was wrong, I think I ought to re-examine my
> AES_sbox calculation code.
Considering I said "read my sboxgen source" and my diff code IS RIGHT. You
may want to rethink your code.
Do you honestly read the postings or just re-post the same stupid comments
over and over?
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Glide)
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Fri, 19 Jan 2001 04:02:56 GMT
On Thu, 18 Jan 2001 16:47:47 -0800, "Paul Pires" <[EMAIL PROTECTED]>
wrote:
>
>John Myre <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> Bob Silverman wrote:
>> <snip>
>> > I don't think Tom was rude at all.
>> <snip>
>>
>> Tom wrote, in part:
>> > This question is asked like 50 times a day here... For #### sake
>> > cryptanalysis is not some magic wand. Get a grip and read papers!
>>
>> Perhaps the OP deserved it - I won't try to debate
>> that issue - but the above response is indeed rude.
>>
>> It's still rude even if we say it is justified.
>
>Every lofty bastion needs a Gargoyle over the portal.
>Maybe Tom has a function if not a justification.
>
>Naw, Gargoyles are kinda cute.
>
>Paul
I see the function thing, but the justification's in absentia.
How about Gargoyle's ass?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SAC question
Date: Fri, 19 Jan 2001 03:45:34 GMT
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> [snip]
> > Given a function F, of size 2^n.
> >
> > Table A[n][n] initialized to zero
> >
> > for x = 0 to n
> > for y = 0 to n
> > for z = 0 to 2^n
> > if flipping bit 'x' of 'z' causes bit 'y' of the output to flip
> > (i.e (F(z) ^ F(z^(1<<x))) & (1 << y))
> > add one to A[x][y]
> > else
> > sub one from A[x][y]
> > next z
> > next y
> > next x
> >
> > If all the entries of A[][] are zero it's SAC.
>
> I would like you to present me with any 2x2 table which is SAC.
Righto, but I did find a 3x3 sbox with SAC... So they don't exist for 2x2
doesn't mean they don't exist for larger ones.
sbox: { 7, 6, 3, 5, 4, 0, 2, 1 }
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 03:49:38 GMT
In article <947vg2$5ch$[EMAIL PROTECTED]>,
Greggy <[EMAIL PROTECTED]> wrote:
> > > When you get done reading through that stuff, if you are
> > > interested, do a search on the "missing thirteenth amendment"
> >
> > The claim that it was ratified by a 13th state relies entirely on
> > the Virginia legislature's Act No. 280: "... there shall be published
> > an edition of the Laws of this Commonwealth in which shall be
> > contained ..." and the subsequent publication of the Virginia
> > Civil Code containing the proposed 13th Amendment among other
> > US and Virginia laws. At that time (1819) there were 21 states,
> > so even if Virginia had thereby ratified the amendment (which
> > is debatable, to say the least), it would have still failed to
> > gain the required 3/4 approval (16 states, not 13).
>
> I know what you are saying. Jol Silversmith made similar claims and
> actually convinced me I was wrong. Recently I came across an argument
> not even you can refute that says I am right. Your statement shows you
> are thinking and looking in the wrong place altogether - as I was.
In the absence of any elaboration from you, shall we assume that you've
developed a new form of kook math in which the fraction 13/21 is greater
than the fraction 2/3? Or do you have so little confidence in this
miraculous new kook argument to reveal it to general scrutiny?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 03:46:26 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > When you get done reading through that stuff, if you are interested,
> > do a search on the "missing thirteenth amendment"
>
> The claim that it was ratified by a 13th state relies entirely on
> the Virginia legislature's Act No. 280: "... there shall be published
> an edition of the Laws of this Commonwealth in which shall be
> contained ..." and the subsequent publication of the Virginia
> Civil Code containing the proposed 13th Amendment among other
> US and Virginia laws. At that time (1819) there were 21 states,
> so even if Virginia had thereby ratified the amendment (which
> is debatable, to say the least), it would have still failed to
> gain the required 3/4 approval (16 states, not 13).
A through article at www.thirdamendment.com/missing.html explains this
point in greater detail (if it isn't what you're relying on already).
It also talks a bit about the amendment process in general, such as that
publishing a book that includes an amendment can't be construed as a
ratification of an amendment. And notes that the same kooks who claim
the 16th amendment wasn't ratified because of changes in spelling, etc.
conveniently ignore the same issues for the "missing 13th amendment."
But not that one can expect much rational thought from these kooks. They
also claim that the "missing 13th amendment" gives them the right to
murder cops (because being a police officer is a "title of nobility,"
doncha know).
Sent via Deja.com
http://www.deja.com/
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
