Cryptography-Digest Digest #505, Volume #10 Thu, 4 Nov 99 09:13:07 EST
Contents:
Re: What is the deal with passwords? (John Kennedy)
Re: Kerberos Question ("Joseph Ashwood")
Re: A new thread disappeared ? (Ichinin)
Re: Incompatible algorithms (jerome)
Re: Decreased risk using two encryption algorithms? (jerome)
Re: Decreased risk using two encryption algorithms? (jerome)
Re: Q: Removal of bias (Scott Nelson)
Re: Decreased risk using two encryption algorithms?
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: What is the deal with passwords? (Johnny Bravo)
Re: What is the deal with passwords? (Tom St Denis)
Re: Proposal: Inexpensive Method of "True Random Data" Generation
D.J. Bernstein's Cryptography Lecture Notes (slackjawyokel---*)
Re: D.J. Bernstein's Cryptography Lecture Notes (David A Molnar)
Re: D.J. Bernstein's Cryptography Lecture Notes (slackjawyokel---*)
Re: D.J. Bernstein's Cryptography Lecture Notes (Steve Sampson)
Re: An encryption proposal from a Newbie... (CoyoteRed)
Re: An encryption proposal from a Newbie... <- A modification (CoyoteRed)
----------------------------------------------------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 21:35:30 -0500
On Wed, 03 Nov 1999 23:23:06 GMT, [EMAIL PROTECTED] (Dan Day) wrote:
>On Tue, 02 Nov 1999 08:06:14 -0500, John Kennedy <[EMAIL PROTECTED]>
>wrote:
>>High entropy pass phrases are not as difficult to memorize as most
>>people seem to think. Most people can rememeber some fairly long
>>sentences.
>
>I don't think the memorization is the biggest hurdle.
That's right.
> I easily
>memorized Lewis Carroll's nonsense poem "Jabberwocky", for example,
>and can still recite it upon demand today, 15 years later.
>("Twas brillig, and the slithy toves...")
>
>However, I'll be damned if I want to type it in every time I
>need to access my data, and *that's* the real hurdle to using
>a sizeable high-entropy passphrase.
You can type in in once a day or session when you will use encryption.
You can use it to just protect life and death and prison and torture
type stuff.
And if that level of security isn't worth typing in a couple of
sentences, it just isn't. It's your call, it depends on your needs.
It's entirely feasible if you really need it, and if you don't need it
you don't need it.
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Kerberos Question
Date: Wed, 3 Nov 1999 18:35:45 -0800
And to think, even with all of these problems known, only now is M$ adding
Kerberos authentication. Seems more than a little dumb to me.
Joe
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> David Wagner ([EMAIL PROTECTED]) wrote:
> : 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).
>
> The server's response, though, is a *random session key* encrypted with K
> xor M. Nothing more. The attacker was able, in the case of ordinary
> Kerberos, to do a dictionary search because in the next message, the
> legitimate user used the session key to encrypt public data - the current
> time and the user's name.
>
> Of course, this depends on the format of the messages. If the random
> session key had correct DES odd parity, there would be an opening for this
> attack.
>
> John Savard
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: A new thread disappeared ?
Date: Thu, 04 Nov 1999 03:41:55 +0100
Mok-Kong Shen wrote:
>
> Yesterday morning I saw a new thread with a post containing a
> proposal...
> ...
> ...But several hours later, when I tried to look at it again, the
> thread disappreared.
Many threads have dissapeared lately, mine about SAC in SBoxes
dissapeared, luckyly i the replies to it on www.deja.com.
> I like to know whether this is a problem
> specific to my news server (i.e. you still see that article) or
> other people also experienced the same rather strange phenomenon.
> Thanks.
It's not, it's probably just some dark Nsa conspiracy, -"Move along
people, nothing to see here" :o)
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Incompatible algorithms
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 Nov 1999 02:39:55 GMT
Max, please, don't be impressed by Tom St Denis. Most contributors
of this newsgroup are less arrogant and more skillfull.
On Wed, 03 Nov 1999 03:44:16 GMT, Tom St Denis wrote:
>Refer to the MARS AES submission, and do not reply until you know why I
>said that.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Decreased risk using two encryption algorithms?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 Nov 1999 02:59:12 GMT
On 4 Nov 99 01:21:27 GMT, [EMAIL PROTECTED] wrote:
> it seems to offer better resistance to analysis than ordinary double
> encryption, even if it, of course, offers nothing against a
> brute-force search.
can you explain what do you mean by 'better resistance to analysis' ?
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Decreased risk using two encryption algorithms?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 Nov 1999 03:12:18 GMT
On Wed, 03 Nov 1999 00:13:17 GMT, Brent J. Nordquist wrote:
>I have heard that double-encrypting data with two different algorithms
>(in serial, i.e., the encrypted output of one is used as input to the
>other) does not substantially improve its security.
Im not aware of it. can you give me some references about it ?
> It seems to me that it then requires breaking both of the algorithms
> (or keys, etc.) to retrieve the message; breaking only one is not
> sufficient. Would this then improve security?
it would probably if double 'serial' encryptions don't require it.
your sheme doubles the size of the message, requires a true random
number generator, it is 2 disavantages, it has signicantly more
secure to overcome these disavantages.
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Q: Removal of bias
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 Nov 1999 03:57:17 GMT
On Thu, 04 Nov 1999 00:59:30 GMT, [EMAIL PROTECTED] (jerome) wrote:
>On Wed, 03 Nov 1999 17:58:33 GMT, Scott Nelson wrote:
>>
>>Assuming a biased bit which is '1' .75 and '0' .25
>>(entropy = 0.8112781)
>>Using XOR to combine N bits,
>> 1 bits: Entropy = 0.8112781
>> 2 bits: Entropy = 0.9544340
>> 3 bits: Entropy = 0.9886994
>> 4 bits: Entropy = 0.9971804
>>(after 12 bits, it's 1.0 to seven places.)
>
>i don't understand what do you mean by "after 12 bits, it's 1.0 to
>seven places" can you please explain ?
I meant, if you XOR 12 or more biased bits together
(with the bias being .75/25 of 1/0) then the entropy
of the resulting bit is closer to 1.0000000 than to .9999999
The point being that it never quite reaches one, but it's within
1 part per 10,000,000 of one. Since I only listed seven significant
digits or "seven places" that seemed good enough. beyond that,
I start to question the accuracy of my calculator.
In other words, after you XOR 12 biased-bits together,
the probability of a '1' is almost equal to the probability
of a '0'
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Decreased risk using two encryption algorithms?
Date: 4 Nov 99 03:56:03 GMT
jerome ([EMAIL PROTECTED]) wrote:
: On 4 Nov 99 01:21:27 GMT, [EMAIL PROTECTED] wrote:
: > it seems to offer better resistance to analysis than ordinary double
: > encryption, even if it, of course, offers nothing against a
: > brute-force search.
: can you explain what do you mean by 'better resistance to analysis' ?
I can't say that it *does* offer that, only that it seems it might.
Because with ordinary double encryption, you have a stronger cipher - but
it is enciphering plaintext, which may have redundancies or patterns.
This way, each cipher only enciphers geninely random bits; only the
relationship between what the two ciphers are enciphering is the nonrandom
message.
As a relationship, instead of a more deeply buried plaintext, are the
patterns in the plaintext harder to make use of ... or not?
John Savard
------------------------------
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: Thu, 04 Nov 1999 04:07:52 GMT
On 3 Nov 1999 17:10:06 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>In article <[EMAIL PROTECTED]>,
>Scott Nelson <[EMAIL PROTECTED]> wrote:
>>>It has not, thank you.... you're confusing finite sample statistics
>>>with the statistics of an infinite set.
>>>
>>>If I play a (fair) roulette table once and walk away, the fact that only
>>>one number appeared does *NOT* make the distribution other-than-
>>>equiprobable.
>>>
>>
>>After N digits, there is zero chance of 41*N zeros in a row.
>>This is true for all values of N.
>>
>>If PI were "normal" then after N digits, there would be
>>a 1/10^(41*N) chance of 41*N zeros.
>
>That is not true. You're still confusing finite sample statistics
>with infinite set statistics; the infinite tail dominates all
>finite samples.
>
Yes, I suppose I am. I don't know of any definition of
'equiprobable' that works for infinite samples, so I tend
to use finite pieces.
Still, I'm confused as to how the digits of PI can be biased
at any nameable point, but still be unbiased in the totality.
Is there a reference work that can explain this, or better yet,
a working definition of probability that still works with
non-inumerable sets?
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What is the deal with passwords?
Date: Thu, 04 Nov 1999 00:02:00 GMT
On 3 Nov 1999 08:20:30 -0000, Paul Crowley <[EMAIL PROTECTED]> wrote:
>I'm sure that's not true. Normal English has entropy around one bit
>per character. Even if your passphrase is so far out that the entropy
>is closer to two bits, that's still a 64-character passphrase, which
>is really rather long - and in practice, I think two bits per
>character would be inconvenient to reach.
Not really, the key is to use mnemonics to remember your passwords.
I like using the Diceware list as an example, as you can easily generate truly
random passwords from a list with regular 6 sided dice. The list has 7776
entries, so each entry is 12.9 bits of entropy. You would need 10 words for 128
bits. Words picked at random have more bits per character, it's normal English
text that is 1 bit per character.
Example (10 words from the list picked at random):
gus frail marcy block tony daffy nude lisp pity mink
This passphrase is 3 bits per character (not counting spaces).
Mnemonics:
GUS and FRAIL MARCY BLOCK TONY.
DAFFY duck, NUDE and speaks with a LISP.
i PITY the MINK.
If you used the pass phrase several times a day for a few days, then at least
once a day for a week after that, then at least once a week thereafter. You
would have no trouble remembering it
My memory is nothing special, and this is how I remember my secure passwords.
I use them several times a day until I get it down, and make sure I use them at
least once a week so they stay pretty fresh in my mind.
Best Wishes,
Johnny Bravo
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Thu, 04 Nov 1999 05:20:15 GMT
In article <[EMAIL PROTECTED]>,
John Kennedy <[EMAIL PROTECTED]> wrote:
>
> I didn't say it had to be. But 41k seemed pretty small to me for the
> feature set described for this particular program.
Actually the 1.70 version (to be released in two days) has the
following features
) Can encrypt the keyring
) Can encrypt/decrypt files
) Can encrypt/decrypt messages upto 16kb using any one of seven popular
ciphers
) Create/copy/add/delete public/private keys (dh keys)
And is only 44kb. So beat that.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 4 Nov 99 06:11:01 GMT
Scott Nelson ([EMAIL PROTECTED]) wrote:
: ==> 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.
The site you gave - the URL was wrong; I suppose the pi on the end should
be pi.s; was very interesting.
Numbers like the square root of 2, because they are repeating continued
fractions, have only very poor rational approximations.
Pi has some much better rational approximations, such as 3 16/113.
However, even for pi, there is a limit on how good its rational
approximations can be - the site notes Mahler's theorem, which says that
for any rational number p/q, | pi - p/q | is greater than q to the -42
power.
This means that, after the first 100 digits of pi, the next 4200 digits
can't all be zeroes, for example.
That does allow for an (extremely slightly) profitable betting strategy on
the digits of pi, if you have available a *lot* of pennies.
Does that mean that pi is not normal? No, because pi can be normal as long
as it is possible to have *two* zeroes in a row within the first 100
digits of pi...and analogously all the way up.
John Savard
------------------------------
From: slackjawyokel---* <[EMAIL PROTECTED]>
Subject: D.J. Bernstein's Cryptography Lecture Notes
Date: Thu, 04 Nov 1999 02:26:04 -0500
I was hoping someone had copied prof. bernstein's cryptography lecture
notes off the web prior to the court order for removal. maybe that
kind soul could post them for a lowly undergrad. prof. b?(they'd
never know it was you).
Thanks....
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: D.J. Bernstein's Cryptography Lecture Notes
Date: 4 Nov 1999 08:45:25 GMT
slackjawyokel---* <[EMAIL PROTECTED]> wrote:
> I was hoping someone had copied prof. bernstein's cryptography lecture
> notes off the web prior to the court order for removal. maybe that
> kind soul could post them for a lowly undergrad. prof. b?(they'd
> never know it was you).
> Thanks....
is there a particular reason why you want his lecture notes? are you
in his class now? if you can get by with just "notes on crypto", please
specify your interest and maybe there's another class out there which
does have notes posted...
------------------------------
From: slackjawyokel---* <[EMAIL PROTECTED]>
Subject: Re: D.J. Bernstein's Cryptography Lecture Notes
Date: Thu, 04 Nov 1999 03:11:47 -0500
no, i want these specific course notes. if i were in his class i most
likely would not post to a worldwide news server looking for the
course notes. I want these specifically because the government made
him take them off. but in all fairness i do believe i could find all
of the information elsewhere. i want these course notes because i
can't have them.
On 4 Nov 1999 08:45:25 GMT, David A Molnar <[EMAIL PROTECTED]>
wrote:
>slackjawyokel---* <[EMAIL PROTECTED]> wrote:
>> I was hoping someone had copied prof. bernstein's cryptography lecture
>> notes off the web prior to the court order for removal. maybe that
>> kind soul could post them for a lowly undergrad. prof. b?(they'd
>> never know it was you).
>> Thanks....
>
>is there a particular reason why you want his lecture notes? are you
>in his class now? if you can get by with just "notes on crypto", please
>specify your interest and maybe there's another class out there which
>does have notes posted...
------------------------------
From: Steve Sampson <[EMAIL PROTECTED]>
Subject: Re: D.J. Bernstein's Cryptography Lecture Notes
Date: Thu, 04 Nov 1999 03:46:23 -0600
> i want these course notes because i
> can't have them.
Then you can show all your friends and be
famous. They will bow in your presense...
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: An encryption proposal from a Newbie...
Date: Thu, 04 Nov 1999 11:54:24 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
On Wed, 03 Nov 1999 02:17:34 GMT, [EMAIL PROTECTED] (CoyoteRed)
wrote:
>Yes, I can hear the groans already, but...
>
>Okay, let's first assume that this form of encryption will be used for
>relatively small messages AND this will be for one-to-one two-way
>highly-secure communications.
>
>First, we need a random number that is 64k in size. (Never mind where
>we get this number, that's for another discussion, but it must be
>random, not pseudo-random.) And we need to have both parties have
>this number.
>
>We will both generate new key pairs that we will use for communicating
>with each other. These pairs are shared with each other in an
>encrypted form so they are never open to the public.
>
>(A side note: to distribute this number, have one party come up with
>the number and the other generate a large key pair and send his
>partner the public key, encrypted, and the random number can be sent
>back and the public key destroyed. We would have only one message
>with that key out there.)
>
>Once both parties have this number, it is divided into 64 1k files.
>
>To encrypt a file, we generate a random 64 bit key (which will really
>be an index) by what ever means at our disposal. Each bit of this
>index represents one of those 64 1k files.
>
>For each bit that is "on" XOR the 1k random file with the next file
>that is "on", continue until each bit that is "on" and it's
>corresponding file has been XOR'ed in. This is our pseudo-random
>number generator, but because it does not rely on any mathematical
>computations it should not be able to be guessed.
>
>Next, XOR your plaintext with this number. If we run out of room in
>our 1024 bit number, we back up 65 bits. Generate a new 64 bit index
I forgot I was using 1k BYTE number, not 1k BIT numbers...
>key and add a "1" bit to our previous index (to be a 64bit key plus a
>"1"bit). We generate a new pseudo-random number with this key and
>continue with ciphering until we run out of plain text.
>
>Next, we use our partners public key to encrypt our 65 bit index key
>and add it to the beginning of our ciphertext.
>
>Our partner just strips off the first 65 bits, decrypts it with his
>key and reverses the above process.
>
>The advantages of this scheme that I see are:
>
>It has nearly the security of a OTP, it's not as secure because of the
>off chance of a number being repeated.
>
>Once we both have the number, we should be able to generate 2^64 OTP's
>if we choose. The off chance of a duplicate should be remote in the
>extreme if our 64 bit index key is chosen randomly.
>
>A successful attack on the asymmetric keys will only reveal our 64 bit
>index, the attacker would still have to analyze the 64 1k files and
>these are publicly defended by a different key that was used only once
>(and that key was encrypted.)
>
>The ciphertext is small with only 65 bits overhead per 960 bits per
Ditto above...
>data.
>
>It is FAST!
>
>I know a main weakness will be the 64 bit key that is generated for
>our index. So we must concenrate on it's randomness. Of course, we
>could build a list of used indexes and never use the same one twice,
>this /would/ make it a OTP.
>
>A disadvantage is it's setup, you can't just grab someone's key and
>send away.
>
>So... what do you think? How secure? Aside from a physical attack,
>what are it's weaknesses?
>
>Thanks, in advance, for your kindly input.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: An encryption proposal from a Newbie... <- A modification
Date: Thu, 04 Nov 1999 11:54:26 GMT
Reply-To: CoyoteRed (at) Bigfoot (dot) com
Thanks for all your responses...
I've noticed a weakness that some of you picked up on and that's the
index keys. So, I proposes the following change:
After we have establish both sides having the really random 64k
file...
We generate an semi-random number. This number needs to be unique and
have a large number of bits "on." I don't think it has to really be
random, just never repeat. We will call this a "Seed Index Key."
We use this number to generate a random number from our 64 1k files as
before, but this time we don't XOR this number with our plaintext.
Instead, we generate a 64 bit hash from this number. This will be our
first index key.
We then use /this/ key to generate our first number that we will use
to mix with our plaintext.
Also, from this first "mixing number" we will generate a hash from
/it/ to get our next index key. We continue to build until we have a
number as large as our plaintext and then stream the two together (for
the sake of arguments we will continue to use XOR)
As I see it we have done the following:
-We are not sending our index keys at all, encrypted or otherwise.
Only the Seed Index Key.
-We lose the 64 bit overhead in 1k /byte/ number blocks. (see my other
message, I forgot I was using 1k BYTE number, not 1k BIT numbers)
-Even if we sent the Seed Index Key in the clear the attacker would
have to know (or guess) our 1k byte numbers to combine and then hash
to know what index keys to use. And because we will never use the
same Seed Index Key twice our attacker can't use the "Two-Time Pad
Attack."
-Our index keys should be sufficiently random and hidden so there are
no "weak" keys.
-Made it slower.
-We can create nearly 2^64 "near OTP's" of any length from our 64 1k
byte files (or 2^64 1k byte OTP's) and number each one with a single
64 bit number.
OKAY, let's have it! How secure, even if we send the Seed Index Key
in the clear? (We'll add security to this SIK later just for extra
protection, but I want to know how secure the underlying methods are.)
(Remember I'm a newbie and I don't have the advanced math skills to
analyze the system well enough to find fault myself, so I'm relying on
you guys to find the faults in my system)
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
** 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
******************************
