Cryptography-Digest Digest #238, Volume #13 Wed, 29 Nov 00 02:13:01 EST
Contents:
Re: SRP - not good enough? (John Savard)
Re: Question regarding OS's. (Benjamin Goldberg)
Re: A Simple Voting Procedure (Benjamin Goldberg)
Playstation 2 Units $599 ("adsl5")
Re: collision probability with file checksums (Ed L Cashin)
Re: Entropy paradox (Benjamin Goldberg)
Re: Cyrptography Digest Archive ? (Benjamin Goldberg)
Re: RSA funny stuff (Benjamin Goldberg)
Re: P/w based authentication and key exchange (David Hopwood)
Re: collision probability with file checksums (David Hopwood)
Re: collision probability with file checksums (David Hopwood)
Re: Q: Role of linguistics (Benjamin Goldberg)
Re: PDF/PS to MS WORD converter (Benjamin Goldberg)
Re: Rijndael applications ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SRP - not good enough?
Date: Wed, 29 Nov 2000 03:51:14 GMT
On Wed, 29 Nov 2000 03:23:31 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:
>(I was trying to take a look at PAK, to see if it is better, but I
>can't seem to get through right now.)
Finding information on PAK, I see that PAK-X protects the server's
password file from dictionary attack, but a dictionary attack is still
possible if the user's computer files are obtained.
And Augmented EKE doesn't protect against dictionary attack.
I'm not sure it is even possible to protect against dictionary attack
at both ends; but I'm not certain it's impossible, either. Perhaps
something with a physically secure master server, like the TGT in
Kerberos, has to be settled for.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Question regarding OS's.
Date: Wed, 29 Nov 2000 04:51:08 GMT
William Rowden wrote:
>
> Juri wrote:
> [snip]
> > > I am just curious, why OS do you, cryptographers, use?
> > > Windows, Linux, Unix or something else?
> > > If Unix, what distributor of Unix? Thanks very much.
>
> I'll add the word "amateur" to the first question and answer it. For
> cryptanalysis, especially of classical ciphers, the file manipulation
> and regular expression search tools of Unix/Linux are excellent. For
> cryptography, the programming environment is similarly advantageous.
> (As Douglas Gwyn notes elsewhere in this thread, these tools may be
> added to Windoze; they are already there, waiting to be discovered, in
> *nix.) For general security, one may feel safer with an open source
> OS like Linux. The Linux community tends to patch security holes
> faster, too.
Actually, if you were to leave out the word "faster" in that last
sentence, you would be more accurate in the sentence's implications
about what Windoze does and doesn't do.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Wed, 29 Nov 2000 05:01:08 GMT
David Schwartz wrote:
>
> Benjamin Goldberg wrote:
>
> > I don't think that will necessarily work:
> > Consider using a voting machine like the one I mentioned in another
> > thread. The vote (the position of the levers) doesn't count until
> > you pull the Commit level, which also resets to their original
> > position -- at any time up until the commit lever is moved, the
> > individual levers can be moved into any valid configuration you
> > want, with no effect on the vote. If you photo yourself, in the
> > both, with the levers in some particular configuration, there is
> > NOTHING preventing you from moving them to an entirely different
> > arrangement after the photo and before your pulling of the commit
> > lever. Photoing the setup after the commit lever's been pulled is
> > un-useful, because pulling it resets all the vote levers to their
> > starting positions.
>
> So you bring a video camera in with you. You are overanalyzing
> the example and missing the point.
>
> DS
Does the average voter have a video camera? Also, normal cameras
nowadays are small, video cameras aint. If you've got enough officials
bribed that they'll overlook people sneaking in video cameras, why not
assume that Mr. Nasty will be able to just install his own video camera
in the booth? Or stick in little electronic sensors under each lever?
We have to assume that there are at least a *few* honest people present
in the voting area, otherwise ANY system will break.
As a further note against worrying about cameras (of any kind), consider
that elections generally happen in public, indoor areas, like Town
Halls, or school auditoriums. Some schools have metal detectors -- why
not use them to stop people from bringing in cameras?
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: "adsl5" <[EMAIL PROTECTED]>
Subject: Playstation 2 Units $599
Date: Wed, 29 Nov 2000 05:14:49 GMT
--
WWW.ADSL5.COM
------------------------------
From: Ed L Cashin <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: 29 Nov 2000 00:40:14 -0500
Bryan Olson <[EMAIL PROTECTED]> writes:
> No, the subject was collision search when the specific work
> factors came up. The Van Oorschot and Wiener estimate is for
> finding one collision, not a second pre-image.
OK, so "collision search" doesn't mean looking for a collision with a
given file's MDC. I didn't know that. But the subject line is less
ambiguous.
> > In that case, the attacker must try to match a hash output
> > that is already there, which is harder, requiring 2^n tests. So David
> > would be right.
>
> Wagner and Schwartz are both "David". I side with Wagner.
This time I was feeding the ambiguity, sorry. :) Of course you side
with Wagner if you're both talking about birthday attacks, which don't
apply to "collision probability with file checksums". (... except in
the situation you propose below)
> Incidentally, a good manipulation detection code must be collision
> resistant. Otherwise an attacker might be able to construct an
> innocuous file and a malicious file with the same digest, legally
> introduce the innocuous file, and then substitute the malicious file
> without detection of the substitution.
Happily, the idea of a legal introduction is not realistic in file
integrity verification systems. If the file is being monitored for
manipulation, say it's /bin/ls, then introducing your own /bin/ls is
never a legal file introduction. There should be no opportunity for
such undetected file placement.
--
--Ed Cashin PGP public key:
[EMAIL PROTECTED] http://www.coe.uga.edu/~ecashin/pgp/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Entropy paradox
Date: Wed, 29 Nov 2000 05:43:21 GMT
Scott Craver wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >As also questioned elsewhere, does that mean that I couldn't
> >use more than m bits out of BBS, if I desire perfect
> >security?
>
> Yes. "Perfect secrecy" is a technical term,
> defined as a situation in which the probability
> distribution of plaintext messages does not change
> conditionally on the ciphertext.
>
> Simply put, using the PRNG will allow an attacker
> with unbelievably incredible computational
> resources to crack the cipher by trying all keys.
> This may be unrealistic given the age of the
> universe and all, but that is based on our present
> conception of computation.
>
> With perfect secrecy, even infinite computational
> resources will not determine the plaintext from
> the ciphertext.
In other words, what's needed is a TOTP. Using any conventional method
whatsoever, it is impossible to securely transport your pads over an
eavesdroppable communication line without losing the property of perfect
security. Physically transporting the pad (preferably on a CD in a
locked steel briefcase or lightweight safe) is the only conventional way
of obtaining perfect security.
Note that quantum cryptography is a way of doing TOTP *and* maintaining
something approaching perfect security.
> >And what security would I have if I use
> >u = 1000 * m bits? Thanks.
>
> Probably very good security.
>
> By the way, you are not guaranteed perfect
> secrecy even if you only use m bits or less from
> the BBS generator. Any deterministic algorithm
> performed on your random seed can only hurt,
> and you're better off just using the m bits,
> obtained from a true random process. As far as
> you know, the BBS generator could skew the
> distribution of bit strings a tad.
>
> >M. K. Shen
> -S
Each output bit eliminates (on average) 50% of the 2^m possible seeds.
Start with seeds := { all 2^m possible strings }
To find the entropy in the first bit, find C_0 = number of seeds which
output 0 as the first bit, and C_1 = number of seeds which output 1 as
the first bit. Plug these into the formula for H, and that's the
entropy for the first bit. (The actual *value* of the first bit is not
looked at anywhere in this calculation).
To find the amount of entropy in the second bit, look at what the first
bit actually outputted was, and eliminate the seeds which couldn't have
output it. Then calculate C_0 and C_1, then find H.
The first few bits will have close to 1 bit of entropy each, but this
will continuously decrease until the set 'seeds' contains only one
element, at which time all remaining bits of the stream contain 0 bits
of entropy. Note that, when the seeds set is small (but greater than
one), some of the bits *may* have 0 bits of entropy, even though there's
more entropy available in the stream.
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Cyrptography Digest Archive ?
Date: Wed, 29 Nov 2000 06:05:18 GMT
Will Anthony wrote:
>
> Why not write a program that takes the input of a short wave radio
> turned to a dead frequency and hash the stellar noise out into a
> random string of junk? I have read theories on this, but I have never
> seen it put to use. I imagine that it (stellar noise) would be a
> great foundation for random generators.
Although this is in fact a good idea, you have to beware of a few
things:
1) Most radios try to pick up signal, and filter out noise. You will
need to design a reciever to do the opposite. This is difficult.
2) If someone discovers the frequency you're on, they can transmit a
powerful signal at your machine, drowning out any noise, and allowing
the attacker to control your RNG.
3) [this point's not really important] it's called atmospheric noise,
not stellar noise. (Yes, I realize that that sorta sounds like it's
refering to actual acoustic sound, not radio fuzz, but that's the proper
term).
There are, I'm sure, other things which I don't know about which can
cause complications in using radio static as an RNG source, but that
doesn't mean it's not a good idea. If you want to build one, go for it!
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: RSA funny stuff
Date: Wed, 29 Nov 2000 06:13:53 GMT
Tom St Denis wrote:
>
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> > Tom St Denis wrote:
> >
> > > hehehehe... as if people honestly believe a little logo means it's
> > > secure... hahahaha
> >
> > I think the presense or absence of familiar and "trusted" logos and
> > icons is all most people have to go on when evaluating security.
> > For the average user, the establishment of a truly trustworthy logo
> > (meaning one whose useis carefully controlled, and which is applied
> > only to products that have passed rigorous security analyses) would
> > be a very good thing.
>
> You summed up what I was making fun of. "For the average user, the
> est..." which means "perdy logo means it werks good, ya'huh".
>
> So sad really.
>
> Much like we trust UL logos......
Hey! UL logos, which go on real, physical, *things* (as opposed to
intangible bits and bytes), have a reasonable basis of trust.
If I dl something from the net, and it has some logo on it, I have not
--ing way of telling that that logo is legit.
If I buy something in a store, and it has a UL logo, and the widget zaps
me, there a way of telling where the thing came from (my reciept, the
store owner's invoce, the warehouse's invoice, the factory), and a way
to sue someone (somehow), possibly involving complaints to the Consumer
Protection Agency (or whoever).
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
Date: Wed, 29 Nov 2000 06:26:34 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: P/w based authentication and key exchange
=====BEGIN PGP SIGNED MESSAGE=====
Ivars Suba wrote:
> I recommend to attend complete strong password authentication
> reference page http://www.integritysciences.com/links.html#BR00
>
> My choice would be elegant and brilliant Leighton-Micali "Secret-key
> agreement without public-key cryptography" (T.Leighton and S.Micali,
> Advances in Cryptology: Proceedings of Crypto'93,1994)
> applied for pswd authentication and key exchange purposes and has
> several advantages over Kerberos and Needham - Schroeder protocols.
Leighton-Micali requires a central trusted party or parties, which
introduces many unnecessary avenues of attack against the system, and it
is not suitable for password authentication (users' keys are generated by
the central party, and they cannot be derived from a password). If this
protocol was ever useful, it has been superceded by more recent designs,
both in the password-based and non-password-based cases.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOiShfDkCAxeYt5gVAQEfeQf/WId2v32ajlJTlSJ/DuWoUG9kYiUQGz5S
HGhSO5qgUeNRFDU4t6G2p+9Om6UtJUcMSv6nFWoK3zSnufRIHa8IIm0CA/6ZgUIC
YmiesEd40AesbcwW71AOyySRtqGq8nDbgklSSgr0XVM9J3ndDuIldJbH/rOZdfbD
wBMsIr3ycHhmJuqKG9ABeKIHXz1aAwkew3jDgrGQLjd8tQVKxu+AAI/Y2dlVQ2NZ
l2XOrCwJEvPvoYDfR3zNn4RvtxfDRrE285Q3k062lCThRadiC20X02v6IvcRPRIQ
2If7NMU6aIpDBw4+neASWbtKN7LsQwRq2L7rwUF7uKY9Fx0CqulEWA==
=eiZl
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 29 Nov 2000 06:28:23 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: collision probability with file checksums
=====BEGIN PGP SIGNED MESSAGE=====
Ed L Cashin wrote:
> David Schwartz <[EMAIL PROTECTED]> writes:
> > Ask a few cryptography experts to predict in what year they
> > think the first SHA1 collision will be found. I predict the first
> > SHA1 collision might be found by massive distributed search
> > techniques around 2080.
It would be a very brave expert who would predict that no weaknesses
will be found in SHA-1 up to 2080.
> The reference you cite above notes that Van Oorschot and Wiener
> thought that in 1994 a ten-million-dollar, specially designed, machine
> could produce an MD5 collision in 24 days. I guess they were off in
> their guess or we'd have seen some collisions by now.
That estimate doesn't sound too far off to me. However, the public
cryptographic community doesn't have $10m (or whatever that would have
come down to now) to spend to prove a point.
(It *does* have $250,000 to spend to prove a point, c.f. Deep Crack -
especially if making the point has political value. As well as being
too expensive, finding a collision in a 128-bit hash doesn't have any
political value, because governments aren't putting pressure on anyone
to use short cryptographic hashes.)
Note that, assuming no weaknesses in SHA-1, finding a 2nd pre-image
(which is what is required to find a file that matches an expected hash,
as the original poster asked), requires 2^159 expected work, not ~2^80.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOiSh3jkCAxeYt5gVAQETtwf+Ld3l/tSzwTt6eJU/hUWUBypDQsOfDrWa
1vQBwpwGtOnWz7de44p3sasihsk+zVyEq5gTslRqR9oy6NzG/HTZkuisW2agimcV
DW8qQx3clgxG3kGqVhRSsIptzUSNe2FzMo6IGHxj/z7r/364VKyaR8wDu2I0Aj9G
ARzWipy3AzmBpF/mE8LuGM2ocPefKCRub992CFDt3ziorxmgF4FIfYMRwXGhC/LV
5KRMiKrN09uCMs9xJZv2bE0aJUni1Isd6hXUuHmHlis3ke5A494GWWnhlrBJxgAm
LuCxKLdoJSBlbQ57jjwSWuEDGorZ5ZRc909mMJSF/JOmvXQavS1fvw==
=VicQ
=====END PGP SIGNATURE=====
------------------------------
Date: Wed, 29 Nov 2000 06:31:49 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: collision probability with file checksums
=====BEGIN PGP SIGNED MESSAGE=====
Ed L Cashin wrote:
> Hello. A file integrity verification product like tripwire uses
> different algorithms to compute checksums for files. By comparing the
> checksums of a file with known state to the current file's checksums,
> it's possible to find out whether the file contents have been
> modified.
>
> If the system uses just one 160-bit algorithm, say SHA-1, for doing
> the checksums, then what are the chances that an intruder could make a
> malicious file that has the same checksum as the file's known-state
> checksum?
Negligable; an attacker wouldn't even consider trying to do that.
He/she might consider modifying the operating system kernel so that
tripwire reads the file contents it expects, though (or other methods
of achieving the same effect).
Unless you do a hardware reboot from read-only media containing a
trusted copy of the operating system each time you want to verify the
checksums, and have some way of making sure you are checking against
the right checksums, it is impossible to completely prevent such attacks
(assuming that the attacker is able to completely subvert the OS, rather
than only unprivileged user accounts).
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOiSiuTkCAxeYt5gVAQH7FAf/RFzVGh1H21G/XeCY5n1sWuAAjetkuT1i
T+OHtR2Y4CjH7y8SMk0d/KxVdjZDs7V9M9fkY/6j/EajdCQwSXbpFSnW5OZsiLIN
Gi/D6MRtqw75Byewmt/ruANW99l6GIoOLuBxp1kwwpV1LAMwZGGO6wzv56u9xY4t
uRDkzr0Pj5S/yRVWfbuNBMOPFWrDVP5A5crY9obz+dxxZ8aEqb2itkNdoIOa/zif
ngQIyEd07jnrmy5OKw47cHAxRAi8UU54i2VQkUraPrfkLOHTPz4OCuyNdC3lpoA3
8EAuACq/YIwWDHN9cztYiQ0IIVVSyvn3LfPu05DqvN9NlAkNlN3UAg==
=TlaM
=====END PGP SIGNATURE=====
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Q: Role of linguistics
Date: Wed, 29 Nov 2000 06:37:39 GMT
Although I don't think that an encryption scheme based on these ideas
would be feasable, I do think that a stenographic scheme might be.
Consider: Start with a body of text into which you are going to embed
your message. Feed it to a language parser, which builds some kind of
data structure representing the meaning of the sentences. Then, use the
bits which are to be embeded to select from among the various ways of
writing that structure as english language. To extract the bits, feed
the steno'd file to the parser, and rebuild the structure which
represents the meaning of the sentences. Measure how much, and in what
ways, the sentence in the steno'd file differs from "canonical" form;
those are your bits.
Plus, this method has the added advantage of providing a great excuse
for sending the files back and forth... "Hey, Joe, I'm planning on
sending this love letter to my GF, could you give me some suggestions on
the phrasing?" The steno program would change the phrasing, while
keeping the sentences close to their original meanings, and still being
good english grammer.
Mok-Kong Shen wrote:
>
> If I don't err, in the old days knowldege of languages played
> a non-trivial role in cryptanalysis. With modern cryptography,
> which works at the fine level of bits, the significance of
> linguistics to crypto seems to have disappeared completely.
> Could someone confirm this? On the other hand, advances in
> automatic language translations etc. suggest that automatic
> analysis of sentences is nowadays without problems and perhaps
> even certain degree of understanding of natural utterences is
> feasible. If the domain of discourse is appropriately
> restricted, wouldn't the limited number of sentence structures
> together with default words and eventually in combination with
> a code book be exploitable as a valuable means of preprocessing
> (encoding) of the plaintext before its treatment by a proper
> modern encryption algorithm? Or is this kind of computational
> work too complicated and costly to merit any consideration for
> practical crypto applications? Thanks.
>
> M. K. Shen
> -------------------------
> http://home.t-online.de/home/mok-kong.shen
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: PDF/PS to MS WORD converter
Date: Wed, 29 Nov 2000 06:39:28 GMT
Raphael Phan wrote:
>
> Hi,
>
> Anyone know of any PDF or PS to MS Word converter? I know of some
> that facilitate the other way round but not PDF to Word...
First, use a pdf to ps converter, there are a number available.
Then you should be able to get Word to open the PS (maybe).
--
There are three methods for writing code in which no bug can be found:
1) Make the code so straightforward that there are obviously no bugs.
2) Make the code so complicated that there are no obvious bugs.
3) Insist that any apparent bugs were really intentional features.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Rijndael applications
Date: Wed, 29 Nov 2000 06:50:09 GMT
Red Shadow wrote:
> I'm a student of the university in Ghent and I'm writing a presenation on
> Rijndael. I'm looking for some application or some systeem who are already
> using this algoritme.
> Thanx
GPG - www.gnupg.org
== <EOF> ==
Disastry http://i.am/disastry/
http://disastry.dhs.org/pgp <-- PGP plugins for Netscape and MDaemon
remove .NOSPAM.NET for email reply
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
