Cryptography-Digest Digest #778
Cryptography-Digest Digest #778, Volume #13 Fri, 2 Mar 01 10:13:01 EST
Contents:
PKI and Non-repudiation practicalities (Mark Currie)
Re: encryption and information theory (William Hugh Murray)
Re: How good is the KeeLoq algorithm? (Mark Currie)
Re: Safe to use DSS key for DH? (DJohn37050)
Re: confused:Diffie-Hellman is key agreement, how about RSA? Is RSA both algorithm
and keyagreement? (DJohn37050)
Re: = FBI easily cracks encryption ...? ("Mxsmanic")
repeating codes ("Eric Mosley")
Re: RC4 like stream cipher ("Tom St Denis")
Good Security Products?? ("Matthias Bauer")
Re: RC4 like stream cipher ("Henrick Hellström")
Re: super-stong crypto, straw man phase 2 (William Hugh Murray)
Re: How good is the KeeLoq algorithm? (Frank Gerlach)
Re: "RSA vs. One-time-pad" or "the perfect enryption" (William Hugh Murray)
Re: Urgent DES Cipher source code ! ("MVJuhl")
Re: = FBI easily cracks encryption ...? (William Hugh Murray)
Re: Good Security Products?? (Frank Gerlach)
Re: How good is the KeeLoq algorithm? (Søren A.Møller)
Re: repeating codes (Frank Gerlach)
Text of Applied Cryptography ("Ryan M. McConahy")
Re: Good Security Products?? ("Matthias Bauer")
Re: Text of Applied Cryptography ("Erick Perez")
Subject: PKI and Non-repudiation practicalities
From: [EMAIL PROTECTED] (Mark Currie)
Date: 02 Mar 2001 12:23:40 GMT
Hi,
Non-repudiation is often used as a selling point for PKI but this can be
misleading. Non-repudiation requires additional infrastructure such as
databases for storing each signed message together with its corresponding
signature. In high-throughput applications the amount of storage needed can be
very large indeed. There are many applications of public key cryptography (i.e.
communications security) where Non-repudiation is impractical because of the
storage requirement. Non-repudiation would also require independent validation
services that are capable of verifying the message originator given a message,
signature certificate. These services would have to demonstrate a high level
of trustworthiness since the output is likely to be a simple Yes/No. The full
implications of supporting Non-repudiation may not be that clear to PKI
customers and their application developers. The message that often comes across
is that PKI / PK technology gives you Non-repudiation. It does not. It seems to
me that there needs to be more information around the practical implementation
of Non-repudiation.
It is possible that these issues are now being addressed by PKI vendors. Does
anyone know of any literature that covers the practical issues around
Non-repudiation ?
Mark
--
From: William Hugh Murray [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: encryption and information theory
Date: Fri, 02 Mar 2001 12:37:06 GMT
Mxsmanic wrote:
"Benjamin Goldberg" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Consider symettric encryption. Is there information
added to the message during encryption which the attacker
does not know?
No.
YES, the secret key is added, and the attacker does not
know the secret key.
The secret key is not added to the message. Nothing is added to the
message. Parts of the message are transposed, and parts are
substituted, but the overall information content remains the same.
I agree. What has been added is a new code and code book but that
information is in the alogorithm and the key, not in the cryptogram.
Now in order to understand the message one must have at least two code
books, the public one(s) in which the original message was encoded and
the secret one.
--
Subject: Re: How good is the KeeLoq algorithm?
From: [EMAIL PROTECTED] (Mark Currie)
Date: 02 Mar 2001 12:45:49 GMT
Many remote controlled security gates and vehicle alarms today still make use
of an un-changing transmitted code. The danger here is that a determined thief
gets hold of a device that can record the transmission and later re-transmit
the code to gain access. Keeloq was designed to provide significant improvement
over this. You now need to involve a highly skilled cryptographer who may/may
not be able to crack the cipher.
In article 1103_983533150@3s-sam-pc, [EMAIL PROTECTED] says in part...
Isn't it easier to move the car to someplace else and remove the car alarm
etc.?
I think that this is exactly how you should view the thing.
Mark
--
From: [EMAIL PROTECTED] (DJohn37050)
Date: 02 Mar 2001 12:58:59 GMT
Subject: Re: Safe to use DSS key for DH?
Actually, using a too large subgroup introduces ineffiencies. It is best to be
approx. balanced ;=)
Don Johnson
--
From: [EMAIL
Cryptography-Digest Digest #778
Cryptography-Digest Digest #778, Volume #12 Tue, 26 Sep 00 13:13:01 EDT
Contents:
Re: On block encrpytion processing with intermediate permutations (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: continuous functions and differential cryptanalysis (Tom St Denis)
Re: Encryption Project (pink aka Chr. Boesgaard)
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Test for weak keys in 3DES (Paul Schlyter)
Re: continuous functions and differential cryptanalysis (Tim Tyler)
Re: Question on biases in random numbers decompression (Tim Tyler)
Re: Question on biases in random-numbers decompression (Tim Tyler)
Re: Question on biases in random-numbers decompression ("D.A.Kopf")
Re: A New (?) Use for Chi (John Savard)
DES ([EMAIL PROTECTED])
Re: Test for weak keys in 3DES ("kihdip")
Re: continuous functions and differential cryptanalysis (Mika R S Kojo)
Re: Why is TwoFish better than Blowfish? (Eric Lee Green)
Re: DES ("Martin Wolters")
Re: continuous functions and differential cryptanalysis ("Scott Fluhrer")
Re: Again a topic of disappearing e-mail? ("David C. Barber")
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Tue, 26 Sep 2000 10:56:05 GMT
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Bryan Olson wrote:
Tom is right; the diffusion is obviously terrible.
Here's a first-cut at an attack strategy:
In a typical Fiestel cipher one might have 16 rounds
or 8 round-pairs. Let's use chosen messages of about a
thousand blocks. We introduce differential pairs in
which only one block input differs. There probably
exists a left half-block for which any input
differential survives to become an output differential.
That happens if at each of the seven between-round
permutations the differential goes into a left block
and the right blocks are still constant.
We can easilly detect the case when it happens; the
differential put into the left half of input block
'i', appears as the differential comming out of the
left half of ouput block 'j'. Now we can put
differntial pairs into the right half of i, holding
everything else constant, and the differential that
comes out in the left half of j is exactly the
differential from the right half of i going through
the f function in the first round. For most Feistel
ciphers that will expose the first round-key, and
allow us to push to the next round.
There are other opportunities to extract information
based on the poor diffusion. As a rule of thumb,
letting information out from intermediate rounds is
extremely dangerous.
Suppose each half is a word (e.g. DES), the permutation
is rendering each one of them to go to a different
location that is unknown to the opponent. I don't yet
see how he can 'follow' the individual halves as they
get processed in the different cycles in order to be
able to exploit differentials etc. He has a moving
target, so to say, and the motion is invisible.
That's just it. If the blocks diffuse poorly things like differential
cryptanalysis will work. I can send a huge msg in with specific
differences. Then I watch to see which output halves have the required
difference. Then I can guess which are involved...While this is not a
concrete attack if you only use say 2-round DES in each step the
differences will propagate for sure.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis [EMAIL PROTECTED]
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Tue, 26 Sep 2000 10:59:47 GMT
In article [EMAIL PROTECTED],
Mok-Kong Shen [EMAIL PROTECTED] wrote:
Tom St Denis wrote:
Ah, but something can be pratically random. Take the output of say
RC4
that is hashed (gather 30 bytes then hash it via SHA-1, etc...) I
would
bet 10 bucks that without knowing the RC4 seed you couldn't guess
the
output better then 1/2.
Make the RC4 seed 256 bits long ... and voila.
Of course how do you make a random RC4 seed? recursive problem...
I am really confused. Aren't we discussing the 'ideal'
OTP that requires (theoretical) perfect randomness
all the time? Why here 'practical' randomness at all??
That's just it. If you can't practically guess the output, isn't it
effectively random?
Random is not a point in uncertainty, it's a state of it. If something
is random to you, that means you can study it to guess the next output
with any success better then the standard distribution. (1/p ...).
Universal randomness as people want to see it CANNOT EXIST. It's
impossible for something to be totally random. But it's possible for
me to take some americium and make a rng that you
Cryptography-Digest Digest #778
Cryptography-Digest Digest #778, Volume #11 Mon, 15 May 00 15:13:01 EDT Contents: Re: Notes on the "Vortex" block cipher (Terry Ritter) Re: Notes on the "Vortex" block cipher (Terry Ritter) Re: (May 11, 2000) Cipher Contest Update (Mike Rosing) Re: Definition of "Broken" Cipher (Mok-Kong Shen) Cryptography FAQ (01/10: Overview) ([EMAIL PROTECTED]) Cryptography FAQ (02/10: Net Etiquette) ([EMAIL PROTECTED]) From: [EMAIL PROTECTED] (Terry Ritter) Subject: Re: Notes on the "Vortex" block cipher Date: Mon, 15 May 2000 17:18:20 GMT On Mon, 15 May 2000 13:39:08 +0200, in [EMAIL PROTECTED], in sci.crypt Runu Knips [EMAIL PROTECTED] wrote: Tom St Denis wrote: There is some science behind cryptography whether you want to believe it or not. And I think his dislike of Blowfish is only instinctive. I would trust Blowfish, too. It only requires a little bit too much resources for some applications. That particular answer of mine would have been the same for any other cipher. The problem is not a particular cipher, the problem is in trusting something which cannot be tested to see how closely it comes to doing what we want it to do. --- Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM -- From: [EMAIL PROTECTED] (Terry Ritter) Subject: Re: Notes on the "Vortex" block cipher Date: Mon, 15 May 2000 17:18:31 GMT On Mon, 15 May 2000 09:49:22 GMT, in 8foh6v$mib$[EMAIL PROTECTED], in sci.crypt Tom St Denis [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Terry Ritter) wrote: Nonsense. That is *not* the same at all: In all normal fields of engineering design (and I am a professional engineer), engineers can test their work. Most designs will have specifications, and the resulting equipment can be tested to see if it meets those specifications. In most areas of life, we can detect design bugs simply because the machine (including software) does not do what we want it to: it does not meet specs. Hindenburg. Nuff said. Nonsense. When the Hindenberg went down *everybody* *knew* that a disaster had happened. CRYPTOGRAPHY IS NOT LIKE THAT! The disaster that happens in cryptography is secret, and so we will keep riding that dirg. Consequently, we will have the same disaster (without really experiencing it), over and over again. The dirg never gets built right because we don't know where it went wrong. And people use it anyway, because they "trust" it. You are trying to tell me everything engineers do is flawless? Shaw- right. Nonsense. Never said that, never tried to tell you that. When we design and use normal things, we can tolerate errors because we see the ultimate results. If the results are not what we want, we can do something about it. In cryptography nobody gets to see the ultimate results: We cannot know if our information is hidden from secret opponents. We don't know if problems exist, so we cannot fix them. And the "we" part of this includes everybody: both amateurs and experts. There is some science behind cryptography whether you want to believe it or not. Nonsense. I have never said that there is no science behind cryptography. Many things used in cryptography can be measured, and I have personally measured and reported on some of them. Many things in cryptography can be designed to specification, and I have reported on some of those as well. Instead it is the unsupported belief in cipher strength which is unscientific. Science does not require belief. Indeed, that is the whole point. It is non-science which requires belief, and that is what we have when we trust some cipher: a belief without supporting evidence. --- Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/ Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM -- From: Mike Rosing [EMAIL PROTECTED] Subject: Re: (May 11, 2000) Cipher Contest Update Date: Mon, 15 May 2000 12:22:31 -0500 Runu Knips wrote: Adam Durana wrote: But I think when someone publishes a cipher for analysis, they are saying that the only attack they can come up with is brute force. Any attack better than that would be a break through. So if an attack arises that can recover the key or plaintext faster than brute force, I think that attack should get the cipher removed from the listing. Keep in mind this is a contest of cipher design. I disagree with that definition. RC6, for example, accepts keys of any size. It is quite unfair to state that it is therefore broken by definition. I think "much faster" than brute force would be a better term for "break". For example, if the key size is n bit, then we might say "much faster" is 2^(n/2).
Cryptography-Digest Digest #778
Cryptography-Digest Digest #778, Volume #10 Tue, 21 Dec 99 14:13:01 EST
Contents:
Re: Q: transcendental pad crypto (Lincoln Yeoh)
Re: firmware encryption? (Volker Hetzer)
Re: Code Puzzle (John Savard)
Re: RST discovers defective crypto in Netscape mail password saver ("Roger Schlafly")
Re: firmware encryption? (Guy Macon)
Re: Keystrokes monitored/encryption useless (Medical Electronics Lab)
Good way to one-way encrypt? (Christoffer =?iso-8859-1?Q?Lern=F6?=)
Re: compression encryption (Kenneth Almquist)
Re: How do you know if you found a key? (Paul Koning)
Re: Good way to one-way encrypt? (NFN NMI L.)
Re: QPK (Medical Electronics Lab)
Implementing ElGamal ("Rowland Smith")
Re: Come visit Forest Hills, NY...home of Dimitry Vulis. (Günter Bergmän)
Re: Good way to one-way encrypt? (Scott Nelson)
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: Q: transcendental pad crypto
Date: Tue, 21 Dec 1999 16:21:29 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 20 Dec 1999 18:31:19 -0500, "dls2" [EMAIL PROTECTED] wrote:
Physics! Physics is arguably predictable, i.e. non-random. So
how is its use really so different from the use of transcendental
numbers?
Given that you know I'm rolling a 6 sided die, can you tell me which side
is going to come up, even after I give you the results of the past 1000
throws?
Compare that to knowing that I'm using a transcendental number and being
given the past 1000 numbers.
Cheerio,
Link.
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
***
--
From: Volker Hetzer [EMAIL PROTECTED]
Subject: Re: firmware encryption?
Date: Tue, 21 Dec 1999 16:29:32 +
[EMAIL PROTECTED] wrote:
Depending on the level of security you need you could try XORing it with
the code you are replacing.
I recommend against this. The level of security should be high enough
to force the attacker to disassemble the device. XOR'ing one piece
of data with another is much too easy to read.
Greetings!
Volker
--
Hi! I'm a signature virus! Copy me into your signature file to help me spread!
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Code Puzzle
Date: Tue, 21 Dec 1999 09:31:26 GMT
[EMAIL PROTECTED] (Rich Lafferty) wrote, in part:
When all else fails, google!
Yes: I've been trying to get my site to be fully indexed by AltaVista
again for some time, but have been unsuccessful so far, although I'm
still waiting for my table of contents to get spidered there.
But
http://www.google.com/
http://infoseek.go.com/
http://www.excite.com/
at least have my current site fully indexed, even if I've been
unsuccessful with the better-known search engines (HotBot and Lycos as
well as AltaVista).
John Savard (jsavardatecndotabdotca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Roger Schlafly" [EMAIL PROTECTED]
Subject: Re: RST discovers defective crypto in Netscape mail password saver
Date: Tue, 21 Dec 1999 08:40:08 -0800
Ken Lamquist [EMAIL PROTECTED] wrote in message
news:83mvtk$61g$[EMAIL PROTECTED]...
According to the RST web page, RST does consulting for firms which
want to improve the security of their software. I have no way of
knowing the quality of this consulting work. If their advice to
companies relying on security through obscurity is simply to make the
software more obscure--even if the software contains other holes so
that penetrating the existing obscurity is not the most efficient
course of action for an attacker--then the risks are obvious.
Yes, the RST folks seem to have some misunderstandings
about what cryptography is for. Besides your point, Netscape
makes its source code available. I don't know whether the source
code to the email piece is available, but if it is, then a fancier
encryption algorithm wouldn't even add any obscurity.
--
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: firmware encryption?
Date: 21 Dec 1999 12:48:52 EST
In article 83nbee$9e0$[EMAIL PROTECTED], [EMAIL PROTECTED] ([EMAIL PROTECTED])
wrote:
Hello All,
I am designing a microcontroller-based system (an 8051) that will be
deployed to a large number of customers. The controller contains on-
chip flash memory, so I wanted to take advantage of it by releasing
controller code (i.e. firmware) updates periodically as needed. The
user would simply download the firmware into the box. The controller
would then read the data and reprogram itself with the new code. BUT
the code needs some security via encryption, so that one cannot simply
disassemble it.
So the system looks like it needs an encryption algorithm with the
following traits:
1. Can run ok on a 8-bit processor
2. Uses little RAM (256 bytes)
3. Most importantly, can use a single ke
Cryptography-Digest Digest #778
Cryptography-Digest Digest #778, Volume #9 Fri, 25 Jun 99 23:13:03 EDT
Contents:
Re: one time pad (John Savard)
Re: Hasty Pudding Cipher -- update (William Tanksley)
Re: How does 3DES work? (John Savard)
Re: TeraPi (William Tanksley)
BAN Logic considered useful? (Jim Flanagan)
Re: one time pad (William Tanksley)
Re: IDEA-128 (John Savard)
Re: DES-NULL attack (John Savard)
Re: DES-NULL attack ([EMAIL PROTECTED])
Re: DES-NULL attack (JPeschel)
New idea for block cipher (please comment) ([EMAIL PROTECTED])
Re: sha-1 C/C++ source code ("Richard Parker")
Re: Converting arbitrary bit sequences into plain English texts
([EMAIL PROTECTED])
Re: one time pad (S.T.L.)
Re: TeraPi (Greg Ofiesh)
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: one time pad
Date: Fri, 25 Jun 1999 22:56:22 GMT
AllanW [EMAIL PROTECTED] wrote, in part:
Note that the CPU's clock drift is not connected to the
counter's clock drift in any way.
As another poster has noted, free-running oscillators tend to lock up
to any RFI in the vicinity, such as another oscillator might produce.
Also, the major source of frequency drift in an oscillator is
temperature, and so two oscillators in the same apparatus are likely
to be subjected to common influences in that area as well. (Both would
have been turned on at the same time, besides being in the same
room...)
But there are plenty of other relatively inexpensive ways to make
passable physical RNGs, such as thermal noise from a resistor. Really
good ones, though, are harder to make.
John Savard ( teneerf- )
http://members.xoom.com/quadibloc/crypto.htm
--
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: Hasty Pudding Cipher -- update
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Jun 1999 22:57:59 GMT
On 23 Jun 1999 19:53:43 GMT, [EMAIL PROTECTED] wrote:
What the %@$^ is 1/3 of a bit?
Would you actually like to know, or are you merely enthusiastic?
Regards, Noah Paul [EMAIL PROTECTED]
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How does 3DES work?
Date: Fri, 25 Jun 1999 23:05:11 GMT
[EMAIL PROTECTED] wrote, in part:
Does 3DES work because not all outputs are possible? Because the key
is smaller then the input it's not a perfect permutation (it's
complete ... but ?).
For example 2^64 possible inputs but only 2^56 possible outputs for
that one input.
If this argument is true then ciphers with larger keys will most likely
not work because there would be a shortcut (i.e mitm).
Actually, you're describing single-DES. It has a 56-bit key, and so
there are only 2^56 possible encipherments of a 64-bit input block.
Triple-DES uses a key of two or three times that length, and
meet-in-the-middle IS a shortcut that can be used in attacking it.
Which is why it is sometimes used with a 112-bit key, as that is its
maximum effective security.
However, if one is enciphering 64-bit blocks, there are (2^64)!
possible ways to describe what each block becomes. That enormous key
space is the limit, not 2^64, to the key for a block cipher with a
64-bit block, since it is useful that even if an opponent knows that
block A is enciphered to B, he still doesn't know what block C
becomes.
Actually, though, although meet-in-the-middle only applies to *some*
large-key block ciphers, there is another shortcut attack that
requires only 2^64 operations to break any block cipher with a 64-bit
block. Terry Ritter outlined it: the "codebook attack". If one has
2^64 different known plaintexts, one has a table for the entire
operation of the block cipher, however long its key.
So you're right - there is a shortcut when the key is bigger than the
block - even if it isn't related to meet-in-the-middle. Opinion is
divided, though, on whether that shortcut is worth worrying about.
John Savard ( teneerf- )
http://members.xoom.com/quadibloc/crypto.htm
--
From: [EMAIL PROTECTED] (William Tanksley)
Subject: Re: TeraPi
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Jun 1999 23:05:04 GMT
On Thu, 24 Jun 1999 20:36:39 GMT, Greg Ofiesh wrote:
I had such good feedback on one time pad that I think I will venture to
propose a new encryption strategy for your amusement and critique. I
call it TeraPi.
[algorithm snipped]
What say all of you?
It has some interesting characteristics -- it's got a gaping possibilty of
a hole because it's using such a predictable sequence over and over again.
But that might not be a problem.
The real problem is that nobody qualified is going to review it, so we'll
always suspect (correctly or not) that it's got holes in it. If you want
to design an encryption alg, you have to first crack lots of algorithms
invented
