Cryptography-Digest Digest #180, Volume #13 Sat, 18 Nov 00 00:13:00 EST
Contents:
Re: Hitachi - on what grounds ?? (John Savard)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (d)
Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS (John Savard)
Re: ---- Internet Voting Questions ([EMAIL PROTECTED])
Re: Anyone has read / poses / is found of book by M.Schroeder(not the ("John A.
Malley")
Re: My comments on AES ([EMAIL PROTECTED])
Re: DES question: Has this ever been proven before? (Simon Johnson)
Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware (Simon Johnson)
Re: voting through pgp (Benjamin Goldberg)
Re: Randomness from key presses and other user interaction (Benjamin Goldberg)
Re: Q: fast block ciphers (Benjamin Goldberg)
Re: Q: fast block ciphers (Benjamin Goldberg)
Re: vote buying... ("Trevor L. Jackson, III")
Re: help on user authentication protocol ([EMAIL PROTECTED])
Re: Hitachi - on what grounds ?? (Terry Ritter)
Re: [Question] XOR encryption (Simon Johnson)
Re: Integer encoding on a stream (Benjamin Goldberg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Hitachi - on what grounds ??
Date: Sat, 18 Nov 2000 02:11:15 GMT
On Fri, 17 Nov 2000 17:26:43 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>At first glance, that does not seem to be a good pattern for a block
>cipher: a bit-change in plain(i) apparently affects only cipher(i) and
>cipher(i+1). That is not good diffusion.
You're right. It is fatally flawed. But once it is fixed, to make it
behave, say, like CBC, and still be invertible, it will start to look
like some of the diagrams in that patent.
>Have *you* used it? Do you know anyone who has? Exactly what is your
>factual basis for "suspecting" that the cipher is "very commonly
>used?"
Oh, I may be making a generalization here.
>As you may recall, I did ask for your personal opinion on this, and
>you did assure me that none of the AES ciphers was following my path.
>I had not studied those ciphers, and still have not, but I expect that
>you were right.
But I have now to confess that this patent was one of your inventions
that I missed or overlooked when making that assessment.
>A patent covers only what is described in the claims. The body is not
>important, except to teach, or to define terms, or to become prior art
>after publication.
Although I know this, I didn't see the claims on that web page. I'll
have to look again more carefully, or use the patent number on
Delphion in the unlikely case that the claims are not on the web page.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: d <[EMAIL PROTECTED]>
Crossposted-To: alt.sources.crypto
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Sat, 18 Nov 2000 02:06:09 GMT
In article <[EMAIL PROTECTED]>,
d <[EMAIL PROTECTED]> wrote:
> Command line One Time Pad utility. Options: pad generation, randomness
> testing, en/decryption, base64 en/decoding and disk wiping. ANSI-C
> source and DOS executable included.
>
> Free download at <http://www.vidwest.com/otp/>
>
> Your bug reports/other feedback will be gratefully received.
>
> [EMAIL PROTECTED]
>
>
Update now available (0.9.4) at above URL - same functionality, some
minor bug fixes - a big THANKS for all the help and constructive comment
--
Thanks for giving this your attention,
David West. <[EMAIL PROTECTED]>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS
Date: Sat, 18 Nov 2000 02:13:05 GMT
On 17 Nov 2000 21:13:32 GMT, [EMAIL PROTECTED] (Scott
Craver) wrote, in part:
> I'm not sure what has
> suddenly caused him to start posting to sci.crypt,
> but he seems to be diversifying elsewhere too.
I note that the first post in the thread isn't on this NG. Whether or
not that has anything to do with it, though, I do not know.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ---- Internet Voting Questions
Date: Sat, 18 Nov 2000 02:40:35 GMT
On Fri, 17 Nov 2000 17:40:24 -0800, David Schwartz
<[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote:
>
> These are all arguments from lack of imagination.
This is simply an assertion. To make your point, try advancing an
argument.
>> The problem with Internet voting, or indeed any form of electronic
>> voting, is lack of transparency, combined with the incentive to attack
>> the integrity of the system whih is present in any voting process.
>
> Why couldn't an electronic system be as transparent as a physical
>system?
This is a question. To make your point illustrate how an electronic
system can be as transparent as making a mark on a physical ballot
which is then counted.
>> The problem with electronic voting is that it increases the
>> vulnerability of the vote to mass manipulation (by technical means),
>> while making it harder to ensure that such manipulation hasn't taken
>> place. Also, there is no physical representation of the votes to fall
>> back on if it there is subsequent doubt about the electronic process.
>
> Why can't there be a physical representation of the votes to fall back
>on? And do you realize how many systems in current use have no physical
>ballots to fall back on?
Both questions. How do *you* propose that a physical representation
be made in system of voting over the 'net (which is the topic)? In
advancing your proposal, remember that the purpose is that the
physical ballot can be readily used to verify the count independently
of the electronic system, if necessary. As in manual recounts of
ballots.
>> So, there is a major incentive to corrupt the electoral software at
>> any point of the system - whether through trojans on voters' machines,
>> or the software itself.
>
> The software doesn't have to know who it's voting for. Again, argument
>from lack of imagination.
So what if the software doen't know. You are implying, without
grounds, that my argument rests on the sofwtare "knowing". It doesn't.
>> Does one have to have party scrutineers who
>> are software engineers, entitled to access and verify the electoral
>> software - at *every* point in the system? What about the possibility
>> that the vote is corrupted at the client end, how is that scrutinised?
>
> Again, the client software doesn't have to know who it's voting for. It
>could, for example, only know that I'm voting for candidate number '3'
>without knowing that, for me, number '3' represents George Bush.
The possible attacks are numerous. You are addressing only one
possible attack and even then in a very slight way. For example,
suppose a trojan simply randomises the votes in counties which are
known to favour one or t'other candidate? And before you respond to
this example, remember it is simply one illustration. The point made
was general, and stands regardless of the rightness or wrongness of a
particular example, unless a generalised refutation is made.
>> The second vulnerability, even if the voting process is technically
>> inviolate, is that people would attempt to manipulate the perceptions
>> of the system. That is people would attempt to game the system by
>> casting doubt on the process. Imagine if Gore or Bush had suggested
>> in an electronic voting system, that the Florida count was wrong due
>> to a software bug in the system. How would the vote be verified? It
>> could dramatically undermine the public's confidence in the system and
>> the outcome.
>
> How do you verify the counts from current systems that use touch
>screens or modified palm pilots? How do you verify the results for
>current mechanical level voting machines?
It is logistically much harder to fiddle the mechanics in many
different sites than it is to fiddle software. To tamper with my
car, a persons needs physical access. To tamper with systematically
with a significant percentage of all cars is logistically difficult.
To access and taper with a significant number of 'net connected
computer's is much more feasible - and has been demo'd in practice by
everything from Back Orifice to the Melissa virus, etc.
>> Democracy relies fundamentally on public commitment to a
>> fair process, over and above the result. If the process is in doubt,
>> democracy collapses. How does one give the public *absolute*
>> confidence in an electronic voting system they cannot see or few of
>> them can understand?
>
> Oh that's just such total bunk that it doesn't even deserve a response.
Another overwrought assertion.
>If lack of absolute confidence was sufficient to collapse democracy, we
>couldn't have gotten nearly this far. This is an argument from lack of
>understanding of history. Obviously, we should continue to move in the
>direction of better and better electoral processes.
>
Assertion, again without supporting argument, not to mention an
implied ad hominem attack (ie that I am ignorant of history).
You arguments are close to non-existent.
cheers
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Anyone has read / poses / is found of book by M.Schroeder(not the
Date: Fri, 17 Nov 2000 19:14:29 -0800
Ariel Burbaickij wrote:
> What book would you recommend ?
"Standard Mathematical Tables and Formulae", CRC Press, ISBN
0849324793.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: My comments on AES
Date: Sat, 18 Nov 2000 03:16:09 GMT
In so much as an academic attack after 5 years is proof of close
scrutiny, one might have more confidence in a cipher for which the
only known attack is an academic attack (ie with no real reduction in
practical security), than one for which there is no known attack.
If there are no academic attacks, it may indicate lack of scrutiny.
And no I am not saying that an academic attack is either the only
evidence of scrutiny, nor sufficient evidence in itself. But it is
evidence of scrutiny - especially if it is apparent that it is the
product of 5 years of analysis.
On Sat, 21 Oct 2000 21:36:58 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: Tim Tyler wrote:
>
>:> How about the bit where he wrote (from the URL above):
>:>
>:> ``I believe that within the next five years someone will discover an
>:> academic attack against Rijndael.''
>
>: However, if an academic attack is only of interest
>: academically and not a genuine menace in practice, then
>: that would be only a happy and laudable success of some
>: intellectual endeavour, nothing more.
>
>No doubt it would be an inspiration for those wishing to embark on
>further such intellectual endeavours.
>
>Does anyone have any comments on the proposed timescale?
>
>I suspect an academic break (of 128, 192 or 256 bit Rijndael) will come
>to light eventually - but that it may well take more than five years.
>--
>__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Surf against sewage.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Sat, 18 Nov 2000 04:12:22 GMT
In article <8v2bnt$mct$[EMAIL PROTECTED]>,
Raphael Phan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Just wondering...
>
> let x and y be a pair of plaintexts to DES such that the input XOR
> is x'. Would the corresponding output pair have the same XOR
> difference?
>
> Raphael
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Its probably possible, but the probability of this occuring is most
likely to be stupidly small.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Announcement: One Time Pad Encryption - 0.9.3 - freeware
Date: Sat, 18 Nov 2000 04:14:38 GMT
In article <[EMAIL PROTECTED]>,
d <[EMAIL PROTECTED]> wrote:
> Command line One Time Pad utility. Options: pad generation, randomness
> testing, en/decryption, base64 en/decoding and disk wiping. ANSI-C
> source and DOS executable included.
>
> Free download at <http://www.vidwest.com/otp/>
>
> Your bug reports/other feedback will be gratefully received.
>
> [EMAIL PROTECTED]
>
>
Erm.... k
Where you getting your random data to generate your pad from?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: voting through pgp
Date: Sat, 18 Nov 2000 04:21:06 GMT
John A. Malley wrote:
>
> David Wagner wrote:
> >
> > Ok, I see. Witnessing helps with authenticating voters. But it
> > doesn't help me if my computer has been silently infected with an
> > "Election Day" virus which secretly changes my vote. (Crypto can't
> > help if one of the endpoints is not trustworthy.) So it's not a
> > silver bullet, but it still seems like it could be useful. Right?
>
> Right. The witnessed-act protocol or something like it could be
> developed into a viable means of on-line vote taking. I don't think it
> will scale well, though, as the number of witnesses increases.
>
> Your "Doppleganger" attack with a trojan horse/virus resident on the
> PC and intercepting all of the voter's actions and the actions of the
> other witnesses to the voting act is wickedly insidious and worth
> further study/analysis. What we've discussed in this thread cannot
> defend against such an attack.
>
> The Doppleganger sits between the voter and the other witnesses in a
> "man-in-the-middle" attack role. It knows everything the voter stores
> on the local machine if it has the same access rights and privileges
> as the voter. It can alter or pass through anything from the voter to
> the witnesses and thus the witnesses authenticate it as the true
> voter. It can alter what the voter thinks s/he sees on the local
> machine. It can collect all the info from witnesses used to mark the
> decision made by the voter. And, it can change the value of the
> decision made by the voter before making the non-malleable decision.
>
> Most interesting. Sort of a "spot the evil twin" problem. :-)
Or even sort of a Turing test.
> (Vague hunch this Doppleganger attack can be transformed into a
> decidability problem of some kind, and that the decidability problem
> is undecidable - there is no algorithm for it.)
Hmm, suppose we have an AI, and a human, and we can have a text only
conversation with each. Further assume that the AI is advanced enough
that a human being can't tell which is which better than 50% of the
time. Is it possible to create another AI which *can* tell which is
which?
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Randomness from key presses and other user interaction
Date: Sat, 18 Nov 2000 04:21:02 GMT
Steve Roberts wrote:
>
> Tim Tyler <[EMAIL PROTECTED]> wrote:
>
> >Steve Roberts <[EMAIL PROTECTED]> wrote:
> >
> >: Aargh, the user will just hold a key down so that all the key
> >: strokes will have the same spacing in time!! Don't forget that
> >: humans will usually find the easiest possible way of doing
> >: something. The same thing for human-chosen random typing - there
> >: will be a lot of repeated a's out there.
This can indeed be a problem, but keep in mind that these are two
different, if similar, problems. The first is the user holding down a
key and reducing timing entropy to 0, and the second is the user
repeatedly using the same key continuously and reducing character
entropy to 0.
> >You can detect this easily. Insisting on a number of key releases
> >is one counter-measure to having the user hold down a key.
>
> But if that is implemented then the work-minimising user, on finding
> that holding the key down won't do, will repeatedly press the same
> key, or alternate with two different keys.
Even if a user repeatedly presses one key, or alternates between two
different keys, there is still the entropy of the timing of the
keystrokes.
> For that sort of reason, in the stream of characters I required the
> user to copy there were no repeated consecutive letters.
If you're using the characters themselves as the entropy source, not
their timings, then that test is still too simplistic, because if the
user types 'abababababab', there's little or no entropy in the
characters.
It would be a better idea to measure the number of bits order-1 (NOT
order-0) entropy of the stream of characters; Call this value (measured
in bits-of-entropy/bit-of-input) H, and collect
((bits-of-entropy-needed) / H) characters from the stream.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Sat, 18 Nov 2000 04:21:14 GMT
David Schwartz wrote:
>
> Scott Fluhrer wrote:
>
> > Umm, the OP asked for a block cipher. I do believe that RC4 is
> > normally considered a stream cipher...
> >
> > --
> > poncho
>
> While a block cipher may be difficult to use as a stream
> cipher (actually, it's not hard to use but hard to be sure it's
> secure), any stream cipher can trivially be changed into a block
> cipher.
>
> DS
Umm, isn't that sort of backwards? A block cipher can trivially be
changed to a stream cipher by putting it in counter mode or OFB mode. I
would be interested in hearing how one would change a stream cipher into
a block cipher.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Sat, 18 Nov 2000 04:21:26 GMT
Tom St Denis wrote:
>
> In article <8uvh3t$lgt$[EMAIL PROTECTED]>,
> "Brian Wong" <[EMAIL PROTECTED]> wrote:
> >
> > "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> > news:8uvbod$7l6$[EMAIL PROTECTED]...
> > >
> > > I once designed a block cipher that uses decorrelation modules for
> > > security. The idea was to precompute multiplication in GF(2)^32
> > > as a series of four 8x32 sboxes. With six rounds I achieved a
> > > rate of about 13 cycles/byte on my AMD K6-II machine which is the
> > > fastest speed for a block cipher I ever heard of.
> >
> > It's GF(2^32), something you should remember after being corrected
> > for this so many times. If you can't get this simple statement
> > right, how do you expect to have any credibility at all?
>
> Then why is GF(p) modulo a prime modulus, such as in IDEA?
>
> That's why I get confused. I am working with a 32-degree polynomial,
> not a 32-bit scalar.
GF(n) means that after each operation, we reduced modulo n.
GF(n)^m means that we have m non-interacting terms, each of which is
reduced modulo n after each operation. For example, XOR could be
considered to be addition in GF(2)^m.
GF(n^m) means that we reduce by an m term polynomial, each term of which
is in GF(n).
If you multiply two values in GF(2^32), you are are doing polynomial
multiplication, where each term of the result is reduced by 2, followed
by reducing this reduced by an order-32 primitive polynomial.
If you multiply two values in GF(2)^32, then the N-th term of the result
is the multiplication (in GF(2)) of the N-th terms of the operands. In
other words, a logical AND of the two values.
If you add two values in GF(2)^32 or in GF(2^32), then the N-th term of
the result is the addition (in GF(2)) of the N-th terms of the operands.
In other words, an XOR of the two values. If we are working in
GF(2^32), a reduction by the polynomial *could* be done, but it would
not change the result, because the polynomial addition of two values
which are already in GF(2^32) cannot have a result with a x^32 term.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
Date: Fri, 17 Nov 2000 23:28:52 -0500
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: vote buying...
David Schwartz wrote:
> "Trevor L. Jackson, III" wrote:
>
> > > So long as you need the voter's help to check them, you can easily meet
> > > both goals.
>
> > Not quite. If the voter can prove the validity of his vote than a person
> > threatening the voter can force him to reveal the validity token.
>
> And he can equally well produce someone else's validity token.
>
> > The only way to
> > protect the voter is to permit him to present a fake validity token. But that
> > conflicts with the fraud detection mechanism because it can be used to hide fraud.
>
> How? So long as the same number of fake validity tokens are issued for
> each candidate and the number of fake validity tokens is known, they
> don't interfere with the fraud detection mechanism at all.
>
> Again, all these arguments are based simply upon lack of imagination.
Well, I'll admit that I can't imagine a better way to terminate this thread. Imagine
that.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: help on user authentication protocol
Date: Sat, 18 Nov 2000 04:22:13 GMT
In article <[EMAIL PROTECTED]>,
Thomas Wu <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> >
> > Can you comment on Tomas Wu's SRP? I like this protocol but would
want
> > to know how strong SRP is with comparison to other protocols like
PAK,
> > SNAPI, SPEKE, AMP, etc. Thanks.
>
> I'll try my best to be objective on this one. :-) Choosing a
protocol
> is like choosing any other crypto primitive - you need to make an
> evaluation based on all factors, like security, ease of
implementation,
> performance, availability of reference implementations, freedom from
> encumbrance, etc.
>
> Unless you have done so already, I'd recommend reading some background
> material on the subject:
>
Tom, thanks for your reply. I indeed already read your paper and also
checked out SRP project website. Sorry for my naive question here
becuase I am really new to this area. I want to ask you that if it is
safe to put the prime number N and its generator g in the source code.
I am thinking the "g" at least has to be hard-coded. Is that right?
Your insight on implementation of your protocol will be greatly
appreciated. BTW, I don't see the license statement of SRP on your
website. You only say it's open-source friendly. But I would like to
see a formal license statement on your website. You also seem to
imply that Standford is seeking patent on SRP. This concerns me. How
do you ensure SRP is still a open-source protocol if your employer wants
to get royalty on it?
c6ap
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Hitachi - on what grounds ??
Date: Sat, 18 Nov 2000 04:32:22 GMT
On Sat, 18 Nov 2000 02:11:15 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (John Savard) wrote:
>On Fri, 17 Nov 2000 17:26:43 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
>in part:
>
>>At first glance, that does not seem to be a good pattern for a block
>>cipher: a bit-change in plain(i) apparently affects only cipher(i) and
>>cipher(i+1). That is not good diffusion.
>
>You're right. It is fatally flawed. But once it is fixed, to make it
>behave, say, like CBC, and still be invertible, it will start to look
>like some of the diagrams in that patent.
CBC is a mode of operation, not a block cipher. Nor does CBC by
itself constitute a cipher. But, as you suggest, something like it
might well be used as a one-way diffusion layer in a patented Variable
Size Block Cipher construction. That does not mean that I claim CBC
per se.
>[...]
>>As you may recall, I did ask for your personal opinion on this, and
>>you did assure me that none of the AES ciphers was following my path.
>>I had not studied those ciphers, and still have not, but I expect that
>>you were right.
>
>But I have now to confess that this patent was one of your inventions
>that I missed or overlooked when making that assessment.
Well, of course. What was I thinking?
>>A patent covers only what is described in the claims. The body is not
>>important, except to teach, or to define terms, or to become prior art
>>after publication.
>
>Although I know this, I didn't see the claims on that web page. I'll
>have to look again more carefully, or use the patent number on
>Delphion in the unlikely case that the claims are not on the web page.
The claims were and are at the end of the patent.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: [Question] XOR encryption
Date: Sat, 18 Nov 2000 04:31:56 GMT
In article <JQiR5.9587$[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote in message news:8v4926
$8ig$[EMAIL PROTECTED]
> > [snip is XOR secure]
> >
> > There's a rather continual debate going on about just that.
>
> <Snip>
>
> Off on tangent but I'll never get a better chance to ask
> a really clueless question.
>
> Often XOR is discussed as if it was synonymous with OTP. It
> is also a simple operation used in a variety of other algorithms.
> While it is a useful operation, certain conditions can occur to
> produce a surprisingly scary result, at least to me.
>
> Example:
>
> 1, Load an array with a variety of values.
> 2, Mix them up by randomly selecting two of the values
> and XOR them together.
> 3, Overwrite each original value in the list with each result
obtained.
>
> Do this long enough and you end up with an array full of zero's.
> Using XOR in this way appears to be a bad practice.
> I think I have a clue on why it happens. The
> possible pairs for one bit position are
>
> 0,0 0,1 1,0 and 1,1.
>
> A pair without a zero XOR'ed can make a zero
> but a pair without a one cannot make a one. Once all ones are
> gone from a bit position in the list,
> they can never "come back".
>
> I'm curious about this and was just wondering if
> anyone has compiled a list of things NOT to do with simple
> operators.
>
> I realize that the best solution for my curiosity is to
> go back to school and stay awake this time but I was
> wondering if there was a general article somewhere
> about uncommon cases using simple operations?
>
> Paul
>
>
A property of XOR is that A XOR A = 0, which describes while your
algorithm eventually fills an array with 0's.
The security of the One-Time-Pad is not dependent on the XOR operator.
Any operator that "Compresses" two inputs 'evenly' into each other
works just as well. The OTP's security is derived from the randomness
of the key. Sinec there are only a finite number of keys for a plain-
text of given size, then each key is equally likely. This means that
any concieveable plain-text could have resulted in the same cipher-text
as the attack has. Meaning it is impossible to find with any
significant probability that the correct decrytion.
XOR is used heavly in cryptography for two reasons:
1. XOR is a bitwise comparrison which executes fast.
2. XOR is self inverse, by this i mean: B XOR (A XOR A) = B
These properties do not make ciphers using XOR any more secure, but
make implementation of these ciphers simpler.
Hope this helps,
Simon.
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Integer encoding on a stream
Date: Sat, 18 Nov 2000 05:07:02 GMT
In response to my question, Ray Gardner sent me a reference to the
following page:
> http://citeseer.nj.nec.com/fenwick96punctured.html
It contained a mention of using the various integer encodings for
writing the output values of the move-to-front compressor used in BWT
compression.
An idea has occurred to me that might be of interest...
Consider the Elias gamma' code, which is an alpha code (alpha(n) is n 0s
followed by a 1) for the length of the number, followed by the binary
representation of the data bits (a beta code).
Suppose that, after the MTF step of BWT compression, the *lengths* (the
first part of the gamma' code) were all written out, but instead of an
alpha code, entropy encoding were done on them. Follow that by the
second part of the gamma' code, which would then be the data bits of all
the values.
MTF should result in most of the values being small. The lengths of
these numbers should all be nearly the same, so entropy encoding on the
lengths should work quite well. Additionally, the second part (all of
the data bits) should hopefully be quite short.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
** 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
******************************
