Cryptography-Digest Digest #434, Volume #11 Tue, 28 Mar 00 03:13:01 EST
Contents:
Re: The lighter side of cryptology ([EMAIL PROTECTED])
Re: Cryptomat.com ("John A. Malley")
Re: DES question (David Hopwood)
Re: root mod a prime? (David Hopwood)
Re: Method for time-altering keys ("Adam Durana")
Re: The lighter side of cryptology (Gerhard Wesp)
Re: Download Random Number Generator from Ciphile Software (Anthony Stephen Szopa)
Re: DES question ("Scott Fluhrer")
Re: Checking for a correct key (John Savard)
A good encryption program? (JohnNY)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: OAP-L3: Answer me these? ("Scott Fluhrer")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: The lighter side of cryptology
Date: Tue, 28 Mar 2000 04:10:15 GMT
In article <
20000327181351.04429.00001668@ng-
fk1.aol.com>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Check out the Journal of Craptology.
> Don Johnson
>
Here's an excerpt from an actual journal-
"Annals of Improbable Research" (or AIR):
PGP-Y
Our engineers have developed a truly
foolproof data security protocol. It is called
PGP-Y --"Pretty Good Parapsychology." The
mechanism is simple. You imagine that you
have transmitted data to someone; that person
then imagines that he has received it. Using
PGP-Y, any type of information can be
transmitted over the Internet with complete
security. The key is that the data is
transmitted high over the net--so high that
the data actually travels above the net rather
than within it. The data is transmitted
telepathically (and for those who distrust
electronic funds, we also have a scheme for
transmitting cash and gold plate
telekinetically.)
Looking for a good prime? Call 129-9827
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Cryptomat.com
Date: Mon, 27 Mar 2000 21:29:09 -0800
Cryptomat.com is registered to Bright Grey Ventures in Cambridge, UK,
according to a WHOIS query at NetworkSolutions.com.
The addresses and telephone contact info for admin contact and billing
contact are for Green Cathedral Ltd, a web site development company (see
http://www.greencathedral.com.)
Bright Grey Ventures (CRYPTOMAT-DOM)
The Barn, Longstanton
Cambridge, CB4 5BP
UK
Domain Name: CRYPTOMAT.COM
Administrative Contact:
Managing Director (MD736-ORG) [EMAIL PROTECTED]
Green Cathedral Ltd
The Barn, Longstanton
Cambridge
UK
+44 1954 204000
Fax- +44 1954 204001
Billing Contact:
Financial Director (FD257-ORG) [EMAIL PROTECTED]
Green Cathedral Ltd
The Barn, Longstanton
Cambridge
UK
+44 1954 204000
Fax- +44 1954 204001
Record last updated on 12-Dec-1999.
Record created on 12-Dec-1999.
Database last updated on 27-Mar-2000 11:49:50 EST.
So it appears (?) that Bright Grey Ventures is (probably) owned by Green
Catherdral?
Interesting enough, Green Cathedral spawned Clickstream Technologies in
February 1999, "a wholly owned
subsidiary which develops, licences and markets a range of tracking
products based on Clickstream." Clickstream is a product designed to
track all activity of web site visitors.
>From the Clickstream web site, "Clickstream's autonomous page-side
tracking components are embedded in Web pages, graphics, adverts, shows,
games,channels and any other transmitted objects that site creators can
dream up for their audience. Coupled with Clickstream's server-side
database software, the page-side "agents" track what individual people
actually do whilevisiting a Web site. And what they do when they're
"off-line". Clickstream is a response to the now considerable demand
formore accurate, more comprehensive, more intelligent visitor tracking
and traffic analysis tools."
( See http://www.clickstream.net/techno.html)
Clickstream and all other web sites developed or owned by Green
Cathedral bear the Green Cathedral copyright in their HTML source.
HMTL source from cryptomat.com does NOT bear the Green Cathedral
copyright "boilerplate" text.
If you run their cgi script directly,
http://www.cryptomat.com/cgi-bin/tracer.cgi, you'll see that to get to
cryptomat.com (195.224.241.23) the traffic passes through
clickstream.greencathedral.co.uk (195.224.241.111) (according to the
script, that is. I don't know if that is REALLY where the traffic goes
but I'm taking it at face value here.)
http://clickstream.greencathedral.co.uk/ brings up an authentication
dialog with a product called Netsaint Access which is running on a Zeus
web server. A log of who's been visiting from where?
I have no idea why Bright Grey Venture/Green Cathedral is trying to set
up something like the cryptomat site. Cryptomat.com is a hobbled
demonstration of "cryptanalysis."
Anyone have any idea what's behind cryptomat.com?
John A. Malley
[EMAIL PROTECTED]
------------------------------
Date: Tue, 28 Mar 2000 03:32:52 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: DES question
=====BEGIN PGP SIGNED MESSAGE=====
Paul Rubin wrote:
> In article <[EMAIL PROTECTED]>, doc
> <[EMAIL PROTECTED]> wrote:
[...]
> >Perhaps a more general way of asking this question is to
> >inquire about the domain of the ciphertext.
> >
> >Or, is it possible to have a ciphertext that does NOT
> >decrypt using DES?
>
> That wouldn't make any sense. It would mean the encryption was not
> reversible.
It is possible to have a reversible encryption algorithm with this
property, but it would have to be probabilistic, and the ciphertext
would have to be longer than the plaintext (a concrete example is
DHAES).
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOOAnmjkCAxeYt5gVAQH6pAf+KNQZc+14CqsYmvANhFZA6/lDuEUqsN0J
xRpNp2wJKk9Y3K+6S1EpxH2FF9UwtKjVOGlAJLPV+PqumyB7C+KxxH8cLgz2LKRg
1PGujnzMlVWk2EeEpWabTZMNp6eHE0YP86q/4GPoBfeBkR+MmpVKgMfhHvw8lOi9
W7Roi8xtru95eZ818vZEstfrGrgDeOLjBsWUB9PQKW/aDAGuCg1f/YnbGJdFpsEN
Xz+5u6Oe5Vzp7smctRqlj9dRHlQj/glZrI9H3JynCDILJhTVXPq4+SKodt7nEQjc
kfFVDF+8bLJsNUFsaazsVu++l9cTolMEh+VYbH6gwBmhjTVQkZMYlA==
=YBLv
=====END PGP SIGNATURE=====
------------------------------
Date: Tue, 28 Mar 2000 02:38:41 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: root mod a prime?
=====BEGIN PGP SIGNED MESSAGE=====
Mike Rosing wrote:
> David Hopwood wrote:
> > Careful: if kP is the point at infinity then the order of P divides k,
> > but it is not necessarily equal to k.
>
> Right. I was assuming k was a prime already. [...]
And that P is not the point at infinity, which has order 1 even if
k is prime :-)
[I know that you already understand all of this, but some readers might
not, so it's important to be precise.]
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOOAa4DkCAxeYt5gVAQH+dAgAihMpImZ4QKlE4Y1NIXqf5as4H5/pxG9u
S7vUJ82o9hd+fw3Q3an8EbjURn7Yz4lWQR/taPTd9hsAE74yyRLsxy3WktmBZryA
izoNa+U/Ij5Hi2RmRXtTrVsz8eqSKaeHvcN7gVcrbcOB13cRjaOuHKQclZIdTlkv
kTRUJRTqyzZJfmaaxYQbIxgAP8qbFWNT7oIeV/ukNgtxDiTwZ3huk0yksrEUw5P8
25/oT5jU2ghB7X6WJyZeGFNPbamO8TX-Mozilla-Status: 0009SImQ5tB12xjR
2n19TbN9H4sdBmciWpmUn9680F51XRLOyvxoa3H1FEBDK7+5zknKRw==
=yj/X
=====END PGP SIGNATURE=====
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Method for time-altering keys
Date: Tue, 28 Mar 2000 00:57:47 -0500
So you are assuming an attacker will have the salt but not the transmission
time? If an attacker an intercept your salt the attacker will most
certainly know about what time your key was generated, depending on the
system. Even if you do create the key prior to using it how is the other
party supposed to know the time? Are they supposed to brute force a small
key space? If the party on the other end can do this an attacker can too.
I really don't see what your are trying to accomplish. Are you trying to
securely exchange secret keys? If you are you should just use DH, RSA or
even ECC. I suppose you could still incorporate your time/PID/IP scheme,
although I'm still not seeing the point. You could hash the IP/time/PID
combination if you are trying to create unique ids.
- Adam
"RecilS" <[EMAIL PROTECTED]> wrote in message
news:8bp4el$l4c$[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I too, think that a random value would be better but here's my
> reasoning...
> a) A random value would obviously have to be transmitted and I'm more
> worried about interception
> b) I want cracks attempted in the future (without knowledge of the
> transmission time) to be almost impossible
> c) I will also be including the processor ID, IP address and other
> user-specific variables into my scheme under the same methods. Not
> to make it harder to crack, but more time and effort consuming.
>
> - - Doug
>
> Lyalc wrote in message ...
> >A critical benefit arises from the suggestion to add time bits to
> >the user's pass phrase.
> >This adds a "specific use" element to the use of the password (or
> >any other shared secret), increasing the ease of replay detection.
> >And, it's used in several environments today - and in the future.
> >
> >Lyal
> >
> >
> >Adam Durana wrote in message ...
> >>
> >>I think I follow even though your explanation could be better. But
> >>what is the point of doing this? Letting the time affect the key
> >>just seems like a weakness, i.e. if someone knows what time the key
> >>was made they know some
> >of
> >>the key bits, or the ordering of the bits depending on what your
> >>method does. I still can't think of a case where you would want a
> >>key to be affected by the time it was created, unless you can
> >>derive that time from the key without giving away the key. Keys
> >>that expire are interesting but this method does not do that. Also
> >>why even bother reordering the bits? Just attach the output of
> >>time(0) to the end of the passphrase the user provided.
> >>
> >>And I do suggest you read "the statistical report analysis for time
> >>sensitive PF417 gJq10 data proccessing routine".
> >>
> >>- Adam
> >>
> >>
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>
>
> iQA/AwUBOOAVFRJETAFqh0RgEQLq/QCgpxYsUhQNqudUhMAiqLBFb3ZGh3kAn0Rc
> SNOGpRuYlNvPy4esIOsTL5B9
> =fr6Y
> -----END PGP SIGNATURE-----
>
>
>
------------------------------
From: [EMAIL PROTECTED] (Gerhard Wesp)
Subject: Re: The lighter side of cryptology
Date: 28 Mar 2000 06:16:37 GMT
Reply-To: [EMAIL PROTECTED]
In Galois fields, full of flowers,
Primitive elements dance for hours...
-- from MacWilliams, Sloane: The Theory of Error-Correcting Codes,
Chapter 4.2
regards,
-gerhard
--
| ___ Gerhard Wesp
| \_________|_________/ http://www.cosy.sbg.ac.at/~gwesp
| O Ban Dihydrogen Monoxide, the most dangerous
| chemical known to mankind! --- http://www.dhmo.org
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Mon, 27 Mar 2000 22:43:42 -0800
Eric Lee Green wrote:
>
> Anthony Stephen Szopa wrote:
> > What would you say if there were no attacks possible against
> > OAP-L3 when used according to recommendations (truly random user
> > input and large key length) except brute force?
>
> I would suggest a paper similar to the Yarrow paper, which addresses a large
> number of potential attacks including references to other papers about those
> attacks, and steps they made to make sure that it was not succeptible to those
> attacks.
>
> As for what you "say", I'd say that all random number generators have attacks.
> The issue is how to minimize those attacks. For example, even the Linux
> /dev/random, as deeply embedded in OS internals as it is, is succeptible to
> attack if the attacker has control over the system clock and can monitor the
> device interrupts. (Something that might be possible in, e.g., a smart card
> application). To totally dismiss issues of this type gives people the
> impression that you are engaged in complete hyperbole.
>
> --
> Eric Lee Green [EMAIL PROTECTED]
> Software Engineer Visit our Web page:
> Enhanced Software Technologies, Inc. http://www.estinc.com/
> (602) 470-1115 voice (602) 470-1116 fax
My position is that the theory upon which OAP-L3 is based is
fundamentally simple. So simple that one versed in possible
attacks should be able to reasonably suggest any if they seemed
to have potential of success.
I just haven't heard of one yet.
I would like to hear of one if one should exist.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: DES question
Date: Mon, 27 Mar 2000 22:47:53 -0800
David Hopwood <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Paul Rubin wrote:
> > In article <[EMAIL PROTECTED]>, doc
> > <[EMAIL PROTECTED]> wrote:
> [...]
> > >Perhaps a more general way of asking this question is to
> > >inquire about the domain of the ciphertext.
> > >
> > >Or, is it possible to have a ciphertext that does NOT
> > >decrypt using DES?
> >
> > That wouldn't make any sense. It would mean the encryption was not
> > reversible.
>
> It is possible to have a reversible encryption algorithm with this
> property, but it would have to be probabilistic, and the ciphertext
> would have to be longer than the plaintext (a concrete example is
> DHAES).
Actually, there's no reason it would have to be probabilistic. Any
deterministic function whose output is strictly larger [1] than its input
will have certain output patterns that cannot be generated. If that
function is used to 'encrypt', then there will be 'ciphertexts' that cannot
be decrypted, as they don't correspond to any plaintexts. And, as long as
that function was also one-to-one, then any ciphertext that was also
actually generated by the cipher can be decrypted, so it would be a possible
encryption method.
[1] ObMath: As long as you use Cantor's definition of larger, this is true
for functions with infinite inputs and outputs.
--
poncho
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Checking for a correct key
Date: Tue, 28 Mar 2000 06:31:35 GMT
On Sun, 26 Mar 2000 04:38:10 +0200, Thomas Luzat
<[EMAIL PROTECTED]> wrote, in part:
>2 seems to be not a good solution, but what about 1 and 3; Are they
>secure? Should I store those values encrypted together with the rest
>of the file, too? Are there better methods?
Your listing of methods suggests a way to improve on them; one could
hash the file plus the key, and then encrypt that hash along with the
file. Thus, even if the hash function is weak, the hash doesn't relate
to the key or the file by itself, and thus is less likely to aid in
breaking the cipher.
I remember seeing an explanation of how PGP worked: it improved
security by taking the checksum it used, and enciphering it along with
random data in several blocks, IIRC. This suggests that even taking
the hash, and splitting it up so that one byte of the hash was
included in a cipher block with seven (or fifteen) bytes of the
message would be a way to further reduce the risk created by doing
this.
Also possible is this:
Take the user-supplied key. Generate two keys from it by a
cryptographically-secure hash function. Encrypt the message by a
method sufficiently secure to protect it, used by itself. Take a
checksum of this encrypted message, and append it to the encrypted
message. Then, encrypt the result using the second key.
This way, while the hash adds redundancy to the message after the
first step, helping attacks on the second step, there is nothing that
helps in attacking the first step except the fact that its key is
derived from the same key as also produced the key to the second step.
So this method also depends on the hash function being really
non-invertible, but at least it compounds the problem for the
attacker.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: JohnNY <[EMAIL PROTECTED]>
Subject: A good encryption program?
Date: Tue, 28 Mar 2000 02:07:32 -0500
Reply-To: [EMAIL PROTECTED]
I hope I am posting this question to the right group. If not, would
you please direct me to it?
I am looking for a good encryption program (freeware or shareware)
which will encrypt both folders and a zip disk. Ideally, it would
offer choices like Blowfish and IDEA.
Sincere thanks for any help you are able to give.
John
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Mon, 27 Mar 2000 23:08:13 -0800
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> [ ... ]
>
> > I will not accuse you of being a liar.
> > I will not accuse you of being an idiot.
> > I will not accuse you of being stupid.
>
> You then go on to attempt to imply each of the above, in essence
> making a liar of yourself.
>
> > Although a case could be supported for each of the above.
> >
> > 1) CASE: liar. You say the theory, and specification of the
> > procedures and processes have not been made available. Not true.
> > The theory, and specification of the procedures and processes have
> > been available for some time now at http://www.ciphile.com
>
> This is where the BIG lie comes into the picture: you have some
> garbage that you SAY covers the theory and the specification of
> procedures and processes, but as has been pointed out repeatedly in
> the past, what you've posted covers nothing of the sort; it contains
> nothing more than hand-waving. Based on its content, there are two
> possibilities: either you don't really know how your software works,
> or else you're intentionally covering things up to prevent the rest
> of the world from knowing how it works. Regardless of how they got
> to the sad state they're in, the portions of your help files that
> talk about the algorithm you use are utterly worthless and useless.
>
> > 2) CASE: idiot. "01234567890123456789... Each output digit will
> > occur an exactly equal number of times making a bias of exactly
> > zero." Not quite. Bias refers to any patterns that can be
> > discerned and exploited cryptoanalytically. There is clearly a
> > pattern here, the sequence is predictable, etc.
>
> Bias does NOT refer to any pattern that can be discerned and
> exploited. Bias refers specifically and ONLY to a sequence
> containing different digits at different frequencies. As expressed
> (in decimal) the sequence above is absolutely free of bias: every
> digit occurs exactly twice. If each digit is expressed in binary,
> there is a bias: 0 bits occur more often than 1 bits.
>
> The obvious predictability in this case is not bias, but correlation:
> correlation refers to being able to predict the next part of the
> sequence based on previous parts of the sequence. The sequence given
> above is free of bias, but highly correlated.
>
> It's long been said that it's better to stay silent and be thought a
> fool than speak and remove all doubt. Even if he doesn't learn the
> accepted terminology for the concepts, anybody designing a cipher
> should certainly have thought about things enough to classify
> predictability into the two basic areas normally referred to as bias
> and correlation. By claiming that there IS only one class, you've
> shown not only that you're ignorant of the terminology, but that
> you've given insufficient thought to the ways in which an attacker
> can and will look at the output from your program. In short, by
> speaking, you removed all doubt; it's obvious that you can't possibly
> have taken into account the factors necessary to do a good job of
> design a cipher, because you deny the very existence of those
> factors.
>
> > 3) CASE: stupid. "By adding a new process you inherently add
> > ability to "mix things up even more." That is simply not the
> > case..." Oh, really? In the popular state lotteries or in the
> > gambling game of keno, you may pick six numbers. Six of eighty
> > ping pong balls numbered 1 - 80 are randomly selected. Let's
> > say you bet one dollar for your pick six. If I decide to add
> > 80 more ping pong balls making a total of 160 and keep your
> > potential winnings the same, will you now bet two dollars?
>
> Your comparison is invalid for a number of reasons. First and
> foremost, adding more balls to a lotto machine does NOT add "a new
> process" -- it only adds more balls that will be processed in exactly
> the same fashion. Rather than being analogous to a new encryption
> algorithm, it's roughly equivalent to using a larger key with exactly
> the same algorithm (which of course requires an algorithm that
> supports both key sizes).
>
> Second, with the balls in a lotto machine, much like a cipher, there
> may be unforseen side-effects of using twice as many balls. In the
> case of a lotto machine, you would probably need a bigger box and/or
> a longer time for them to mix up before the order of them balls is
> completely unpredictable. If you used exactly the same process
> otherwise, it's entirely possible that the balls simply would not mix
> well at all.
>
> Now, to be truly analogous to adding a new process, what you want to
> discuss would be something that retains exactly the same number of
> balls, but attempts to randomize them better. For a couple of
> examples, the balls are normally rolled into the box in order, then a
> blower is turned out to mix them up. Two possible processes you
> could add would be to 1) mix the balls up ahead of time, so they're
> rolled into the machine in a random order, or 2) have the air
> pressure and/or volume from the blower varied in a random fashion.
>
> I don't believe that either of these would have any good effect at
> all -- statistical studies have shown that the output is already
> quite thoroughly unpredictable, and therefore adding these new
> processes would accomplish nothing useful.
>
> > You admit to not having read the Help files or insist that
> > you are unable to understand them, you have not gotten the
> > software: in other words, you don't know what you are talking
> > about yet you seem to be an authority on OAP-L3. Incredible!
>
> I've read and understood the help files. They were _obviously_
> written to impress people with complexity, NOT to provide adequate
> information for cryptanalysis or say anything about the strength of
> the encryption provded. Since you claim they provide real, solid
> information, there are really only two possiblities: either you're so
> grossly incompetent that you haven't a clue of what you need to
> provide, or else you're intentionally withholding the information you
> know is necessary.
>
> > I really get satisfaction knowing that my work has gotten to you.
> > Can't refute the facts can you.
>
> Facts, by their nature, can't be refuted. Fortunately for those of
> us who refute your claims on a regular basis, facts are only rarely
> to be found among your claims. So far, on the rare occassion that
> you DO say something that's truly factual, it's not really related to
> your original argument at all.
>
> > There is a very real encryption
> > software package here to address. It's tangible.
>
> The software is tangible. The security is not.
>
> > But I am afraid nearly everything you have said to date has been
> > unscientific, insupportable or unsupported, and without merit.
>
> You should be afraid, but mostly because the criticisms of your
> software are well supported by facts.
>
> > By the way, I have had tremendous traffic at my web site where many
> > many copies of the OAR-L3: Original Absolutely Random Level3 random
> > number generation software has been being downloaded.
>
> Great. What does this have to do with anything? Do you honestly
> believe that lots of traffic somehow means the product is of high
> quality? In the past you've seemed intelligent but misguided.
>
> Recently, your statements about traffic levels, who's downloaded your
> software, etc., make it sound a great deal more as if you aren't very
> intelligent after all.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
I did not accuse anyone of being a liar, an idiot, or stupid. I
merely said a case could be made. And I pointed out the basis of
such a hypothetical case.
How can someone defend an accusation that what they have written
is garbage when the person making the claim does not support such
a claim with factual support?
If frequency is the same as bias, why did they apply the word
bias to describe the same thing in a science? Could it have been
that a lazy scientist felt it would be less effort to write or
speak the word bias instead of frequency because bias only has
four letters and two syllables while frequency has nine letters
and three syllables?
Do you know the name of this news group? It is sci.crypt. It
refers to cryptography. My definition of "bias" is the one in
the field of cryptography. What field of study does your
definition of "bias" relate to?
I could go on but certainly your irrelevant insistence borders
on something other than the search for truth.
When you cannot attack the encryption theory you continue to
attempt to attack the originator of the encryption software.
We would all like to hear from you why the theory is bogus with
factual support of your position.
Or maybe you should just forget about it.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Mon, 27 Mar 2000 23:04:17 -0800
Eric Lee Green <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Jerry Coffin wrote:
> > Despite this, if a particular person's vote is represented (for
> > example) as a single bit, with a 0 representing a vote for one
> > candidate, and a 1 a vote for the other, I can easily switch
> > everybody's votes: I simply toggle the bit from whatever it presently
> > is, to the other possible value.
>
> That is why no serious encryption protocol would lack at least a CRC
checksum
> to make sure that the data received has not been messed with. In reality,
> you'd also have a sequence number and salt value in order to prevent
replay
> attacks, and you'd probably also have a cryptographically secure digest
rather
> than a plain old CRC (much harder to find a plaintext that encrypts to the
> same checksum then).
You do realize that, other that the cryptographically secure digest, none of
your suggestions does much of anything against the attack Mr. Coffin
described above. A sequence number and a salt value do nothing -- this
isn't a replay attack, and he doesn't care whether he ever sees another
packet encrypted with the same keystream. And, since a CRC is linear, the
attacker can easily compute which bits he needs to flip in the CRC to make
the decrypted CRC come out correctly for the packet with the altered vote
(without him knowing the actual value of any bits of the message or the
CRC).
--
poncho
------------------------------
** 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
******************************
