Cryptography-Digest Digest #552
Cryptography-Digest Digest #552, Volume #14 Thu, 7 Jun 01 14:13:00 EDT Contents: Re: Notion of perfect secrecy (Tom St Denis) CBC variant Re: Notion of perfect secrecy (Tim Tyler) Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes (Tom St Denis) Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes (Tom St Denis) Re: OTP WAS BROKEN!!! (Paul Pires) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Mok-Kong Shen) Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes ([EMAIL PROTECTED]) Re: Humor, I Must be a Threat to National Security (Dimitri Maziuk) Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes (Tom St Denis) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Medical data confidentiality on network comms (wtshaw) Re: Medical data confidentiality on network comms (wtshaw) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tim Tyler) Re: Best, Strongest Algorithm (gone from any reasonable topic) (Tom St Denis) From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Notion of perfect secrecy Date: Thu, 07 Jun 2001 17:11:44 GMT Tim Tyler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Tom St Denis [EMAIL PROTECTED] wrote: : Tim Tyler [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... : Tom St Denis [EMAIL PROTECTED] wrote: : : Typically the MEANING of the message is not stored in the length. : Shannon refers to *any* information about the identity of the plaintext. : : For perfect secrecy, observation of the cyphertext should make no : difference to the attacker. : : This is not the case if he was unaware of the length of the plaintext : before observing it - and he knows that the length of the cyphertext : matches that of the plaintext. : You don't understand his results that's all. [...] My understanding is fine thanks. : In his model WHO, WHEN, LENGTH were not the information he wanted to protect. Who and when are not modelled by Shannon. However length /is/ information that relates to the identity of the plaintext (except in the case where all possible plaintexts are the same length) and *is* covered by Shannon's definition of perfect secrecy. No they are not. When will you realize that the contents of the message are what an OTP protects. So if the contents are random than an OTP is perfectly secure. : You're really mocking the dead here. I sincerely hope you are some : 12yr kid trying to get a rise out of people, otherwise I wonder how you : did in College challenging all your profs without listening to their : proofs... No offense Tim but you have a lot of growing up todo. Even : if you are 76 yrs old you're an immature brat as far as I am concerned. Sorry you feel that way Tom. It seems this is the thanks I get for pointing out your errors. Maybe I won't bother in the future. So far it seems #[sci.crypt] vs #[scott, tim]. I don't think it's my errors : Anyways this is all OT. You started this thread about perfect secrecy - which incidentally is not off topic at all. Your rants are not on topic. Tom -- From: [EMAIL PROTECTED] Subject: CBC variant Date: Thu, 7 Jun 2001 13:07:09 -0400 Hi, We know that methods used to inject feedback into a small block cipher, such as CBC, have known-ciphertext attacks against them, like what Vaudenay posted here. I propose a variant of CBC that requires 2 extra block-width XORS and 1 extra encryption per block. (shown here in plain English) (1) Cipher(block n) in CBC is E(block n XOR block n-1), so I propose an extra step like this: (2) XOR block n using a block constant (the constant evolves like the round constant in TEA)* (a) Encrypt the sum. (b) Xor the sum onto block n-1 like a mask. *Note that (2) and (2)(a) are discarded. (The block is not actually double encrypted.) As stated, this needs just two xors and one encryption (same key) in addition to regular CBC. Can anyone find faults in it? If worth anything, use freely ;) Thanks, thecode -- From: Tim Tyler [EMAIL PROTECTED] Subject: Re: Notion of perfect secrecy Reply-To: [EMAIL PROTECTED] Date: Thu, 7 Jun 2001 17:04:04 GMT [EMAIL PROTECTED] wrote: : *IF* I know that the message must be one of k known plaintexts, each : having different lengths, then I can use the length to deduce which : plaintext is being sent. : Note further, however, that this properly belongs to traffic analysis: : I already knew what the message said; [...] Not according yo what you said - you said I know that the message must be one of k known plaintexts. All cryptanalysis involves analysis
Cryptography-Digest Digest #552
Cryptography-Digest Digest #552, Volume #11 Sat, 15 Apr 00 13:13:01 EDT
Contents:
Re: Open Public Key (Tom St Denis)
Re: BlowWire (Tom St Denis)
Re: $100 Code Challenge (Tom St Denis)
Re: Is AES necessary? (Tom St Denis)
Re: CLOSE Encryption (Tom St Denis)
Re: SHA1 algorithm verification
Re: BlowWire ([EMAIL PROTECTED])
Re: ? Backdoor in Microsoft web server ? (Ichinin)
Re: DES (Rob Warnock)
Re: ? Backdoor in Microsoft web server ? (David A Molnar)
EPIC report: Cryptography and Liberty 2000 (Steve K)
Re: ? Backdoor in Microsoft web server ? (Francois Grieu)
MD2? ("Simon Johnson")
Re: Is AES necessary? (Mok-Kong Shen)
Re: CLOSE Encryption ([EMAIL PROTECTED])
Re: Stream Cipher - Mark 2. ("Simon Johnson")
Re: ? Backdoor in Microsoft web server ? (Lincoln Yeoh)
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Open Public Key
Date: Sat, 15 Apr 2000 10:22:54 GMT
[EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Tom St Denis [EMAIL PROTECTED] wrote:
ElGammal or ECC are the certain winners in this case. Although
ElGammal
is slightly easier to implement and understand.
Tom
How secure are ElGammal and ECC??
Where can I find more information about ElGammal or ECC?
ElGammal is slower and takes more space then RSA, but it's a bit tougher
to crack [ie solve]. You can find out about it on my little dork page
at
http://24.42.86.123/numtheory.html
Note: My spelling and grammar are a bit off, so if you actually read
the page and have comments please let me know.
ElGammal is really easy to progrma though, assuming you have a large int
lib.
Tom
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: BlowWire
Date: Sat, 15 Apr 2000 10:23:33 GMT
Spleen Splitter wrote:
"Tom St Denis" [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]...
Spleen Splitter wrote:
Greetings:
I need something to crank on, so I decided to toy with something I fancifully
call
BlowWire, which is simply a 500MHz or so fully pipelined implementation of
Blowfish
in some modern technology, say 0.18um CMOS. Connecting two of these devices on a
cable seems to have enough meat on it to provoke a discussion.
After eating a key in 64 bit hunks of up to 1024 bits, this thing would have a
latency
of ~18 clocks, and then treats the incoming 64-bit parallel stream as a block,
packet,...
to be encrypted/decrypted.
Software implementations are one thing, but they're slow, and I really don't
want to
use a "yet-another-embedded-cpu" on this particular project (top performance
required,
thus the pipeline design, which is more of my interest than say just a wire
protocol).
The C code for Blowfish that I've seen, however, has guided my views on
implementing the
hardware.
I think I can do this in 60Kgates, with my biggest problem being all the
simultaneous
accesses to pi during each clock (what a ROM, what wires!). I'm looking at
things like
how many register files of how many ports, and what sort of ROM in how many
copies.
Each round would presumably be done in a clock, thus leading to the 18 or so
clock
latency to get through the pipe.
Given that I'm only doing Blowfish for fun, I'm fairly certain that further
enlightenment
could be forthcoming on hardware implementations of crypto-functions...
Question: Why did you pick Blowfish? I would have looked up another
cipher that is a tad more hardware friendly. If you have the time and
inclination todo this. If you want to at some point sell your design
you had better make it cheap. Try finding a cipher with less ram
requirements, such as IDEA, Rijndael, etc...
I fully kow-tow to your point of view, but Blowfish is the assignment in this
particular endeavour. In particular, I like Blowfish since it is a difficult
realization in hardware when fully pipelined. It is not my concern to sell
the device, but simply how to build it as rapidly as possible in an advanced
CMOS process. I can afford to be somewhat liberal in an implementation if
it achieves the goal.
Oh so it's just the challenge of design, well good luck!
Tom
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: $100 Code Challenge
Date: Sat, 15 Apr 2000 10:25:03 GMT
Jeff Hamilton wrote:
You know, it's people like you who have no clue how to even begin
Cryptanalysis. You know, why don't you try to do something other than make
stupid comments. I think his challenge is valid. Just as mine was. In fact
I'm suprised you didn't knock my challenge.
Well what routine did you use to encrypt it?
Tom
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: Is AES necessary?
Date: Sat, 15 Apr 2000 10:28:22 GMT
Mok-Kong Shen wrote:
Tom St Denis wro
Cryptography-Digest Digest #552
Cryptography-Digest Digest #552, Volume #10 Fri, 12 Nov 99 14:13:03 EST
Contents:
Re: Ultimate Crypto Protection? ("Trevor Jackson, III")
Re: RC4 in Kremlin US version 2.21 can be cracked !! ([EMAIL PROTECTED])
Group English 1-1 all file compressor (SCOTT19U.ZIP_GUY)
Re: Signals From Intelligent Space Aliens? Forget About It. ("Douglas A. Gwyn")
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! ([EMAIL PROTECTED])
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! (JPeschel)
Re: What sort of noise should encrypted stuff look like? ("Douglas A. Gwyn")
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Douglas A. Gwyn")
Re: Build your own one-on-one compressor ("Douglas A. Gwyn")
Re: Signals From Intelligent Space Aliens? Forget About It. (Patrick Juola)
Re: Signals From Intelligent Space Aliens? Forget About It. (Patrick Juola)
Re: Research suggestion? (Anton Stiglic)
Re: Build your own one-on-one compressor (Tim Tyler)
Re: PALM PILOT PGP found here (John Savard)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (John Savard)
Public Key w/o RSA? ("Brian Greskamp")
Date: Fri, 12 Nov 1999 10:28:32 -0500
From: "Trevor Jackson, III" [EMAIL PROTECTED]
Subject: Re: Ultimate Crypto Protection?
Jeremy Nysen wrote:
"Trevor Jackson, III" wrote:
Sundial Services wrote:
Adam Durana wrote:
I have a friend who tells me that the Russian military used double
enciphered
OTP all through the cold war and that NSA, with all it's expertise and
computer
hardware never had much success breaking it.
Is double encipherment really all that effective?
No one has ever broken an OTP. Double OTP just seems like an overkill. A
single OTP provides perfect security.
Not if one of their spies is at the bottom of the Danube and the enemy
stole a copy of his pad before shooting him. A system involving two OTP
streams would be resistant to either one of them being stolen, and would
further introduce the question of how the streams were combined; the
random nature of OTP streams offering no clues.
Spy organizations think like that.
Hardly. The spy at the bottom of the river had to have both pads. A system
involving two pads has security equal to that of a single pad, but is four times
as hard to use.
Not if it required two spies meeting to be able to send an important
long distance message.
Two pads AND two people? 16 times as hard to use and 2^16 times weaker. No serious
organization would interdict communications in this manner. The field problem is to
create redundant comm channels so control gets some idea of what's going on.
Further, you don;t want to create the kind of correlation between spies meeting and
messages going out. That kind of behavior is a glaring hint.
This might be the case where there are a number of local operatives who
can communicate with eachother covertly. And when any of them has to
send a message across a 'locked down' border, a multi-pad system
improves the chances of the secret remaining undisclosed.
Nope.
An enemy agent
might be able to track down one of the message senders (eg. the bottom
of the Danube), but chances are the other guy has now been tipped off
and is burning his pad.
Absolutely not. Each spy has a pad. Each can send messages encrypted independently.
The dead spy will not be sending any messages. The live spy's pad has not been
compromised.
The only issue is whether the opponent can masquerade as the dead spy, sending
messages encrypted with his pad. Requriring a second encipherment not address that
issue, because if the spies meet for every message they will both be on the bottom of
the river and control will get doubly enciphered messages from the opponent.
A second scenario might be if I store my two pads in unrelated places,
so if one is found hopefully the other remains hidden. I could sign the
message with the first and hide it, then later apply the second pad to
my signed message and hide the second pad elsewhere.
Even more devious: if when signing with my second (hidden separately)
pad, I spend some extra time creating a third pad that when applied to
the message decrypts to some unrelated 'safe' message. I could cave
under torture and divulge this fake pad to the enemy who use it to
verify my message is relatively harmless. For example, if I have
encrypted:
'ENEMY SCUM ATTACK AT MIDNIGHT FIRST JAN 2000X'
and create a third pad that used alone causes the ciphertext decrypt to
'PLEASE SEND ADDITIONAL MONEY FOR HOUSING LOAN'
then I could plausibly deny any evil intent. :- To prove otherwise,
they would need both the first and the second pad.
No, to prove evil int
Cryptography-Digest Digest #552
Cryptography-Digest Digest #552, Volume #9 Sat, 15 May 99 13:13:03 EDT
Contents:
Re: Europe and USA encryption export restrictions (Jerry Park)
Re: Lemming and Lemur ([EMAIL PROTECTED])
Re: Roulettes (Matthias Bruestle)
Re: Europe and USA encryption export restrictions (Serge Paccalin)
Re: Europe and USA encryption export restrictions (Anders Lindbäck)
Re: Lemming and Lemur ([EMAIL PROTECTED])
Musing on and Factoring of a (special) 782-bit Modulus (Ted Kaliszewski)
Re: Intel Pentium III actual random bit generator-- does it exist?
([EMAIL PROTECTED])
Re: Toy Round Function ([EMAIL PROTECTED])
help me crack strong RSA-DNS unicode encryption (Nenad Aliix)
Re: Toy Round Function ([EMAIL PROTECTED])
Re: Need to design basic authentication system ("Tim Mavers")
From: Jerry Park [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: Europe and USA encryption export restrictions
Date: Sat, 15 May 1999 02:21:17 GMT
Nils Zonneveld wrote:
Hi,
I have to admit that I know very little about encryption, but what I do
know is that today browser software for europe is equipped only with 40
bits encryption. Due to USA export restrictions the 128 bits encryption
version is not available. This makes on-line banking[1] impossible and
cripples e-commerce.
There are in fact European made encryption algorithms that offer more
protection then 40 bits and even go further then 128 bits. What I do not
understand is that these algorithms are not used in the European
versions of browser software.
That way on-line banking becomes a possibility and e-commerce within
Europe would be encouraged. This way one would create a incompatibility
between Europe and USA encryption algorithms used in browser software,
but that is the fault of the USA government.
Does anyone have a clue why there is still no decent encryption in
European browser software? Technically it is a piece of cake to use
European based algorithms. There seem to be a lot of political
obstructions, that hinder the protection of european consumers.
[1] on-line banking in this context, transactions over the internet in
stead of a direct dail-in to the bank-computers.
--
M.v.g.
Nils Zonneveld
-
"Misschien is niets geheel waar, en zelfs dat niet"
(Maybe nothing is completely true and even that is to question)
Multatuli (Eduard Douwes Dekker) - Idee 1
Since the major browsers are made in the US, they cannot include strong
encryption outside the US/Canada, regardless of where the encryption algorithms
come from. The US export regulations are so general, that if, for example, I buy
a strong encryption product from say Ireland, I cannot even send it back to the
company I bought if from because I would be exporting the product.
Nevertheless, Netscape browsers can easily be converted to the strong encryption
version anywhere in the world thanks to the work of the people at fortify:
http://www.fortify.net/
--
Jerry Park
Affordable Production Tools
web site: http://www.apt.simplenet.com/
javascript utilities: http://www.apt.simplenet.com/javascript/
* Easiest email encryption system
--
From: [EMAIL PROTECTED]
Subject: Re: Lemming and Lemur
Date: Sat, 15 May 1999 06:08:05 GMT
In article 7hhs1c$l60$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
In article 7hg90g$er4$[EMAIL PROTECTED], [EMAIL PROTECTED]
wrote:
In article 7hfhkg$fmi$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
Dan Bernstein has pointed out in private email that there is an
easy
slide attack [1] on Lemming needing 2^64 known texts.
It looks more like 2^68 to me, since (P,C) can't be part of a
useful slid pair unless P[0]=C[0].
Hmm. I don't see it.
A pair (P,C) (P',C') of known plaintexts is said to be a _slid pair_
if P' = F(P). (F is the 128bit-128bit round function.)
Slid pairs should be found after about 2^{64.5} known texts (birthday
argument).
That's only true for weak F functions.
Where does the relation P[0] = C[0] come in?
The F function in Lemming is only weak when P[0]=C[0]. For
example, pick an arbitrary P and C such that P[0]!=C[0]. Then
the functions F[P] and F[C] will use different elements of the
key array. In this case, there are always keys that satisfy both
F[P]=P' and F[C]=C', so there is no way to tell whether the true
key satisfies both of those. There is no way to recognize the
slid pairs, so the F function is not weak. That's why only slid
pairs with P[0]=C[0] are useful.
I think the attack can be extended to Lemur, under the known-plaintext
attack model. You just look for collisions in the internal 128-bit
state variable. For technical reasons, there might be some increase in
the amount of known texts needed, if you don't refresh the IV very
frequently.
You're right. That'
