Cryptography-Digest Digest #488, Volume #10 Mon, 1 Nov 99 17:13:02 EST
Contents:
Re: Re: Compression: A ? for David Scott (CoyoteRed)
Re: Kerberos Question ([EMAIL PROTECTED])
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (David
Wagner)
Re: Kerberos Question (David Wagner)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: Compression: A ? for David Scott (Tim Tyler)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY)
pwmbr ("Ran")
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Trevor Jackson,
III")
content type for PKCS#12 in NS ([EMAIL PROTECTED])
What is the deal with passwords? (Tom St Denis)
Re: Doesn't Bruce Schneier practice what he preaches? (Tom St Denis)
Re: content type for PKCS#12 in NS (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: Compression: A ? for David Scott
Date: Mon, 01 Nov 1999 18:29:22 GMT
Reply-To: this news group unless otherwise instructed!
On Mon, 1 Nov 1999 15:15:59 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>: If we can seed a random file from a key then both problems
>: of message size and left over artifacts could be eliminated.
>
>If you do this, you rest the strength of your system on the strength of
>the PRNG.
Okay, I see your point.
>: As to the question about getting the random file to my buddy (if I
>: were to XOR the plaintext first) wouldn't it be easy to send the file
>: encrypted because how would the analyst ever know he has a properly
>: decrypted file?
>
>By analysing it in conjunction with the message later encrypted by
>XORing with it.
True. Like I said, there are probably things that I've overlooked.
So, if we go back to David's argument about one-to-one versus
non-one-to-one compression.
One argument presented was if we used one-to-one and the aggressor
attempted a key and decompressed, what's to stop him from looking at
the compression ratio to determine if it expanded out. (It was
mentioned something about output of /random data in/ (an unsuccessful
decryption) would be /random data out/ which, in turn, doesn't
compress well.) One of the answers that I saw was not all files are
compressible, but if the file is very small and if the aggressor is
looking for a text file then we would assume that the file /was/
compressible. Plus, if it /did/ expand out then we would almost
certainly have a /hit/ and a target for further analysis.
(You couldn't "pad" the output file in an attempt to fool him as he
would probably have written a custom program to analyze your messages
and the "pad" routine would immediately alert him of this. If the
"pad" routine is called he would know he had an invalid key, he
wouldn't even have to try a re-compress and compare. BAD NEWS)
Now, if the file didn't expand out much, we assume one of the
following:
1 - uncompressible file
2 - uncompressed file
3 - pre-encrypted file
4 - invalid key
A quick test for data for any headers and other known patterns for 1 &
2. Then when this fails we need to make a decision to further analyze
for 3 or assume 4 and toss the key and try the next one.
So, in this belief scenario, we might be able to assume that
one-to-one is not free of analysis. Granted, the Comp(DeComp(x))=x
attack is eliminated, but not all attacks.
What if we just compressed for size using the best algorithm available
and then generated a random file to XOR with the compressed data.
Encrypt the random file and package the encrypted random file with
XOR'ed data and send it on it's way.
We vastly suppress the ability to analyze from message to message,
because each message will be XOR'ed with a different file. The only
thing that would be the same is the public key and any assumed plain
text.
While we will vastly increase the size of our message, we would
eliminate any compression based attack or pattern attack angle. We'd
just have to sacrifice size for security.
Because, we've (I believe) have established that XOR'ing your data
with a sufficiently random file makes it /secure/. Our next attack
would come from trying to break the encryption on the random file and
because we have a random file as our "data," wouldn't he be forced to
use brute force and the strength of this would rely on the size of our
key?
If the above is true then the argument of one-to-one versus
non-one-to-one is mute. It would only apply if you wanted smaller
messages and still have high security. I'm not convinced, with
today's bandwidth, that the larger message size would be that
detrimental.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Kerberos Question
Date: Mon, 01 Nov 1999 18:28:43 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
> Well, after describing Kerberos on my web site, I see that the
"obvious"
> way to use public-key cryptography to attack Kerberos' one notable
flaw -
> that vulnerability to password dictionary attacks remains - is not the
use
> of an elaborate protocol like EKE or SPEKE, but something rather
simpler:
Well, I considered SPEKE to be a very simple protocol, especially since
it can be done in 3 transmissions.
>
> let the first message from the user to the Kerberos server include,
> encrypted with the Kerberos' server's public key, a random (64-bit in
the
> case of DES) block of bits and a timestamp, and then in subsequent
> messages, use the random block XOR the user's permanent secret key
> wherever the user's permanent secret key, derived from the user's
> password, would have been used.
Hmm, very nice. By using a key derived from the user's secret key
combined with the random key ensures that the message is new and that
you're talking to the server. Correct me if I'm wrong, but there's at
least a third transmission, correct? If not, then there's no way in
this example that the server can authenticate the user. SPEKE works
somewhat similarly on a high level. The only advantage I see is that
you're not dealing with large numbers as much.
>
> That is sufficient to prevent dictionary attacks, it requires only one
set
> of primes to be generated at the beginning, and it requires only one
> commmunication using public-key methods.
>
> My question is:
>
> who first suggested this scheme, or one equivalent to it (using the
random
> block to DES-encrypt the user key or the user key to DES-encrypt the
> random block, instead of the XOR, I would consider to be essentially
the
> same suggestion) as a modification to Kerberos?
>
> Also: although I never found the Scientific American article I was
looking
> for, I tried finding similar information on the web, and found that I
was
> mistaken about one thing: I had thought that one particular
> challenge-response protocol, used for the password, was fundamental to
> Kerberos, but I see that two or three different methods are used for
the
> password-to-key operation, and I did not need to start there to make
> things understandable.
>
> A diagram with color is used to make the protocol understandable; the
> computers are color-coded, and they're shown with little keys beside
them,
> showing which keys each one knows on entry to each step.
>
> John Savard
>
csybrandy
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 1 Nov 1999 10:38:45 -0800
In article <[EMAIL PROTECTED]>,
Stefek Zaba <[EMAIL PROTECTED]> wrote:
> Now, if Vernon S and/or David W want to lay into the concept of cipher
> negotiation using TLS1.0 as the "standard of practice", I for one would
> be most interested in their enlightenment...
Not me. I think you've got it exactly right. I believe TLS1.0 would
serve as a fine starting point for cipher negotiation in many applications.
However, the TLS negotiation protocol _does_ require that you use
a public-key algorithm to exchange session keys, so it won't help in
symmetric-key-only systems (e.g., Kerberos). It's not clear to me that
we'll always be willing to accept the extra overhead of a public-key
operation in the situations Ritter was envisioning, so Ritter's
negotiation problem might still be open.
(Also, there is at least one subtle implicit assumption that one must be
careful not to violate: for instance, _all_ of the available public-key
algorithms must be adequately strong for all applications -- if even one
of them is too weak, rollback attacks become a problem again. This might
be a concern if you, e.g., mix export and non-export cryptosystems.)
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Kerberos Question
Date: 1 Nov 1999 10:45:10 -0800
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> Well, after describing Kerberos on my web site, I see that the "obvious"
> way to use public-key cryptography to attack Kerberos' one notable flaw -
> that vulnerability to password dictionary attacks remains - is not the use
> of an elaborate protocol like EKE or SPEKE, but something rather simpler:
>
> let the first message from the user to the Kerberos server include,
> encrypted with the Kerberos' server's public key, a random (64-bit in the
> case of DES) block of bits and a timestamp, and then in subsequent
> messages, use the random block XOR the user's permanent secret key
> wherever the user's permanent secret key, derived from the user's
> password, would have been used.
>
> That is sufficient to prevent dictionary attacks, [..]
I'm sure I'm missing something, but can't you trivially mount a
dictionary attack with the following technique?
Pick a random 64-bit xor mask M. Encrypt it with the server's public
key (pretending to be the legitimate client; remember, there is no
authentication yet). Capture the server's response, which will be
encrypted with K xor M. Now do a dictionary search for K using trial
decryption (which is easy, since you know M).
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Reply-To: [EMAIL PROTECTED]
Date: Mon, 01 Nov 1999 19:22:09 GMT
On Mon, 01 Nov 1999 08:35:39 -0700, "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>Uncle Al wrote:
>
>> The digits of pi are purely random (except for being pi). We've got
>> pi to about 50 billion decimal places. Nobody would suspect using the
>> digits of pi becaise it is not a random number. No problem. Use pi.
>
>I would like some reference to this. As far as I know, no one has proved
>that the digits of pi are purely random, quasi random, non random,
>uniformly distributed, etc.
>
Not sure if you are asking for references to the first part,
where Uncle Al claims the digits of PI are purely random,
or to the second part, where Uncle Al claims PI is not a
random number.
If the first, he's wrong;
>From the rec.puzzles archive
==> probability/pi.p <==
Are the digits of pi random (i.e., can you make money
betting on them)?
==> probability/pi.s <==
No, the digits of pi are not truly random, therefore you can win
money playing against a supercomputer that can calculate the
digits of pi far beyond what we are currently capable of doing.
There's more to the answer, which you can read at
http://einstein.et.tudelft.nl/~arlet/puzzles/sol.cgi/probability/pi
or any of the several other places the rec.puzzles archive is stored.
If the second, he's right, for _most_ definitions of random,
since PI is a constant. Whether This can proved or not depends
a lot on how one defines random.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Reply-To: [EMAIL PROTECTED]
Date: Mon, 1 Nov 1999 19:29:39 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: "Tim Wood" <[EMAIL PROTECTED]> wrote:
:>Tom wrote in message <[EMAIL PROTECTED]>...
:>>Worse than that - this scheme makes the implementation of a chosen
:>>plaintext attack trivial, where using standard compression makes some
:>>forms of chosen plaintext attack completely impossible.
:>Assuming that the attaker can _choose_ the plaintext
:>it makes no difference what compression is used. The plaintext chossen
:>is the binary string *after* compression.
:
: Yes as I have admitted many times if you can get the enemy to
: completely encrypt a file of your choice. Then he can control exactly
: the complete file that goes into the encryption phase of the program.
: IN this case it would be essetntially the same as giving the enemy a
: different file with out using the compression at all becasue this would
: be like not using compression at all. [...]
A case where I appear to disagee with David Scott ;-)
*Even* if the enemy can control the plaintext of the message, compression
can /still/ offer _some_ security benefits...
These benefits arise because the enemy still has less cyphertext to
analyse.
Consider the case where an EOR with PRNG output has been used for
encryption:
With a known plaintext, the attack boild down to finding the seed
which was used to create the PRNG, given a section of its output.
This latter problem is widely known to frequently become easier the more
PRNG output is available.
There is generally some threshold, below which finding the seed exactly
and with certainty is not possible, while above the threshold the internal
state of the PRNG (and the key) may be recovered.
The conclusion is not confined to simple stream cyphers - having less
cyphertext to analyse generally hinders the enemy and increases security.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Superior firepower is invaluable when negotiations start.
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Mon, 01 Nov 1999 14:34:05 -0500
Reply-To: [EMAIL PROTECTED]
Scott Nelson wrote:
>
> On Mon, 01 Nov 1999 08:35:39 -0700, "Tony T. Warnock"
> <[EMAIL PROTECTED]> wrote:
>
> >Uncle Al wrote:
> >
> >> The digits of pi are purely random (except for being pi). We've got
> >> pi to about 50 billion decimal places. Nobody would suspect using the
> >> digits of pi becaise it is not a random number. No problem. Use pi.
> >
> >I would like some reference to this. As far as I know, no one has proved
> >that the digits of pi are purely random, quasi random, non random,
> >uniformly distributed, etc.
> >
>
> Not sure if you are asking for references to the first part,
> where Uncle Al claims the digits of PI are purely random,
> or to the second part, where Uncle Al claims PI is not a
> random number.
>
> If the first, he's wrong;
>
> From the rec.puzzles archive
> ==> probability/pi.p <==
> Are the digits of pi random (i.e., can you make money
> betting on them)?
>
> ==> probability/pi.s <==
> No, the digits of pi are not truly random, therefore you can win
> money playing against a supercomputer that can calculate the
> digits of pi far beyond what we are currently capable of doing.
If you have a supercomputer that can calculate pi far beyond
what we are capable of doing, your returns on investments will
be -much- higher if you program it to do derivatives trading
on the stock market. There are all kinds of "scientists"
using Chaos Theory and Fractal economic models who love
losing money with "secret" recipe Quantum Logic.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Mon, 01 Nov 1999 20:35:20 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Tim Tyler wrote:
>>
>> In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> : SCOTT19U.ZIP_GUY worte:
>>
>> :> >Addendum: Corrected example:
>> :> >
>> :> > Side1 Side 2
>> :> > ABCD HGF
>> :> > HS Z
>> :> > FTGF MM
>> :> > XYZ PQ
>>
>> :> How many times are you going to so this this list does not much
>> :> his result in at least to seperate places?
>>
>> ...
>>
>> :> >Now XYZABCDABCD --> PQHGFHGF. A modification of the string on
>> :> >side2 to PQHSFTGF gives PQHSFTGF --> XYZHSFTGF -->PQZMM.
>>
>> :> Besides using invalid dictionary you still are substituing wrong
>> :> PQHSFTGF -> XYZZMM but your dictionary still worng. I am surprised
>> :> you don't see how to follow his rules. This in itself is very
> interresting.
>>
>> : Mmh. Did you write correctly above with your 'worng'?? Now, what
>> : is wrong with my dictionary?
>>
>> You proposed:
>> ABCD HGF
>> HS Z
>> FTGF MM
>> XYZ PQ
>>
>> Note that "XYZ" ends with "Z", which is a dictionary entry "Z".
>>
>> This violates the "no-substring" condition.
>>
>> Also note that "FTGF" starts with "F" while "HGF" ends with "F".
>>
>> This violates the condition that no leading characters in one string
>> should exactly match the trailing characters in another string.
>
>Oh! I thought your conditions are to be applied seperately to each
>side and not to the two sides put together. Then use simply totally
>disjoint characters on each side and with appropriate modification
>of the string on side2 and you are guaranteed to have the same type
>of problem:
>
> Side1 Side2
> ABCD PQR
> EF S
> GHIJ T
> XYZ UV
>
>Now XYZABCDABCD --> UVPQRPQR. A modification gives:
>UVEFGHIJ --> XYZEFGHIJ --> UVST
UVEFGHIJ -> XYZST->UVEFGHIJ
no problem but at leatst you got the strings right.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: the ACM full of Dolts?
Date: Mon, 01 Nov 1999 20:41:31 GMT
>Using an adaptive Huffman with an initial frequency distribution
>does NOT add data to the file. The distribution is completely
>hidden from the analyst.
IF you mean my adaptive huffmna compressor which is one to one
than if you use an intial frequency distributiuon you do NOT add data
to the file.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: "Ran" <[EMAIL PROTECTED]>
Subject: pwmbr
Date: Mon, 1 Nov 1999 20:25:13 +0200
I'm trying to get in touch with the author of PWMBR. His name is Lonnie L.
Logue and he wrote the program in 1992.
He lived in:
9231 Goldenrod Lane
Upper Marlboro, MD 20772
The program encrypts MBR.
If someone knows him or has the sources of the program, please reply to
[EMAIL PROTECTED] .
Thanks.
-- AN MBR PASSWORD SYSTEM --
------------------------------
Date: Mon, 01 Nov 1999 15:14:48 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Bill McGonigle wrote:
> In article <7vjcsb$euq$[EMAIL PROTECTED]>, David Bernier
> <[EMAIL PROTECTED]> wrote:
>
> > Suppose we tune a TV set to a channel with no local broadcasting on
> > it. Let's say also that we have removed the antenna. Next, we put
> > the TV (on) inside a Faraday cage (to block as much electro-magnetic
> > radiation from the outside as possible). This could be some fine
> > mesh wire (maybe of the type used in construction to let air in/out and
> > keep mosquitoes and other pests out?). We would expect to see "snow"
> > on the TV screen unless the TV set is "too smart"
>
> I thought TV snow was cosmic background radiation. In a perfect faraday
> cage, I think all you'd get is black.
>
> Cosmologists/NTSC gurus, please correct me.
Since a TV contains a physical amplifier feeding it zero signal does not
generate zero output. The noises from the early stages, e.g., tuner, get
amplified even if there is no antenna signal.
------------------------------
From: [EMAIL PROTECTED]
Subject: content type for PKCS#12 in NS
Date: Mon, 01 Nov 1999 20:09:13 GMT
Like in IE, content type for PKCS#12 is application/x-pkcs12. What's
that in NS? Please let me know. Thank you very much.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: What is the deal with passwords?
Date: Mon, 01 Nov 1999 20:14:02 GMT
There has been some talk lately about people having to choose passwords
for good security (i.e in pgp and in other applications). I find this
to be absolutely false.
Take a look a peekboo for example. It uses modern cryptography, yet I
can talk to joe.blow without knowing a password. Is it safe? I would
like to think so. Basically the assumption that good passwords can be
easily memorized is long since dead.
Does anybody have any thoughts along these lines?
btw I don't mean to plug peekboo, but it really is the only encryption
software I can find that doesn't use passwords. Feel free to list
other software in replies.
[*] peekboo: http://www.cell2000.net/security/peekboo/index.html
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Mon, 01 Nov 1999 20:10:14 GMT
In article <7vkcsi$18k2$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> If by competing just what the hell do you mean. I have challanged
> the guy to do a contest like my gloat contest since I know and he
knows
> dam well that is FISHY methods can not do such a contest. He would
> fuckin lose that kind of contest and he knows it. But he can becasue
> assholes like you have blessed him sit up there and make many
statements
> that are dumb and you guys don't have the smarts to take him to task.
> Yes he can sit there and take potshots at my code mostly through
his
> employee DW ( was listed as such in his site) that my code is weak
> and that my main contest for cash was short. He even joked about
putting
> the cash up one day for it but like a lot of what it says when push
comes
> to shove he is full of it.
Yak yak yak. Yak yak, yak yak yak yak. Yak yak yak yak. yak!.
BTW, yak yak yak, yak yak.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: content type for PKCS#12 in NS
Date: Mon, 01 Nov 1999 20:15:36 GMT
In article <7vks16$huv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Like in IE, content type for PKCS#12 is application/x-pkcs12. What's
> that in NS? Please let me know. Thank you very much.
>
Totally for sure. :0
PKCS are standards for public key cryptography. Last time I checked
they were not file types. At anyrate they are RSA standards not IE, so
it should be the same in NS as in IE.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
