Cryptography-Digest Digest #812, Volume #13 Mon, 5 Mar 01 23:13:01 EST
Contents:
Re: How good is the KeeLoq algorithm? ("Simon Johnson")
Re: The Foolish Dozen or so in This News Group (Bob Harris)
Re: The Foolish Dozen or so in This News Group (Bob Harris)
Re: => FBI easily cracks encryption ...? (Frodo)
Re: => FBI easily cracks encryption ...? (Beretta)
Re: Monty Hall problem (slightly off topic) ("Pete Torrione")
Re: The Foolish Dozen or so in This News Group (those who know me have no need of my
name)
Re: Super strong crypto ("Bryan Olson")
Re: Monty Hall problem (was Re: philosophical question?) (Benjamin Goldberg)
Re: passphrase question (HiEv)
Re: The Foolish Dozen or so in This News Group (those who know me have no need of my
name)
Re: passphrase question (Benjamin Goldberg)
Re: passphrase question (Tom McCune)
One-time Pad really unbreakable? (Steven Smolinski)
Re: Super strong crypto ("Douglas A. Gwyn")
Re: One-time Pad really unbreakable? ("Tom St Denis")
Re: One-time Pad really unbreakable? ("Douglas A. Gwyn")
Re: passphrase question (Paul Rubin)
----------------------------------------------------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: How good is the KeeLoq algorithm?
Date: Tue, 6 Mar 2001 01:06:48 -0800
> Why can't they use a standard algorithm such as DES or RC4 ???
> Sounds like the russian car mafia should have a look at that :-))
RC4 is not an official standard as far as I am aware.
Simon
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Subject: Re: The Foolish Dozen or so in This News Group
Date: Mon, 05 Mar 2001 20:15:22 -0500
I wrote:
> yada yada yada
>
> Hope this helps.
> Bob
to which Anthony Stephen Szopa replied:
> You haven't said much here ...
Sorry it didn't help.
------------------------------
From: Bob Harris <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Mon, 05 Mar 2001 20:21:36 -0500
Darren New wrote:
> Actually, I just loaded a "Windows Update" on my machine that added a 2-second
> delay after the OS flushes the disks before it actually removes power from the
> drives during shutdown, to give the hard disk a chance to actually finish the
> write. The behavior is well-documented on MS's update web pages.
>
> Now [why,] if fclose() makes sure all the sectors are written, the OS has to
> wait two seconds for the write to finish after all your programs have exitted.
I'll bet it's to protect the silly programmers who didn't check fclose's
return value before exiting their program. ;)
------------------------------
Date: 6 Mar 2001 01:37:25 -0000
From: [EMAIL PROTECTED] (Frodo)
Subject: Re: => FBI easily cracks encryption ...?
Crossposted-To: alt.security.pgp,talk.politics.crypto
In article <fnTo6.1725$[EMAIL PROTECTED]>
"Mxsmanic" <[EMAIL PROTECTED]> wrote:
>
> "Fogbottom" <[EMAIL PROTECTED]> wrote in
message
> news:[EMAIL PROTECTED]...
>
> > The people writing the glowing reports about the
> > FBI you apparently read certainly have.
>
> My information comes from talking to them myself, and from
talking to
> other people who have dealt with them.
So does mine.
> > For the same reasons the FBI is always getting
> > into trouble for misdeeds.
>
> Always? How often is that?
The same number as your "local cops always getting into trouble".
>
> > Most local police agencies don't have the FBI's
> > propaganda machine to cover up for them.
> What sorts of things are being covered up, specifically?
Sorry, that's a secret.
------------------------------
From: Beretta <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,talk.politics.crypto
Subject: Re: => FBI easily cracks encryption ...?
Date: Tue, 06 Mar 2001 01:45:08 GMT
On Tue, 06 Mar 2001 00:25:52 GMT, [EMAIL PROTECTED] (Free-man) wrote:
<snip>
>
>>So buy a ranch in Montana and declare yourself an independent
>>country.
>
>Great idea. In fact, the right of secession was fundamental in the
>creation of the US, but, the current tyrants do not respect basic
>rights.
>
<snip>
That is such B.S.
There is no right of secession, nor should there be.
We fought a war over that so called right, and the south lost. Deal with it, or
leave
PGP Key: 0x194DF369
Fingerprint: B777 DB2A FB11 55FA 509D CE63 F3DE D665 194D F369
------------------------------
From: "Pete Torrione" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (slightly off topic)
Date: Mon, 5 Mar 2001 20:54:35 -0500
Hello,
Here's an interesting way that I was taught to look at the problem when I
was young (before I had any probability classes). If anyone needs to
explain this to a non-math person this worked wonderfully for me although
the math is a bit "fuzzy".
Lets extend the problem to contain N doors, and assume that Monty always
follows the regular reasoning, i.e. he will open N-2 doors which contain
goats and leave one door which contains either the car (if you initially
picked the goat) or yet another goat (if you initially picked the car).
For N=3, 4, 5, ... it isn't readily obvious to the average person that you
should switch (unless you know about conditional probabilities etc..) but
consider the case where N = 1,000,000,000... .
It's obvious for this large N that there is practically NO WAY that you
chose the initial door. Now, if our pal Monty opens 999,999,...,998 of the
remaining doors it becomes obvious to you which door houses the car. Now
its just a small leap to take N down to more reasonable numbers like 3.
You can even do a small experiment which is easy to verify. Choose holes in
a ceiling, tiles on the floor, anything there's a lot of, and be Monty, and
let the person be the contestant.
well, anyway, I thought it was neat when I heard the explanation, and its
how i explain it to people who haven't had any probability training.
-pt
Joe H. Acker <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > "Joe H. Acker" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> >
> > > Here's a problem I have with this explanation: Why can't I say that
> > when
> > > Monty opens door 3, there's new evidence: the car is not behind door
> > 3.
> > > Thus, the probability that the car is behind door 1 is 1/2, and the
> > > probability that it's behind door 2 is also 1/2.
> >
> > That would be true if you picked a door _after_ Monty revealed one of
> > the doors. It is not true if you have already picked a door.
>
> Thanks for taking so much time for drawing the truth table. (I've
> printed it out for later reference.)
>
> However, I do not believe that the truth table is correct. I do believe
> that the probability to win in this special case does *not* depend on my
> knowledge regarding Monty's choice---wether or not I *know* which goat
> door Monty will open. The probability to win is determined by the fact
> that Monty will *always* open a door that does not contain the car. I
> think that the truth-table may not contain the goat door Monty will
> always open. It does only contain the door I have picked out and the
> door that will *always* remain after Monty has opened the goat door.
>
> Why do I think so? Because the algorithm Monty implements does *never*
> leave me the choice to pick out the door Monty actually opens. But if I
> never have the choice to pick out the door Monty actually opens, the
> initial chances of winning are 50:50.
>
> Interestingly, Monty's algorithm is required to be deterministic in the
> cases where I have initially picked out a goat door. It may be
> deterministic or not, in the case when I initially have picked out the
> car door. If he would implement a completely non-deterministic algorithm
> and choose a door randomly, his chance of picking out the car would be
> 1/3, and my chance of winning would be 1/3 as well.
>
> What do you think of that opinion?
>
> Regards,
>
> Erich
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 02:30:28 -0000
<[EMAIL PROTECTED]> divulged:
>I would think it depends on your file system, too. For example, on a
>CD-R file system, you can only write to each location once, so you
>obviously *cannot* overwrite 27 times.
even that is problematical -- consider udf based access. (which, quickly,
allows you to treat a cd-r as if it were a read-write device. as you might
quickly guess, each block can only be written once, so a re-write has the
effect of associating new blocks with the file.) such a file overwrite
program would succeed, in no case returning an error to the program, if
there were a sufficient number of unassociated blocks when it began.
>Only in straightforward implementations of a file system can you
>*ensure* the same blocks get overwritten.
nope, not even then. see the subthreads regarding block-level replacement
by the hdd itself.
>Douglas A. Gwyn wrote:
>> if the file is opened
>> for writing in the default mode, it gets truncated to 0 length and
>> all its previous data blocks are returned to the block-buffer pool.
>
>Perhaps under UNIX. I thought this was a Windows program we were talking
>about.
windows isn't that much different, with respect to having a cache for that
purpose.
--
okay, have a sig then
------------------------------
From: "nospam"@"nonsuch.org" ("Bryan Olson")
Subject: Re: Super strong crypto
Date: Tue, 06 Mar 2001 02:39:15 GMT
Douglas A. Gwyn wrote:
>Bryan Olson wrote:
>> Given what you've stated, this answer makes no sense. You
>> not have information theoretic security, and don't seem to
>> be taking that approach, or even seeking to demonstrate
>> security.
>
>I've been proposing a *line of thought* via straw-man
>designs in several phases, that is consistent with such
>an approach.
No, as Dave Wagner noted, the first straw-man is provably
not information theoretically secure, and the same is true
of the following straw-men.
> It is not my purpose to fill in the gaps,
>such as to provide you with a detailed theory about how
>system structure interacts with information measures,
>but only to stimulate thought in a different direction.
Indeed I see Dave Wagner as taking a reasonably approach: in
several posts he's looked at what results follow from what
specific assumptions. As I see it, you have so far
disregarded all of his results because you didn't like the
way he filled in the gaps. Personally, I think he's jumping
the gun. If even your criterion for provable security is a
gap, then of course we're not going to get any interesting
results about it.
>If you don't wish to consider that direction, that is
>your choice.
Ah, but I do. One result I stated, and can show, is that
the key changes do not extend the amount of plaintext we can
send with information theoretic security. If you believe
what you wrote above - that the line of thought embodied in
the straw-men is consistent with an information theoretic
approach to provable security - then this result is very
much in the direction at issue.
>As of phase 3, there has been an unproven
>but provable assertion (about uncrackability of a single
>block) and an open research question (about correlating
>multiple blocks).
So the one security result you choose to note pertains to a
single block, and thus the distinguishing characteristic of
the straw-men, that is the key change, is completely
irrelevant. We can of course generalize the result: if the
unicity distance is larger than n blocks, then there's no
unique cryptanalysis using n or fewer blocks. Again, the
in-band change of key is irrelevant to the result.
> John Savard has proposed improvements
>that could be explored. If you're looking for technical
>work to do on this, there is plenty already.
Yes, for example Crypto 82 had three papers on randomized
encryption (the straw-men are randomized stream ciphers with
feedback). The techniques seem powerful in defeating known
and chosen plaintext attacks. There was a paper, I think by
Yao but I'll have to look up the citation, that set up a
paradigm to examine "accessible information" and try to
relate information theoretic and computational security. I
know cryptologists who thought these works promising and
were saddened that in the following years no one was able to
build significant security results upon them.
--Bryan
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers,de.sci.informatik.misc,sci.math
Subject: Re: Monty Hall problem (was Re: philosophical question?)
Date: Tue, 06 Mar 2001 02:42:55 GMT
Shawn Willden wrote:
[snip]
> int carPos = r.nextInt(3);
> int choice = r.nextInt(3);
I'm not going to comment on anything else, but nextInt(3) returns 3
random bits, or a number in the range 0..7. To get an unbiased int in
the range 0..2, you have to write your own ranmod type function.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
From: HiEv <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: passphrase question
Date: Tue, 06 Mar 2001 02:45:47 GMT
Tom McCune wrote:
>
> In article <9dTo6.56224$[EMAIL PROTECTED]>, "Mxsmanic"
><[EMAIL PROTECTED]> wrote:
>
> >In cryptography, you always assume that your opponent knows everything
> >except the specifically secret part of your key.
>
> I can't buy that. There is no way for my opponent to know whether or not I
> repeat characters, or have numbers, or have letters, etc., in my passphrase.
> If I were to assume this, I would assume that he/she knows my passphrase,
> and that I therefore might as well not have one.
What if they had bugged your office as well? The sound of hitting the
same key repeatedly sounds a LOT different than hitting various keys,
and in fact would stand out. A clue like this could be just the edge
they need to crack your security.
------------------------------
From: [EMAIL PROTECTED] (those who know me have no need of my name)
Crossposted-To: alt.hacker
Subject: Re: The Foolish Dozen or so in This News Group
Date: Tue, 06 Mar 2001 02:46:47 -0000
<[EMAIL PROTECTED]> divulged:
>I know that SCSI cards and HDDs all have read caches these days, do
>any of them implement write caching as well?
only specialized controllers or ha's tend to have any cache. those that
contain raid functionality often do, so as to increase the write
performance of the array.
virtually all substantial drives have write caching logic. often they are
shipped with it disabled, requiring the controller/ha or o/s (or whatever)
to enable it.
--
okay, have a sig then
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: passphrase question
Date: Tue, 06 Mar 2001 02:50:32 GMT
Mxsmanic wrote:
>
> "Benjamin Goldberg" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
>
> > So the whole method produces 60 bits of entropy.
>
> Wow.
>
> I'll let others use these methods to pick their passphrases, and I'll
> just stick with random ones myself.
Hey, I was just saying that it's alot of entropy, not that it's a good
method. Memorizing a random string with 6 letters, plus 6 random
integers, is not my cup of tea. Plus, there's no effective difference
in entropy between repeating N times and adding the string value of N,
so typing out long strings of a repeated character is dumb.
Personally, I would go with diceware if I needed a long passphrase, or I
would pick a stanza from a book of poetry.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
------------------------------
Crossposted-To: alt.security.pgp
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: passphrase question
Date: Tue, 06 Mar 2001 02:56:05 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <[EMAIL PROTECTED]>, HiEv
<[EMAIL PROTECTED]> wrote:
>> >In cryptography, you always assume that your opponent knows everything
>> >except the specifically secret part of your key.
>>
>> I can't buy that. There is no way for my opponent to know whether or
not I
>> repeat characters, or have numbers, or have letters, etc., in my
passphrase.
>> If I were to assume this, I would assume that he/she knows my
passphrase,
>> and that I therefore might as well not have one.
>
>What if they had bugged your office as well? The sound of hitting the
>same key repeatedly sounds a LOT different than hitting various keys,
>and in fact would stand out. A clue like this could be just the edge
>they need to crack your security.
I think this makes some sense. But I would think that if they were really
after my passphrase, they would use something better, such as keystroke
recording, or video monitoring. I see these attacks as potentially very
realistic for most home and office situations - that's why most of us are
very foolish if we think we can defend our encryption against adversaries
such as the NSA.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
Comment: My PGP Page & FAQ: http://www.McCune.cc
iQA/AwUBOqRSRQ2jfaGYDC35EQKBhgCdGNwif7MHo88mLmBdLQVoEvwIO7EAniqk
gojKUBgccTSicJpP0W5VJAdR
=TsxK
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Steven Smolinski)
Subject: One-time Pad really unbreakable?
Reply-To: Steven Smolinski <[EMAIL PROTECTED]>
Date: Tue, 06 Mar 2001 03:13:40 GMT
Literature pointers welcome; I'm trying to figure out something. I
apologize in advance for the lack of clue.
Supposedly one-time pads are unbreakable. In Singh's _The Code Book_
(and on some less reputable websites I've been reading), the claim is
made that a second use of a key from a one-time pad can compromise the
security. Here's what I don't understand:
If you can break a one-time pad if you get two ciphertexts made with the
same key, why can't you divide one ciphertext in half and apply the same
analysis?
Steve
--
Steven Smolinski => http://www.steven.cx/
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Tue, 06 Mar 2001 03:21:57 GMT
Bryan Olson wrote:
> ... One result I stated, and can show, is that the key
> changes do not extend the amount of plaintext we can
> send with information theoretic security.
Sure, if you're using an unrealistic theory in which there is no
cost of computation. I've been ignoring those responses since
I'm not interested in impracticalities, just security in real
systems. If you can show that the sucessive phases of my straw-
man design fail to address the real-world threats that I claimed
for them, that would be useful. For example, exhibit *any*
practical C/A attack against the phase 3 design in a normal
scenario (known PT and CT, multiple sessions with same initial
key). If there isn't one, then the design goals have been met.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 06 Mar 2001 03:32:24 GMT
"Steven Smolinski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> If you can break a one-time pad if you get two ciphertexts made with the
> same key, why can't you divide one ciphertext in half and apply the same
> analysis?
Because the same key bits are not reused.
I.e you have N key bits K0...Kn and N message bits M0...Mn You form the
ciphertext Cn via Cn <= Mn xor Kn. If you reuse Kn for C'n <= M'n xor Kn
it's crackable. Otherwise not.
Tom
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: One-time Pad really unbreakable?
Date: Tue, 06 Mar 2001 03:37:17 GMT
Steven Smolinski wrote:
> If you can break a one-time pad if you get two ciphertexts made with
> the same key, why can't you divide one ciphertext in half and apply
> the same analysis?
I think you're confusing "the same key" used twice with "two parts of
the same key, each used once". Because each of the two parts has no
logical or structural relationship to the other, there is no way to
use a relationship to correlate information from the two pieces of
ciphertext. It might help to see how reuse of the same key can be
exploited:
KEY: 01001110110
PT1: 10110110110
PT2: 11000111000
CT1: 11111000000
CT2: 10001001110
XOR of CT1 and CT2: 01110001110
XOR of PT1 and CT2: 01110001110
Note that by combining CT1 and CT2 we obtain information about a
combination of PT1 and PT2. That means that any guess we make about
PT1 can be *checked* by producing the corresponding PT2:
PT2[guess] = PT1[guess] XOR (PT1 XOR PT2)
where the (PT1 XOR PT2) = (CT1 XOR CT2) is known to the analyst.
If PT1 and PT2 are not just random noise but convey meaning, e.g.
are encodings of natural-language text characters, then a bad guess
for PT1 very likely results in gibberish for PT2, which provides a
way to check our guesses for PT1. I.e. we can figure out what PT1
most likely says (along with corresponding PT2).
Try that where instead of KEY you have FIRST_HALF_OF_KEY and
SECOND_HALF_OF_KEY and you should see why it doesn't work; we
cannot rely on a common KEY to relate the two texts.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: passphrase question
Date: 05 Mar 2001 19:49:21 -0800
Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> Hey, I was just saying that it's alot of entropy, not that it's a good
> method. Memorizing a random string with 6 letters, plus 6 random
> integers, is not my cup of tea. Plus, there's no effective difference
> in entropy between repeating N times and adding the string value of N,
> so typing out long strings of a repeated character is dumb.
>
> Personally, I would go with diceware if I needed a long passphrase, or I
> would pick a stanza from a book of poetry.
I've been using diceware for a while and it works pretty well. I
generate a series of diceware phrases til I get one that looks
memorable. Typically this takes half a dozen tries. I take that into
account when choosing the length: if it takes 16 tries, that destroys
4 bits of entropy, so I subtract that from the normal entropy estimate.
I don't especially try to memorize the phrase right away. I instead I
write it on a little slip of paper that I put in my pocket, and refer
to it whenever I need the passphrase, which is normally several times
a day. After a day or so I don't need the paper anymore, so I destroy
it. I guess really correct procedure would have be to the paper, but
I'm not that dedicated.
Here's a dicephrase program I use sometimes (web page with Javascript):
http://www.nightsong.com/crypto/dice.php
Sorry to keep spamming that url but I just think it's a cool hack :).
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
