Cryptography-Digest Digest #884, Volume #9 Thu, 15 Jul 99 10:13:03 EDT
Contents:
Re: Benfords law for factoring primes? ([EMAIL PROTECTED])
Re: Is it possible to combine brute-force and ciphertext-only in an
([EMAIL PROTECTED])
Re: How strong would this algorithm be ? ([EMAIL PROTECTED])
Re: Benfords law for factoring primes? (Jerry Coffin)
Re: Benfords law for factoring primes? (Jim Gillogly)
Re: Netiquette Question (Wilhelm von Uberlewis)
Re: What is the "real" length of a key in 3-key 3DES? (fungus)
Re: How Big is a Byte? (was: New Encryption Product!) (Dave Turner)
Re: What is the "real" length of a key in 3-key 3DES? ("Richard Parker")
Re: Creating a key (Mok-Kong Shen)
Re: DES permutations ([EMAIL PROTECTED])
Re: DES permutations (Matthew Kwan)
Re: How Big is a Byte? (was: New Encryption Product!) ([EMAIL PROTECTED])
Re: How Big is a Byte? (was: New Encryption Product!) ([EMAIL PROTECTED])
Re: TLS and stream cipher padding (Gabriel Belingueres)
Re: randomness of powerball, was something about one time pads (Alan Braggins)
Re: What is the "real" length of a key in 3-key 3DES? (Patrick Juola)
Re: How Big is a Byte? (was: New Encryption Product!) (Paul Schlyter)
Re: randomness of powerball, was something about one time pads ("Tony T. Warnock")
Re: Benfords law for factoring primes? ("Tony T. Warnock")
Weak keys question (was Replacing IDEA with Blowfish) (Andy)
----------------------------------------------------------------------------
Date: Wed, 14 Jul 1999 01:19:55 -0400
From: [EMAIL PROTECTED]
Subject: Re: Benfords law for factoring primes?
Douglas A. Gwyn wrote:
>
> Thijs vd Berg wrote:
> > All primes start with a "1", most also end with a "1", SO now you
> > know 2 bits!
>
> Not only that, but I happen to know how to factor *any* prime.
I detect a challenge. What is the largest prime you have factored?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Is it possible to combine brute-force and ciphertext-only in an
Date: Sun, 11 Jul 1999 13:12:46 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] () wrote:
> Yes, I'm well aware this is only a theoretical limitation. One could
be
> sending data that actually *is* random, but then, it would be for some
> sort of future use (i.e. as an additive key) which would allow brute-
force
> attacks involving two intercepted ciphertexts.
>
> But in theory - and the fellow did claim the data was random - this,
like
> the one-time-pad, is a fundamental information-theoretic limitation of
> cryptanalysis. No redundancy, no unique solution.
Nothing is truly random and 'data' cannot be random. Think about it,
what information can one extract from 'random' information (memory...).
If the message was truly random you would not need to encrypt it would
you?
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How strong would this algorithm be ?
Date: Sun, 11 Jul 1999 13:05:05 GMT
In article <leQh3.52$[EMAIL PROTECTED]>,
"Daniel Urquhart" <[EMAIL PROTECTED]> wrote:
> > > allocate table [keylen-2][256]
> >
> > are we talking about bytes or what? Is keylen fixed? Is there a
> > minimum, is there a max. Maybe the table should be fixed in size.
> >
> we are talking about bytes. keylen is NOT fixed, and limited only
memory
> (the computers and yours)
That means little from a design point. Normally lots of memory is only
good in attacks (well little memory is better but you know...)
> This is seeded with bytes but the variables (t1,t2) are DWords. Also,
this
> is called once for every set of 3 consecutive bytes in the key
(keylen -2)
> and only has to generate 256 random values each time.
If you only use the lower 8 bits the period is the same.
> Even though I have allmost no experiance I did guess that this may be
the
> case. The biggest whole, as I see it is that if one has the cipher
text &
> plaintext, one immeadeately knows what the first 'random' number as,
this
> would make if very easy to find a set of canates for the first 3
bytes of
> the key.
Well try to design your cipher to be resilient to this attack.
> I meant: out[i] = table[ rem(i,keylen-2) ][ out[i-1] ] XOR in[i]
Note: why are you doing keylen-2? Why not pick a step value and avoid
division?
Plus rem(x, y) is formally denoted as 'f(x, y) = x mod y'
> I explaned this in the comments rem(x,y) gives the remainder of X/Y.
I know
> that this is not standard notaion, but I just finished grade 10. . .
I just finished grade 11, so what. Learn the notation (it's hard I
know but it will help you)
So basically you have
for i = 1 to blah blah
out[i] = table[i mod keylen-2][out[i - 1]] xor in[i]
All this means is that every 'keylen-2' output will use the same table
entry. Is the lower array (i.e table[x][y] the y part) a function of
the 'y' value or just a random table? If it's the latter you have to
make sure the outputs are statistically independant and hopefully
decorrelated somehow.
What is out[-1] though? What do you do for the very first input (use a
IV I would hope). Also this lets the attack know what the inputs into
the table were.
i.e let's say the last out was '7', the next input was 3 and the output
was 2, we know that
table[i][7] = 1
Where i = current i value (mod keylen-2).
This type of attack could find the entire table easily. Do you re-key
the table? You should make it less linear somehow...
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Benfords law for factoring primes?
Date: Thu, 15 Jul 1999 00:57:55 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> I detect a challenge. What is the largest prime you have factored?
You name a large prime, and I'll give you its factorization as fast I
can repeat the number back to you (along with "One and ").
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Benfords law for factoring primes?
Date: Wed, 14 Jul 1999 22:36:43 -0700
Douglas A. Gwyn wrote:
>
> Not only that, but I happen to know how to factor *any* prime.
In that case you may be in line for a huge reward from Bill Gates,
who said in The Road Ahead:
Because both the system's privacy and the security of
digital money depend on encryption, a breakthrough in
mathematics or computer science that defeats the
cryptographic system could be a disaster. The obvious
mathematical breakthrough would be development of an easy
way to factor large prime numbers. Any person or
organization possessing this power could counterfeit
money, penetrate any personal, ...
In his defense, earlier in the chapter he shows he knows what
primes are and what he really meant to say, but still it's
seriously humorous, coming from the most powerful geek in
the world.
--
Jim Gillogly
22 Afterlithe S.R. 1999, 05:32
12.19.6.6.10, 8 Oc 18 Tzec, Fourth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Wilhelm von Uberlewis)
Subject: Re: Netiquette Question
Date: Thu, 15 Jul 1999 00:40:52 +0000
In article <7m4rgj$9ik$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>There is no legal obligation to keep private emails private. It's up
>to the receipients disgression.
This isn't a question of legality[1]; this is a question of etiquette.
(Take a gander at the subject line.)
Anyway, my two cents:
Quoting a received email (attribution & all) to news is considered
improper and gets some people very upset.
Paraphrasing someone's mail (e.g. "After my last posting I received a
message saying that ...") is usually OK, as long as you use some common
sense. Likewise attributing the info to the person who mailed it to
you. It depends on what reason the sender had to use mail instead of
following up: if in doubt, send them mail and ask them if it's OK.
Excerpting a bit of received mail is a gray area.
[1] There *is* a legal aspect as well, of course: the sender of the
email presumably has copyright on it and may object to your
use of the text beyond your implied license. This is getting
into legal-nitpick territory, though.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Thu, 15 Jul 1999 04:40:22 +0200
In article <7mia8t$fea$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> (Patrick Juola) writes:
> ...
>
> > Not so. New article in J. Cryptology by our old friend Eli Biham
> > takes 3DES apart in about 2^64 steps.
>
> Ouch. History in the making. "May you live in interesting times."
The web page says he needs 2^56 - 2^66 chosen plaintexts, so this
isn't much of a practical weakness.
One question: How can a 64-bit (blocksize) cipher need more than
2^64 chosen plaintexts to break?
Surely when you've "chosen" 2^64 plaintexts then you've got the
complete mapping of plaintext<->ciphertext.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Dave Turner)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Wed, 14 Jul 1999 14:59:06 GMT
Reply-To: [EMAIL PROTECTED]
"donald tees" <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote in message
>>
>>Yup. They couldn't count on two hands.
>>
>If God had meant us to think in decimal, she would not have given us four
>fingers and a parity thumb on each hand.
The IBM 7074 was a decimal based machine. Ours had 10,000 ten digit
signed words. Each of the digits used five bits with a two-out-of-five
coding scheme.
So perhaps God did mean for us to think in decimal....
The 7074 predated the 360 by five years or so.
Regards,
Dave
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Thu, 15 Jul 1999 08:59:20 GMT
In article <[EMAIL PROTECTED]>, fungus
<[EMAIL PROTECTED]> wrote:
> One question: How can a 64-bit (blocksize) cipher need more than
> 2^64 chosen plaintexts to break?
>
> Surely when you've "chosen" 2^64 plaintexts then you've got the
> complete mapping of plaintext<->ciphertext.
Note that Biham's paper demonstrates attacks against cryptographic
modes, not against a block cipher itself. So:
1) The dictionary attack against ECB mode (which requires 2^64 known
plaintexts for a cipher with a 64-bit blocksize) allows one to decrypt
messages, but it does not recover the key.
2) While the dictionary attack is effective against the ECB
cryptographic mode, other modes resist this attack since they don't
always encrypt the same block of plaintext to the same block of
ciphertext. Attacks against these modes may require more than 2^64
chosen plaintexts to recover the key.
-Richard
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Creating a key
Date: Thu, 15 Jul 1999 11:07:05 +0200
karl malbrain wrote:
>
> What I do is to use a pseudo-random number generator to repeatedly select 10
> source key bits (using only the lower 5 bits of each source byte for case
> insensitivity), using the half-added sum for each bit of binary key
> required.
If you employ digits, you may also be interested in a simple hardware
mentioned rather recently in this group that the Canadian and German
lottery gave as a present to their customers.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES permutations
Date: Thu, 15 Jul 1999 09:55:55 GMT
In article <7mfoqc$n2a$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7k51r0$gjr$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > > >DES;
> > > >1 That initial permutation; is it actualy worth
> > anything cryptograpicaly?
> > >
> > > No. They were put there to support the hardware
> > implementation of DES that was popular in the mid-1970s.
>
> > I've heard and read this several times but while
> > being from a hardware background I cannot see how
> > the initial permutation could speed up the
> > hardware implementation. Does anyone know how it
> > helps the hardware?
>
> It doesn't help hardware. It doesn't take any
> time in hardware. (No *extra* time beyond normal wiring
> delays)
>
> What it *does* do is royally slow down any software implementation.
> *That* was the point.
>
I agree that they slow down the software implementation but the DES
rounds contain 16 other permutations, expansion functions and S-boxes.
The time spent on the initial and final permutations increases the DES
operation time by perhaps a 1/10th. This does not slow down the
software by an amount that will seriously effect its usage.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Matthew Kwan)
Subject: Re: DES permutations
Date: 15 Jul 1999 21:05:09 +1000
[EMAIL PROTECTED] writes:
>In article <7mfoqc$n2a$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> In article <7k51r0$gjr$[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] wrote:
>> > > >DES;
>> > > >1 That initial permutation; is it actualy worth
>> > anything cryptograpicaly?
>> > >
>> > > No. They were put there to support the hardware
>> > implementation of DES that was popular in the mid-1970s.
>>
>> > I've heard and read this several times but while
>> > being from a hardware background I cannot see how
>> > the initial permutation could speed up the
>> > hardware implementation. Does anyone know how it
>> > helps the hardware?
>>
>> It doesn't help hardware. It doesn't take any
>> time in hardware. (No *extra* time beyond normal wiring
>> delays)
>>
>> What it *does* do is royally slow down any software implementation.
>> *That* was the point.
No, the point was to amount of chip *space* needed to implement DES.
The IP made the wiring simpler. Software was probably not a consideration
at the time.
mkwan
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Thu, 15 Jul 99 09:15:17 GMT
In article <7micrk$j9f$[EMAIL PROTECTED]>,
"donald tees" <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote in message
>>
>>Yup. They couldn't count on two hands.
>>
>If God had meant us to think in decimal, she would not have given us four
>fingers and a parity thumb on each hand.
>
She???!!?? Octal plus a parity bit with one left to suck.
/BAH
Subtract a hundred and four for e-mail.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Thu, 15 Jul 99 09:19:29 GMT
In article <7mi4nl$uce$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>In <7mf54o$ocu$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
>>In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] (Alan J Rosenthal) wrote:
>>>Jim Gillogly <[EMAIL PROTECTED]> writes:
>>>>Of course, nobody disagrees that bytes are usually 8 bits on modern
>>>>machines, most of which (for our sins) are Intel boxes running a
>>>>Microsoft OS.
>>>
>>>If I recall correctly, in the mid and/or late 1970s (and possibly
through
>>>early 1980s), when there were IBM fans and DEC fans, the IBM types used
>>>the word "byte" to mean "8 bits" and us DEC-oriented folks found this as
>>>annoying as many of you find, for example, spelling "lose" as "loose" in
>>>usenet messages. Of course, we had a three-bit bias due to octal
numbers,
>>>whereas THOSE people used hexadecimal and had a four-bit bias.
>>
>>Yup. They couldn't count on two hands.
>>
>>/BAH
>>
>>Subtract a hundred and four for e-mail.
>
>Hey, we used our toes, too!
>
>Whoops, too much information. :*)
Yup. That why we could run rings around them :-). They had
to stop to put their shoes on first.
/BAH
Subtract a hundred and four for e-mail.
------------------------------
Date: Thu, 15 Jul 1999 05:41:11 -0600
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TLS and stream cipher padding
Hi, me again. Sory, I've made a mistake in the question (I was really
tired).
See below the corrected question:
Does anyone out there knows why in the TLS 1.0 spec (RFC 2246), when it
is used with a stream cipher, it does NOT generate a random padding,
just like
for block ciphers?
If you read the paper "Analysis of the SSL 3.0 protocol" by Bruce
Schneier & David Wagner (you can find it at http://www.counterpane.com),
they talk about an attack based in the aproximated length of the HTTP(S)
GET request, in witch an attacker can figure out witch html page you
have accessed.
Why this padding was not contemplated for stream ciphers in TLS?
Gabriel
------------------------------
From: Alan Braggins <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: 15 Jul 1999 13:39:15 +0100
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> remaining doors? On the assumption that the host *knows* where
> the good prize is and as a matter of policy *always* opens a
> bad-prize door, the new odds are 1:2 in favor of the third door.
> If he had just opened a door on whim, with the reported result,
> then the new odds are 1:1. (If you don't know which of these is
> the case, then switching can't hurt and might help.)
On the other hand if he only ever opens a door if you have already
chosen the prize door, switching will hurt. But viewers could be
expected to notice, and once the pattern is noticed no-one will ever
switch.
I'm still not sure about the case where he doesn't always open a door,
and sometimes opens a door when it will help you, but is more likely
to open a door if you have already chosen the prize.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: 15 Jul 1999 09:00:52 -0400
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
>In article <7mia8t$fea$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>> (Patrick Juola) writes:
>> ...
>>
>> > Not so. New article in J. Cryptology by our old friend Eli Biham
>> > takes 3DES apart in about 2^64 steps.
>>
>> Ouch. History in the making. "May you live in interesting times."
>
>The web page says he needs 2^56 - 2^66 chosen plaintexts, so this
>isn't much of a practical weakness.
>
>
>One question: How can a 64-bit (blocksize) cipher need more than
>2^64 chosen plaintexts to break?
Feedback modes. If you're using one of the modes other than ECB
(electronic codebook), then the encryption of the current block
depends on the (encryption of the) prior block as well as the key.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 15 Jul 1999 15:09:34 +0200
In article <[EMAIL PROTECTED]>,
Dave Turner <[EMAIL PROTECTED]> wrote:
> "donald tees" <[EMAIL PROTECTED]> wrote:
>
>>[EMAIL PROTECTED] wrote in message
>>>
>>>Yup. They couldn't count on two hands.
>>>
>>If God had meant us to think in decimal, she would not have given us four
>>fingers and a parity thumb on each hand.
>
> The IBM 7074 was a decimal based machine.
This is no accident: most, if not all, of the computers of the
1950'ies were decimal based. Even the opcodes were coded as decimal
numbers. Apparently the very first generation of computers were
built to mimic mechanical calculators as much as possible.
> Ours had 10,000 ten digit signed words. Each of the digits used five bits
> with a two-out-of-five coding scheme.
>
> So perhaps God did mean for us to think in decimal....
>
> The 7074 predated the 360 by five years or so.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: randomness of powerball, was something about one time pads
Date: Thu, 15 Jul 1999 07:52:12 -0600
Reply-To: [EMAIL PROTECTED]
"Douglas A. Gwyn" wrote:
> fungus wrote:
> > There's one game where you pay a dollar, choose a number from one
> > to six, then throw three dice. You win a dollar for every die which
> > shows your chosen number. Who has the edge? The player or the house?
>
> As described, the odds are even (it's a fair game).
>
> I think you meant to describe "Chuck-a-Luck", where you win a dollar
> if your chosen number comes up on any die, but never more than $1
> per play, and lose a dollar if it doesn't come up on any die.
> In that case, the odds favor the house (you expect to lose over 15
> cents per play, in the long run).
>
No, the game as described, 1 euro for 1 die, 2 euros if it occurs twice, 3
euros if it occurs 3 times is unfair. (of course a fair game in euros may be
a losing proposition.) This is Chuck-a-Luck. 1,2,3 payoffs. Fair payoffs are
1,3,5 and 1,2,20 I think.
Tony
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: Benfords law for factoring primes?
Date: Thu, 15 Jul 1999 07:53:26 -0600
Reply-To: [EMAIL PROTECTED]
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > I detect a challenge. What is the largest prime you have factored?
>
> You name a large prime, and I'll give you its factorization as fast I
> can repeat the number back to you (along with "One and ").
13 = (3-2i)(3+2i) of course 13 isn't prime here.
------------------------------
From: Andy <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Weak keys question (was Replacing IDEA with Blowfish)
Date: Wed, 14 Jul 1999 23:11:47 +1100
[EMAIL PROTECTED] wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
...
> Clear some things up...
>
> 1) Both have 'weak' keys. In blowfish you have a 2^-14 chance of
> getting a random key that produces 'collisions' in the sboxes. In IDEA
> you have a 2^-96 chance of picking a key with weak multiplications
> (they are identities...). The later can be exploited much quicker then
> in Blowfish and Blowfish with 16 rounds has not been broken yet.
Is there a 'standard' way of dealing with this? For example with
Blowfish,
after generating the key schedule, one could check for 'collisions' in
the
s-boxes. If a collison is found there seems to me to be several options
(depending on circumstance). These are
a/ ignore the collision - I won't tell anyone if you won't :-)
b/ if derived form a user entered pass-phrase, ask the user
to enter another pass-phrase,
c/ if derived from some random source, then get another (partial)
random key.
Why isn't there some 'auto collsion avoidance' build into these
algorithms?
For Blowfish, one could envisage say, incrementing a duplicate s-box
entry
until all the entries are unique, or perhaps incrementing the key and
repeating
the key schedule generation until there are no collisions.
Regards
Andy
------------------------------
** 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
******************************
