Cryptography-Digest Digest #216
Cryptography-Digest Digest #216, Volume #14 Mon, 23 Apr 01 15:13:01 EDT
Contents:
Re: C code for GF mults (David Eppstein)
Re: OTP WAS BROKEN!!! (John Savard)
Re: OTP WAS BROKEN!!! (Tom St Denis)
Re: OTP WAS BROKEN!!! (John Savard)
Re: OTP WAS BROKEN!!! (John Savard)
Re: First cipher (Mark Wooding)
Re: OTP WAS BROKEN!!! (John Savard)
Re: OTP WAS BROKEN!!! ([EMAIL PROTECTED])
Re: OTP WAS BROKEN!!! (Ichinin)
Re: OTP WAS BROKEN!!! (Mark Wooding)
Re: C code for GF mults (Mike Rosing)
Re: compare PRNG ( ink)
Re: OTP WAS BROKEN!!! (John Myre)
Re: OTP WAS BROKEN!!! (newbie)
Re: XOR TextBox Freeware: Very Lousy. (HiEv)
Re: OTP WAS BROKEN!!! (newbie)
Re: No base64 (Jack Lindso)
Re: OTP WAS BROKEN!!! (Joe H Acker)
First analysis of first cipher ([EMAIL PROTECTED])
Re: OTP WAS BROKEN!!! (Scott Craver)
Re: compare PRNG (M.S. Bob)
Re: RSA-like primes p and q (Dobs)
Re: UNCOBER = Universal Code Breaker (Joseph Ashwood)
From: David Eppstein [EMAIL PROTECTED]
Subject: Re: C code for GF mults
Date: Mon, 23 Apr 2001 09:04:28 -0700
In article 3YQE6.31605$I5.161433@stones,
Brian Gladman [EMAIL PROTECTED] wrote:
I suspect that Conway's method of multiplication is equivalent to the use of
this method for field extension but I have not yet looked at this again
since I saw your formulation.
Conway proves that his version is equivalent to repeatedly extending by
polynomials of the form T^2+T+c, where c is the last power of two in the
integer ordering of the previous stage.
I'm not sure how this relates to Jyrki's choice of extending by the
polynomial T^2+x_{i-1}T+1=0.
--
David Eppstein UC Irvine Dept. of Information Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: OTP WAS BROKEN!!!
Date: Mon, 23 Apr 2001 16:16:22 GMT
On Mon, 23 Apr 2001 02:58:24 GMT, zkn3 [EMAIL PROTECTED] wrote, in
part:
Small point: I believe infinity squared is still aleph-null, hence, not
larger.
That's true in terms of cardinality.
However, if you have that the probability of one event is p, and the
probability of another event is q, which equals p squared, and the
other event only occurs when the first one does, then the conditional
probability of the second event, given the first, is p; and the limit
of that, as p goes to zero, is zero, even though both p and q are
equal to 1/aleph-null.
Essentially, the discussion in the previous post referred to
infinitesimals and the like in *measure* terms, not cardinality terms.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: OTP WAS BROKEN!!!
Date: Mon, 23 Apr 2001 16:16:40 GMT
newbie [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I'm going to be more clear.
If the sender re-use his key to encrypt any message, I will certainly
recover the 2 plaintext.
If the sender re-use his key to encrypt any message then he's not using an
OTP. Si le person utiliser leur clef deux fois ou plus ce n'est pas un OTP
donc votre poste n'est pas applicable aux sujet de la poste. Is that clear?
(my french is rusty...)
HE DID NOT. He use only once his PAD.
What I'm trying to exploit is nothing more than REUSING HIS OWN PAD.
Then don't claim it as a break for an OTP. It's a break of a Vinegere
cipher nothing more.
Tom
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: OTP WAS BROKEN!!!
Date: Mon, 23 Apr 2001 16:22:21 GMT
On Sun, 22 Apr 2001 19:20:43 -0300, newbie [EMAIL PROTECTED]
wrote, in part:
I knew it.
Do not be skeptical please.
Just try to understand my idea.
Please.
It is based on the simulated re-use of OTP.
If I reuse twice OTP you can break it for sure.
That is the trick that I used.
It is very simple.
Yes, you can break the OTP very easily if you reuse it.
But your method does not 'simulate' the re-use of the OTP, because you
can't do that unless you already have the key.
Your explanation was very hard to follow, but now it seems to make
more sense:
you have both a 'most probable plaintext' and a 'fixed standard
message'. You use the actual ciphertext and the most probable
plaintext to obtain a guess at the key.
But in the next step, you use neither that guess at the key, nor the
actual ciphertext, with the fixed standard message, so either the
ciphertext or key you used were grabbed out of the air somehow. So I'm
afraid you lost me there.
Again, your method, though, seems to be based on the same fallacy:
that you can look at a possible keypad, and reject it when it doesn't
look random enough. You have no real chance of gaining useful
information that way.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: OTP WAS BROKEN
Cryptography-Digest Digest #216
Cryptography-Digest Digest #216, Volume #13 Fri, 24 Nov 00 05:13:00 EST
Contents:
Re: DES question: Has this ever been proven before? (David Wagner)
Re: A Simple Voting Procedure (Dan Oetting)
Re: vote buying... (David A Molnar)
Re: vote buying... (David A Molnar)
Re: Isomorphic Elliptic Curves ("John A. Malley")
Re: DES question: Has this ever been proven before? (Francois Grieu)
Re: Man arrested in stolen Enigma case (Francois Grieu)
Cyrptography Digest Archive ? (Mark Harrop)
Re: DES question: Has this ever been proven before? (Francois Grieu)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: Entropy paradox (Mok-Kong Shen)
Re: RSA Signature ! (Francois Grieu)
Re: My new book "Exploring RANDOMNESS" ([EMAIL PROTECTED])
Re: Man arrested in stolen Enigma case (Richard Heathfield)
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: DES question: Has this ever been proven before?
Date: 24 Nov 2000 05:02:45 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
Paul Crowley wrote:
Better yet, use the techniques of
Paul C. van Oorschot and Michael J. Wiener.
Parallel collision search with cryptanalytic applications.
Journal of Cryptology, 12(1):1-28, 1999.
This finds collisions in a function f() by iterating f(), hugely
reducing memory requirements. If we can avoid using the disk
altogether, it should be much faster.
David Wagner, ISTR you demonstrated this by finding collisions in the
Unix password hashing function. Do you still have source for that, and
is it available online?
I seem to have misplaced the source, but an example of the results may
be found at http://www.cs.berkeley.edu/~daw/my-posts/crypt-collision.
However, it was very easy to implement. Basically, you pick a set of
distinguished points (e.g., the 64-bit blocks whose low 20 bits are all
zero), then you iterate f() at high speed until you hit a distinguished
point. When you see a dist. pt., you enter it into some central table,
and then continue iterating. When you encounter the same dist. pt. twice,
then you've found a collision in f(), which is exactly what you wanted
to find. By storing the iteration count along with each distinguished
point in the central table, once you see a collision you can backtrack
to find the two pre-images that map to the same output.
--
From: Dan Oetting [EMAIL PROTECTED]
Subject: Re: A Simple Voting Procedure
Date: Thu, 23 Nov 2000 22:16:15 -0700
In article [EMAIL PROTECTED], David Schwartz
[EMAIL PROTECTED] wrote:
Stanley Chow wrote:
Properties under discussion:
p1) voter can prove, by himself alone, at his sole option, that
his vote is or is not correctly counted
p2) voter can be forced to reveal his vote against his will
The voter is displayed a GUID before he or she votes which he may or
may not write down. He then casts his vote. Immediately after the
election, all the GUIDs are released along with which way they voted. At
the same time the voter votes, he is shown one GUID (that is not his)
that was cast (by someone else) for each other candidate, which he may
or may not write down.
Why doesn't this meet 'p1' without providing 'p2'?
If the system is rigged, the alternate GUID's could be selected from a
small pool known to the atacker.
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: vote buying...
Date: 24 Nov 2000 05:04:14 GMT
David Hopwood [EMAIL PROTECTED] wrote:
All the attempted solutions I've seen fail to solve the problem that
voters' authentication credentials can be bought. (Authentication
credentials are whatever a voter knows or has that proves that they
are eligible to vote, and that distinguishes them from another voter -
e.g. keys or smartcards.)
What do you think of making the credentials sufficiently important for
other things as well that they're too expensive to buy in bulk? e.g. the
credential allows voting, but it also allows access to a bank account, so
you need to pay someone his bank balance or more before he'll give it up.
This is only a partial solution, but it seems better than nothing.
It seems to be the approach Brands takes in parts of his book on
credentials. But I shouldn't speak much about that until I've read more of
it.
-David
--
From: David A Molnar [EMAIL PROTECTED]
Subject: Re: vote buying...
Date: 24 Nov 2000 05:35:56 GMT
David Wagner [EMAIL PROTECTED] wrote:
One thing that I do find interesting about the Presidental election
system is the lack of preferental voting.
Maybe only a cynic would point out at this point that the two major
parties have an interest in keeping the current system the way it is,
but I guess noone will dispute that preferent
Cryptography-Digest Digest #216
Cryptography-Digest Digest #216, Volume #12 Thu, 13 Jul 00 00:13:01 EDT
Contents:
Re: Steganographic encryption system (Michael Rozdoba)
Re: Elliptic Curves encryption (Greg)
Re: Elliptic Curves encryption (Greg)
Re: Elliptic Curves encryption (Nicol So)
Re: Proposal of some processor instructions for cryptographical ("Douglas A. Gwyn")
Re: Crypto jokes? (potentially OT) ("Douglas A. Gwyn")
Re: Definition question ("Douglas A. Gwyn")
Re: cray and time needed to attack (Greg)
Re: cray and time needed to attack (Greg)
Re: Efficient Arithmetic Coding ("Douglas A. Gwyn")
Computing with Encrypted Functions (Austin Godber)
Re: Bit Shuffling ("Adam Durana")
Re: RC4-- repetition length? ("Scott Fluhrer")
Re: New Idea - Cipher on a Disk (Greg)
Re: DES Analytic Crack ("Douglas A. Gwyn")
Re: Q: Hadamard transform ("Douglas A. Gwyn")
Re: Base Encryption: Strongest Cypher (Boris Kazak)
Re: New Idea - Cipher on a Disk (Greg)
Re: Base Encryption: Strongest Cypher ("Douglas A. Gwyn")
From: Michael Rozdoba [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,uk.comp.os.linux
Subject: Re: Steganographic encryption system
Date: Thu, 13 Jul 2000 02:00:31 +0100
In article [EMAIL PROTECTED], phil hunt
[EMAIL PROTECTED] wrote:
On Wed, 12 Jul 2000 04:02:56 +0100, Michael Rozdoba [EMAIL PROTECTED]
[Snip]
Surely that depends on the definition of strong? If it merely means
hard to decrypt without the key, that doesn't contradict the statement
that the encrypted data is recognisable as encrypted data.
Well, it seems to me that "strong" means that no-one can proctically
find out any useful information about the plaintext if they know the
ciphertext (obviously the size of the ciphertext file places a maximum
limit on the complexity of the plaintext, but that should be it).
If you can tell that the plaintext contains repeated blocks, that could
help an adversary.
Ah, I think one of us has misunderstood Frank. You seem to have inferred
that one can identify repeats in the plaintext from the cipher text, while
I took him to mean one could spot repeats in the ciphertext (implying it
was cipher text not noise) - hence my original comment below.
Perhaps I'm mistaken. It happens a lot.
So how do I get it so it doesn't repeat?
Do you need to? You were going to rely on the source being public to
prove it extends filesizes thus a 25KB cipher text might legitimately
only contain a 1KB plain text. Would this not still work, as long as
the remaining data is not noise, but rather, is encrypted noise?
I want the program to be as strong as possible, to give away as little
as possible.
--
_ _
Michael RozdobaICQ: 15835336|_| |_ | |_| i'm trapped| | |
Ashamed to belong to a club called ACNE | | |_ |_ | in reality ... o o o
mroz at ukgateway dot net//. homepage coming soon .
--
From: Greg [EMAIL PROTECTED]
Subject: Re: Elliptic Curves encryption
Date: Thu, 13 Jul 2000 02:29:31 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (DJohn37050) wrote:
The P1363 password is easy to get, just ask for it, this allows them
to monitor
usage.
Don Johnson
I got a password and now I regret it. Why won't they just
make it freely available? I now get e-mail all the time
on ongoing conversations between other members of the group
that I don't care for. Perhaps it is easy to remove? But
it is really silly to begin with...
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Greg [EMAIL PROTECTED]
Subject: Re: Elliptic Curves encryption
Date: Thu, 13 Jul 2000 02:30:05 GMT
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (DJohn37050) wrote:
The P1363 password is easy to get, just ask for it, this allows them
to monitor
usage.
Don Johnson
Also, I think the password might be MarsRoks or MarsRock or something
like that.
--
Tyranny is kept at bay by guns and will. Our government
knows we have the guns, but they don't know if we have
the will. Nor do we.
The only lawful gun law on the books- the second amendment.
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Nicol So [EMAIL PROTECTED]
Subject: Re: Elliptic Curves encryption
Date: Wed, 12 Jul 2000 22:43:11 -0400
Reply-To: see.signature
Greg wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (DJohn37050) wrote:
The P1363 password is easy to get, just ask for it, this allows them
to monitor
usage.
Don Johnson
I g
Cryptography-Digest Digest #216
Cryptography-Digest Digest #216, Volume #11 Mon, 28 Feb 00 23:13:00 EST
Contents:
Re: Cryonics and cryptanalysis (Tim Tyler)
nonces - a definition (Anthony David)
Best language for encryption?? ("Vinchenzo")
Re: Cryonics and cryptanalysis (John Savard)
Question about password psychology and linguistics ("Seeker")
Re: Status of alleged *THIRD* key in MS Crypto API ? ("Douglas A. Gwyn")
Re: Q: 'Linear encipherment' ("Douglas A. Gwyn")
Re: On jamming interception networks ("Douglas A. Gwyn")
Re: Can someone break this cipher? ("Douglas A. Gwyn")
Re: code still unbroken ("Douglas A. Gwyn")
Re: Best language for encryption?? ("Douglas A. Gwyn")
Re: Question about password psychology and linguistics ("Douglas A. Gwyn")
Why aren't there any newsgroups on Steganography?? ("Amit IG")
Re: Best language for encryption?? (SCOTT19U.ZIP_GUY)
Source Code Available
Re: Why aren't there any newsgroups on Steganography?? (David A Molnar)
Re: How do I get the key from the passphrase in DES? (Bill Unruh)
Re: code still unbroken (lordcow77)
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Cryonics and cryptanalysis
Reply-To: [EMAIL PROTECTED]
Date: Mon, 28 Feb 2000 22:02:05 GMT
John Savard [EMAIL PROTECTED] wrote:
: Jerry Coffin [EMAIL PROTECTED]:
:Therefore, the real trick to cryogenics accomplishing anything is to
:give a motivation for people to bother un-freezing your body when a
:cure is found for whatever disease you have.
: Actually, the motivation is quite obvious; people will be motivated to
: unfreeze the frozen so that, in their turn, they will be unfrozen
: themselves.
If you think this will work, here's a marketing scheme for you - used by
the ancient Egyptians, no less.
Send $5 to each address on the following list. Then delete the last name
on the list and add your name to the top, and forward the message to all
your friends (and even some strangers).
Make /sure/ you send the $5 to each person on the list - or the scheme
won't work. *Only* if you act for the benefit of others /now/ can you
hope to reap rewards in the future.
In no time at all you'll have the $$$s rolling in ;-)
[pre-emptive snip]
: This will also motivate people not to contribute to a population
: problem (or to tolerate one existing as the result of the activities
: of a minority of people uninterested in longer life spans).
Motiviating people not to contribute to the population problem is tricky,
due to the way folks are built. I doubt cryonics will help.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
AAAHHH... AAAHHH... AAAHHH... CHOOO!
--
Subject: nonces - a definition
From: Anthony David [EMAIL PROTECTED]
Date: 29 Feb 2000 09:35:07 +1100
Greetings
While explaining to management how our IPSec parameters are
setup, I came across the term "nonces".
After consulting the online Webster's 1913 and my Shorter Oxford
at home, the term is a Middle English word describing some thing
that exists for the moment or "for the once".
"Applied Cryptography" makes a number of references to the word
but I never found a definition it.
Is a nonce in cryptographic parlance simply a truly random
number generated for the purpose of (public) key exchange?
--
=
Gambling: A discretionary tax on | Anthony David
those who were asleep during high | Systems Administrator
school mathematics classes|
--
From: "Vinchenzo" [EMAIL PROTECTED]
Subject: Best language for encryption??
Date: Mon, 28 Feb 2000 17:43:05 -0500
I would like to know what would be the best programming language to write an
encryption/decryption utility, I expect to use RSA or some public key
algorithms.
My second question is: what encryption algo does the Unix encryption
standard uses?
Thanks
Vinchenzo
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Cryonics and cryptanalysis
Date: Mon, 28 Feb 2000 16:20:36 GMT
Tim Tyler [EMAIL PROTECTED] wrote, in part:
If you think this will work, here's a marketing scheme for you - used by
the ancient Egyptians, no less.
They invented the chain letter? Something I didn't know about history!
However, I don't think that this works the same way; it is a question
of responsible behavior, not foolish behavior. If cryonics is seen to
"work", it will ultimately be handled by the government in most
countries, even if not in the U.S., just like the rest of medical
care, or the telephones or the post office.
Motiviating people not to contribute to the population problem is tricky,
due to the way folks are built. I doubt cryonics will help.
I'm thinking that if it beco
Cryptography-Digest Digest #216
Cryptography-Digest Digest #216, Volume #10 Fri, 10 Sep 99 11:13:03 EDT Contents: Re: some information theory (SCOTT19U.ZIP_GUY) Re: Looking for an asymmetric system (DJohn37050) Re: unix clippers that implement strong crypto. (SCOTT19U.ZIP_GUY) Double encryption is patented (mabey) (Anonymous) Re: Help me please with *.mpg.00* (Richard Herring) Re: some information theory Re: Looking for an asymmetric system (Emmanuel Drouet) Re: Looking for an asymmetric system (Tom St Denis) Re: Schneier/Publsied Algorithms (Anonymous) Re: some information theory (Mok-Kong Shen) From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) Subject: Re: some information theory Date: Fri, 10 Sep 1999 14:07:35 GMT In article [EMAIL PROTECTED], Anti-Spam [EMAIL PROTECTED] wrote: John Savard wrote: Anti-Spam [EMAIL PROTECTED] wrote, in part: Compression with huffman-encoding type schemes is identical to a substition encipherment. The relative order of SYMBOLS as ENCODED in the uncompressed data/file with ASCII, UNICODE or any other binary representation is PRESERVED by the compression Yes, with static Huffman compression. Not with _adaptive_ Huffman, or Lempel-Ziv. Compressing data/files prior to encryption with a cipher system does not alter the frequency of the SYMBOLS encoded in the compressed data/file relative to their original frequencies in the uncompressed file/data. Compressing prior to encrypting does not permutate the order of the SYMBOLS encoded in the compressed data/file relative to their original order as encoded in the uncompressed file/data. Compression only alters the encoding of the SYMBOLS to achieve the maximal entropy possible as a function of the probabilites of the SYMBOLS themselves. Not compression in general, but a particular limited form of compression. For cryptographic purposes, it is important to compress as well as possible. So instead of using single ASCII characters as SYMBOLS, how about compression where digraphs, trigraphs, and even English words are SYMBOLS? Even simply a multi-mode Huffman code, where letters are coded based on their frequencies after a vowel, or after a consonant, or at the beginning of a word, will help. First, Compressed data is NOT necessarily random data. Many of us assume the compressed form of a file is "equivalent" in some form to true random data. It is not. No, but the better the compression, the closer the compressed file will resemble random data. You are right, though, that it is very difficult to compress well enough to get very close to randomness. But it is incorrect, and confusing, to conclude from that that it is impossible to derive any benefit from compression. The benefit is, unfortunately, limited. I DO NOT conclude that it is impossible to derive any benefit from compression prior to encryption. I am exploring the logical holes in the assertion that compression supplies the diffusion and confusion properties of encryption in and of itself. Many of the posts read here imply ( or is just the way I read it? :) ) that compression achieves the desired effects of encryption without using encryption. The static Huffman encoding for compression is equal to a simple substitution of the binary codes for the symbols in the uncompressed data/file into another binary code for those symbols in the compressed data/file. The order and frequency of the symbols remains invariant. That's not a very secure "hiding" of symbols. I am on the hook to extend this analysis to adaptive encoding for compression (such as adaptive huffman encoding for compression.) I've thought about it most of the day. I can only post at night. I've enjoyed the responses. John unless you can break new ground your fighting an uphill battle. In staic huffman coding you can send just the last half of file and it is trivial to reconsturct the underlying message. This is not so with "adaptive huffman compression". If you have a normal ascii message it would be very hard to even determine what the last symbol sent was. Using my file ending method the "all zero" weakness is not as weak as you may think. I still use a tree with only 256 leaves and one can not even tell by looking at the end of the file where the last symbol ended or started. If you only have the last half of a file. You don't even know where any symbol starts. You may be starting in the fragment of a symbol since there is no reference point for the start or end of any symbol. To decode you would have to guess the starting position of the first complete symbol and then guess its value. This is not a trivail task and has been looked at for years. It is not like your multisubsittution cipher in that they can be broken by plain text attacks. What you have when your looking at the last half of a file compressed with an adaptive huffm
