Cryptography-Digest Digest #171
Cryptography-Digest Digest #171, Volume #14 Tue, 17 Apr 01 23:13:00 EDT
Contents:
Re: "UNCOBER" = Universal Code Breaker ("Joseph Ashwood")
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker ("Jack Lindso")
Re: Advantages of attackers and defenders (Bart Bailey)
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: "UNCOBER" = Universal Code Breaker (newbie)
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker ("Tom St Denis")
Re: lagged fibonacci generator idea ("Scott Fluhrer")
Re: Distinguisher for RC4 ("Scott Fluhrer")
Re: lagged fibonacci generator idea ("Tom St Denis")
Re: "UNCOBER" = Universal Code Breaker (David Formosa (aka ? the Platypus))
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: DES Optimizaton - Can Someone Explain? (John Savard)
Re: C code for GF mults ("Brian McKeever")
From: "Joseph Ashwood" [EMAIL PROTECTED]
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Tue, 17 Apr 2001 16:11:34 -0700
"newbie" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I'm not talking about universal algo, but about "unified theory".
Theory means designing concepts and tools to solve types of encryption.
Theory means thinking to hypothesis, conditions etc... to solve any
encryption.
Theory means conceptual vision of the cryptanalysis concern.
Theory does not mean creating a super-algo breaker.
But the existance of a single algorithm which can provably not be broken by
such a theory eliminates the possibility of that theory. The One-Time-Pad
algorithm exists, therefore a unified theory that "solves" (aka breaks,
because there is no other possibility) an encryption algorithm cannot exist.
I proved that at least 2 ways now.
Joe
--
From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Tue, 17 Apr 2001 23:20:40 GMT
"newbie" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I'm not talking about universal algo, but about "unified theory".
Theory means designing concepts and tools to solve types of encryption.
Theory means thinking to hypothesis, conditions etc... to solve any
encryption.
Theory means conceptual vision of the cryptanalysis concern.
Theory does not mean creating a super-algo breaker.
What are you yabbing about? He proved that it can't exist given you can't
break an OTP
Tom
--
From: "Jack Lindso" [EMAIL PROTECTED]
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 02:42:21 +0200
The fact that TRUE OTP is unbreakable doesn't contradict the existence of a
cryptanalysis algorithm e.g. a set of rules or a function which tries to
evaluate encrypted cipher text.
Perhaps Code Breaker is a wrong name for it, a Cryptanalysis Algorithm would
be a better one :
1: check the deviation from RAND
2: Try shifting
And so on.
--
Anticipating the future is all about envisioning the Infinity.
http://www.atstep.com
"Tom St Denis" [EMAIL PROTECTED] wrote in message
news:cd4D6.33598$[EMAIL PROTECTED]...
"newbie" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
I'm not talking about universal algo, but about "unified theory".
Theory means designing concepts and tools to solve types of encryption.
Theory means thinking to hypothesis, conditions etc... to solve any
encryption.
Theory means conceptual vision of the cryptanalysis concern.
Theory does not mean creating a super-algo breaker.
What are you yabbing about? He proved that it can't exist given you can't
break an OTP
Tom
--
From: Bart Bailey [EMAIL PROTECTED]
Subject: Re: Advantages of attackers and defenders
Date: Tue, 17 Apr 2001 16:46:46 -0700
AY wrote:
, but I am not sure how the knowledge of "network
terrains" can help defend against attackers.
Knowledge of the nomenclature and locations of bait files and tripwires would,
hopefully, be held by the defenders and not the attackers. There could be some
rearranging of these resources as attack methods are exhibited.
~~Bart~~
--
From: newbie [EMAIL PROTECTED]
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Tue, 17 Apr 2001 19:51:28 -0300
You are starting to elaborate it.
This t
Cryptography-Digest Digest #171
Cryptography-Digest Digest #171, Volume #13 Thu, 16 Nov 00 22:13:01 EST
Contents:
RE: Big-block cipher, perhaps a new cipher family? ("Manuel Pancorbo")
Re: Hitachi - on what grounds ?? ("Paul Pires")
Re: Big-block cipher, perhaps a new cipher family? (Terry Ritter)
Re: Hitachi - on what grounds ?? (Terry Ritter)
Re: Is Triple DES the BEST Algorithm ? (Tom St Denis)
Re: Re: ECC help please ("James Russell")
Re: My new book "Exploring RANDOMNESS" (Greggy)
Silly idea to prevent decrypt (Silly Things)
Re: Book recommendation, please (Greggy)
Re: Randomness from key presses and other user interaction (Steve Roberts)
Re: voting through pgp (Sundial Services)
Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys! ("George
Peters")
Re: Silly idea to prevent decrypt (Tom St Denis)
[Question] Export restrictions on following algos. (Shri Desai)
[Question] XOR encryption (Shri Desai)
[Question] Generation of random keys (Shri Desai)
Re: My new book "Exploring RANDOMNESS" (Tim Tyler)
From: "Manuel Pancorbo" [EMAIL PROTECTED]
Subject: RE: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 00:27:03 GMT
"Mok-Kong Shen" [EMAIL PROTECTED]
But in the scheme you described there are the functions
F and G which you don't specify in detail.
I will; give me a couple of days and I'll publish the whole code with
graphic explanation and test packets.
If the F is
not good, you wouldn't have good diffusion.
In fact I have no *good* diffusion: only 16 bits (for F) and 24 bits (for G)
out of 32, are affected by a single bit change in input *at the first step*.
Good diffusion is obtained by running this kernel cipher over the packet
(and backwards).
One can have
a combination of stream and block techniques. I designed
one with a block size of 640 bits driven by a PRNG with
feedback to the PRNG by hash values obtained during the
processing and with block chaining. In other words, the
state of the PRNG is influenced by the plaintext blocks
and the processing of the blocks is determined by the
PRNG outputs and the successive blocks are chained. See
my web page.
My cipher method has no upper limit (except the system memory) for the
packet size. You can apply it to a 1 MByte file without chaining (provided
enough memory).
Nevertheless I don't pretend be original. The question is: if this
"large-block-stream-ish" ciphers are really faster than traditional block
ciphers, good diffusive and strong against known attacks... why not give
them more attention?
--
Manuel Pancorbo
[EMAIL PROTECTED] (Apply ROT13)
--
From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: Hitachi - on what grounds ??
Date: Thu, 16 Nov 2000 16:49:19 -0800
Snip
If you have other methods which the communication partners
can easily and safely employ (i.e. without weakening
the cipher) and hinder the work of the opponent, then it
would be fine if you would let others of the group partake
you knowledge through posting these to the group.
Anyway, if you think that posts (not only those of mine)
you see in the group do not contain materials giving
sufficient answer to your five questions listed in a
previous follow-up, then please be kind enough to say so.
This is why we have a 'discussion' forum, isn't it?
As usual you and I are misconnected, I'm trying to back out
of it gracefully. If you wish to continue the discussion by E-mail
I will be happy to do so. I am feeling a little self concious about
how the group feels about this and don't want to continue this
here as it has gone way past anything usefull or interesting.
I don't have any problems, criticisms or questions about the
thread you mentioned. I also have no interest in the topic.
I suggested the questions as general content for the hypothetical
or example situation you originally brought up, not any actual thread
that might exist. Which, by the way, has nothing to do with the
original topic of discussion.
I do not disparage the content or authorship of any of that
material since I have not read it and have no interest in the
topic or knowledge of the subject. You don't have to
prove me an idiot, I freely admit it after getting sucked
into another weird exchange with you. We have to stop
meeting like this.
For someone who has such a problem with English,
you sure don't seem to have a problem with
condecension, misdirection and snide comments.
Be careful, that Columbo act is wearing a little thin.
Paul
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov
Cryptography-Digest Digest #171
Cryptography-Digest Digest #171, Volume #12 Thu, 6 Jul 00 20:13:00 EDT
Contents:
Re: Beginner Questions (Bob Silverman)
Re: Crypto jokes? (potentially OT) ("Paul Pires")
Re: Data compression and encryption ("Douglas A. Gwyn")
Re: cray and time needed to attack ("Douglas A. Gwyn")
Re: A simple all-or-nothing transform (Mark Wooding)
A new cipher (Simon Johnson)
Re: Prime Numbers? ("Douglas A. Gwyn")
Re: Any crypto jokes? (potentially OT) ("Paul Pires")
Re: A thought on OTPs (Mok-Kong Shen)
Re: Crypto jokes? (potentially OT) (David A Molnar)
Re: Has RSADSI Lost their mind? ("Trevor L. Jackson, III")
Re: cray and time needed to attack ("Joseph Ashwood")
Re: RPK (David Hopwood)
Re: RPK (Simon Johnson)
Re: A new cipher ("Joseph Ashwood")
Re: Crypto jokes? (potentially OT) (Allan Crossman)
Re: Crypto jokes? (potentially OT) ("Paul Pires")
Re: Encryption and IBM's 12 teraflop MPC.. (Dan Day)
Re: Any crypto jokes? (potentially OT) ("Trevor L. Jackson, III")
Re: Any crypto jokes? (potentially OT) (Dan Day)
Re: Any crypto jokes? (potentially OT) ("Trevor L. Jackson, III")
Re: Crypto jokes? (potentially OT) ("Trevor L. Jackson, III")
From: Bob Silverman [EMAIL PROTECTED]
Subject: Re: Beginner Questions
Date: Thu, 06 Jul 2000 18:49:12 GMT
In article 8k2f0t$25o$[EMAIL PROTECTED],
"AC" [EMAIL PROTECTED] wrote:
Excuse my ignorance but cryptography is only a hobby for me.
A couple of posts talk about 1024 bit prime numbers. Do these numbers
=
have 128 digits (1024/8)?
No.
Hint: if a number has 1024 bits it is between 2^1023 and 2^1024-1.
Think about why you divide by 8.
Also, what is the most efficient, time wise, to handle 100+ digit =
numbers in C++? I have set up an array to hold each digit of a number
but this seems cumbersome and is terribly slow.
Use a radix bigger than 10. Use (say) 2^30
Now each number is represented as:
a0 + a1 * 2^30 + a2 * 2^60 +
Now store each a_i in a word of an array. This is much more
efficient than storing just 1 digit.
Read chapter 4 of Knuth Vol. 2. [This is ESSENTIAL reading]
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: Crypto jokes? (potentially OT)
Date: Thu, 6 Jul 2000 12:10:38 -0700
[EMAIL PROTECTED] wrote in message news:8k1r9e$qhl$[EMAIL PROTECTED]...
Does anyone know any crypto-related jokes or links to them?
Or perhaps someone could come up with an ingenious answer to the
question:
How may cryptographer does it take to change a light bulb?
One, but you can't *PROVE*
that it has been changed.
Thanks in advance for any suggestions
rot26
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: Data compression and encryption
Date: Thu, 6 Jul 2000 18:24:48 GMT
Dido Sevilla wrote:
Do all cryptologic transformations modify the information content
of a message, e.g. make a message compress better or worse than
the unencrypted message for some given compression algorithm?
That depends on the details. The general principle, however, is
that the ciphertext contains information from the key as well as
*all* the original plaintext information, so the ciphertext must
have more entropy than the plaintext, so in general terms it is
less compressible.
If so, then by how much?
No worse than by the amount of information in the encryption key.
However, the redunancy is usually is a much less accessible form
in the ciphertext than in the plaintext, so general-purpose
compression algorithms cannot exploit the redundancy and thus do
a lousy job of compression.
It seems that at the very least, the one-time pad would serve
to increase the information content of a message such that it
would be nearly impossible to compress by any means after
encryption, provided the OTP was properly produced.
In fact the information content of the ciphertext in the context
of the interceptor's knowledge is exactly that of a uniform
random bit (or character, or whatever) string of length equal
to that of the key (which is equal to the message length).
Such a "random" string can be compressed sometimes, but the
expected *average* performance of any predetermined (reversible)
compression algorithm for such strings is actually expansion.
Since the security of the OTP is what all cryptosystems aspire to,
am I correct in asserting that all encryption systems must increase
the information content of any message by an amount proportional to
the size of the key used?
I do
Cryptography-Digest Digest #171
Cryptography-Digest Digest #171, Volume #11 Mon, 21 Feb 00 01:13:01 EST
Contents:
Re: OAP-L3 Encryption Software - Complete Help Files at web site
([EMAIL PROTECTED])
Re: OAP-L3 Encryption Software - Complete Help Files at web site (Peter Rabbit)
Markku J. Saarelainen is William A. Nelson - vetakaa turpaan jokaista ("William A.
Nelson")
Re: Markku J. Saarelainen is not a Jew and has never been - he is just a ("Markku
J. Saarelainen")
Re: OAP-L3 Encryption Software - Complete Help Files at web site (Chuck)
Re: Question about OTPs ("Stephen M. Gardner")
Re: Markku J. Saarelainen is not a Jew and has never been - he is just a ("Markku
J. Saarelainen")
Re: Markku J. Saarelainen is William A. Nelson - vetakaa turpaan jokaista USAlaista
! ("Igor S.")
US secret agents work at Microsoft claims French intelligence report (Dave Hazelwood)
Re: Swapfile Overwriter: R.I.P. (Dave Hazelwood)
Re: Question about OTPs (Ralph Hilton)
Re: Does the NSA have ALL Possible PGP keys? (John Savard)
Re: OAP-L3 Encryption Software - Complete Help Files at web site (Terry Ritter)
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: EOF in cipher??? ("Douglas A. Gwyn")
Re: NSA Linux and the GPL ("Douglas A. Gwyn")
Re: NIST publishes AES source code on web ("Douglas A. Gwyn")
Re: NIST publishes AES source code on web ("Douglas A. Gwyn")
Game of General - Dictionary - Language and Updates ("Markku J. Saarelainen")
Re: NIST publishes AES source code on web ("Douglas A. Gwyn")
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Mon, 21 Feb 2000 00:00:51 GMT
Do you also think that no one should be interested in a utility
program that will overwrite a file completely where each BIT is
overwritten first with one's (every byte to ) and then the
entire file is overwritten again with zeros (every byte to )
to effectively wipe out any trace of the original data contained in
the file?
Look, as I've already told you, I am not a cryptographer, but even I know
that this method is not secure. Take a look at http://
www.cs.auckland.ac.nz/~pgut001/secure_del.html for better methods and a
quick overview on secure file deletion.
Greetings,
Erich Steinmann
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Peter Rabbit [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Mon, 21 Feb 2000 00:56:20 GMT
Anthony Stephen Szopa wrote:
"Tony L. Svanstrom" wrote:
Peter Rabbit [EMAIL PROTECTED] wrote:
Hey guys, give the guy a break. If you think is programme is snake oil
then it should not be hard to show just that. Until then it is unfair to
judge his prog. out of hand. Maybe he's on to something. You all seem to
forget that before "Chris" the world was flat!
Just take a look at this site...
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: http://www.pgpi.com/ \_@ @_/
--oOO-(_)-OOo-oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---ôôô---ôôô---ôôô---ôôô---
\O/ \O/ ©1999 http://www.svanstrom.com/?ref=news \O/ \O/
I think he has done better than that: he may have the software.
You are NOT talking to a fool when you address Mr. Rabbit.
So you better be careful you don't blow your cover with him like
you have already done with me.
I am not taking anybody's side here. All I am stating is: Investigate
before judging and then prove what you are asserting. That goes for both
sides. If your program stands the test of time and analysis... COOL, if
not... TOO BAD! I think if you want to silence your critics, publish
your algo. I know that IDEA, BLOWFISH, RC4 etc. are all available in
algo form to be analyzed and criticized. It might teach you or them
something. I don't know.
Peter Rabbit
--
From: "William A. Nelson" [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.soviet,soc.culture.nordic,soc.culture.german,soc.culture.ukrainian,soc.culture.israel,soc.culture.china,alt.2600
Subject: Markku J. Saarelainen is William A. Nelson - vetakaa turpaan jokaista
Date: Mon, 21 Feb 2000 01:14:57 GMT
Markku J. Saarelainen is William A. Nelson - vetakaa turpaan jokaista
USAlaista !
--
From: "Markku J. Saarelainen" [EMAIL PROTECTED]
Crossposted-To:
alt
Cryptography-Digest Digest #171
Cryptography-Digest Digest #171, Volume #10 Fri, 3 Sep 99 22:13:03 EDT
Contents:
Re: Schneier/Publsied Algorithms (Eric Lee Green)
Re: 512 bit number factored (Wei Dai)
Re: SQ Announcement (SCOTT19U.ZIP_GUY)
Re: Schneier/Publsied Algorithms (SCOTT19U.ZIP_GUY)
Re: 512 bit number factored ([EMAIL PROTECTED])
Re: Schneier/Publsied Algorithms (David A Molnar)
Re: Re: 512 bit number factored (Wei Dai)
More information on TEA available? ("Greg Keogh")
Re: Alleged NSA backdoor in Windows CryptoAPI ([EMAIL PROTECTED])
Re: Schneier/published algorithms (SCOTT19U.ZIP_GUY)
From: Eric Lee Green [EMAIL PROTECTED]
Subject: Re: Schneier/Publsied Algorithms
Date: Fri, 03 Sep 1999 23:17:02 GMT
"SCOTT19U.ZIP_GUY" wrote:
top five finalists. Sounds like it's pretty solid to me, though some of the
other AES candidates also have good points that make them worth looking at.
Yeah I've been wondering just what those "good points" are. Will the NSA
ever tell us.?
Probably not, but Brian Gladman ( http://www.seven77.demon.co.uk/index.htm ) is
not shy about what he sees as strengths and weaknesses. I'm sure I can find
others with their own opinions if I looked.
The biggest unknown is RC6. It is simple and fast -- but is it secure? Given
RSA's long flirtation with the NSA, that's the billion-dollar question. It's
hard to believe that something so simple could be secure, but on the other hand
the principle designers of RC6 do have a lot of experience in the field and
maybe they're just smarter than the rest of the AES contributors.
I *WILL* point out that design of block ciphers is not exactly brain surgery in
this day and age. This is a field which is, to a certain extent, mature, unlike
the field of public key encryption, which is still in its infancy.
-E
--
From: [EMAIL PROTECTED] (Wei Dai)
Subject: Re: 512 bit number factored
Date: Fri, 3 Sep 1999 17:24:48 -0700
In article 7qog0k$aj4$[EMAIL PROTECTED], [EMAIL PROTECTED] says...
A 700 bit number is about 730 times as difficult as 512-bits
in terns of *time* and 27 times as difficult in terms of space.
Each of these 20K computers will need 2 to 3 Gbytes of memory
(for the sieving phase)
In 1990 my Sparc-10 on my desk had 32M of RAM. Now, my
dual-proc P-450 has 256M. We *might* see workstations desktops
with 2-3Gbytes in 10 years, but I doubt that they will be common
enough to gather 20,000 of them for a year. I don't see most
applications needing that kind of memory. 512M??? Sure! But
not 3G.
First, nine years from now, you won't need 2 computers with 2-3 GB of
memory, you'll only need 500. Second, do you really need 2 to 3 GB of RAM
or can some of that space be hard disk space? Perhaps it is also possible
to trade off between time and space so you use 512 MB of space but more
time. I'm sure you know better than I do what the exact tradeoff is.
Finnally, even if you really do need 3 GB of RAM, at today's prices it's
only a couple thousand dollars. In 9 years 2 GB of RAM will probably cost
around $100.
It took a very large Cray (C90) 10 days and about 2.4 Gbytes
of memory to handle the matrix. I don't see Crays getting
significantly faster in the next 9 years. We might see a factor of
4 to 5, but I doubt more than that.
With C90 hardware, the matrix for 700 bits would take 7300 days
and require about 60 Gbytes of memory.
If vector-processing supercomputers are not improving as fast as
workstation CPUs, an obvious question to ask is whether distributed
memory parallel processing supercomputers (Intel has built one with 1.8
TFLOPS compared to 12 GFLOPS of the C90) can be used to solve the matrix
problem. Is there any reason why they can't?
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: SQ Announcement
Date: Fri, 03 Sep 1999 23:18:59 GMT
In article 7qpc53$nmk$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
In article 7qo4oi$[EMAIL PROTECTED],
Kostadin Bajalcaliev [EMAIL PROTECTED] wrote:
I have read Shannon theories, just compare my and your claim:
If we need more information than the output carry about them inner state of
the generator ...
when the output keystream length is longer than the key length, the
I do not see any logical conection.
My point is that, if the stream cipher uses a N-bit key, then we
need only N bits of information about the cipher to deduce the inner
state, total.
Thus, by looking at N bits of output, we are guaranteed to have enough
aggregate information to break the cipher (if there are no bounds on
our computing power).
I believe this means that the "Information Lose" theory does not apply
to any cipher which generates more than N bits of output: if more than
N bits of information about the output are available, then the output
carries enough infor
