Cryptography-Digest Digest #653, Volume #9 Thu, 3 Jun 99 21:13:03 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: Viability of encrypted flash cards? ("Cor!")
Re: what cipher? (better description) ("Particle")
DES Effective Security Q ("karl malbrain")
Re: PGP Key security? ([EMAIL PROTECTED])
Re: what cipher? (better description) (Terry Ritter)
Re: DES Effective Security Q (DJohn37050)
Re: Break this simple cipher ([EMAIL PROTECTED])
Re: DES Effective Security Q ("karl malbrain")
Re: Break this simple cipher (Paul Rubin)
evolving round keys ([EMAIL PROTECTED])
Re: Generating Random Numbers (Glenn, thine Prophet of Chaos)
Re: Is SSL CPU intensive? (fungus)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Thu, 03 Jun 1999 21:47:13 GMT
On Thu, 03 Jun 1999 02:27:47 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
>Redburn) wrote:
>>On Wed, 02 Jun 1999 02:17:42 GMT, [EMAIL PROTECTED]
>>(SCOTT19U.ZIP_GUY) wrote:
<snip>
>>---------------------------------------------------------
>> /* encrypts a file using 19 bit words */
>> un32 iz, izz, i, j, ip, ipp, k, i19, i19s, jj;
>
> un32 is unsigned integer 32 bits in size
You just don't get it, do you ?
What on earth is "iz" ? Is it the distance from the earth to
the sun, is the the number of atoms in the average human
being ? Is it the file length in bytes, is it the file length in 19bit
words, is it the result of some wierd internal calculation specific to
scott19u in which case it would need more explanation ?
There are four general things your cipher might have :
plaintext, cipher text, key and s-box. Thats four variables.
You have declared many more than four variables, please explain
what they are (I don't care what type they are; that is one of
the few things that is obvious from your code - I want
to know conceptually what each variable is for !!!).
>> p19 *pp19;
>
>p19 is a structure of 19 bit fields alined to 32 bit boundaries
>
>> po19 *ppo19;
>
>po19 is an offset sturcture of 19 bit fileds alinen to 8 bit boundaries but
> when used with the pointer *ppo19 will be set behind the *pp19 pointer
> a few bytes so the 19 bit fileds are off set from matching field by 9 bits.
>
Representing WHAT ????
>
> as you see the magor varibles have meaing fill names though short.
>
>> void *v;
>
> v is a void pointer need it to off set ppo19 from pp19 it a weakness in
>modern C that old c's did not suffer. C does allow easy movement of
>pointers of different types you get an error
Wouldn't a cast work ?
eg..
=================
A *variable1;
B *variable2;
variable1 = (A*) variable2;
====================.
That would be far simpler amd more readable than this .......
=====================
A *variable1;
B *variable2;
void *v;
v = variable2;
variable1 = v;
=====================
Just compare the number of variables, the number of assignments
and the number of lines of code. It is should be obvious which is
easier to read.
<snip>
<snip>
>>You don't seem to be jumping to this fairly easy challenge !!!
>>
>>Until you do, the doubters will persist.
>>
>
> maybe I helped with explaning the above cut of code as you
>can see it made perfect since to me.
>
>It is readable!!
>
To a compiler maybe, to a human IT IS NOT !!!!
Anyone would have to be a very sad to waste the time
necessary to work out what all the variables are for.
Just knowning that "iz" is an unsigned 32 is of no help whatsoever.
An unsigned32 could be used to represent an almost infinite number of
concepts. Which one of those concepts are you using it for ? Is it
an array index, is it a counter, is it a distance, ..............etc..
If it's a distance, than what exact distance are you referring to -
london to paris, milton-keynes to new york .......
(same goes for all the other variables)
Do you understand what is being asked yet ?
- Tim.
------------------------------
Reply-To: "Cor!" <in the newsgroup. Unless it's important. PGPkeys:
http://get.to/the.cor.website/>
From: "Cor!" <[EMAIL PROTECTED]>
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: Thu, 03 Jun 1999 22:37:39 GMT
Eric Smith wrote in message ...
>"Cor!"
<[EMAIL PROTECTED]>
writes:
>> If such a system became widely available, then I guess it would be
used
>> by criminals more than anyone else (ie. peadophiles, Chinese workers
at
>> Los Alamos, etc.).
>Why do you say that?
Well, because that's what I thought when I wrote it <g> and I still
think it now, too.
However, I always keep an open mind, and I'm sure if somebody could
suggest good, practical reasons why non-criminals would use this, then
I'm sure my mind would change.
>Do you think PGP is used by criminals more than anyone
>else?
I don't know; I never thought about it before. Are there any statistics
on this?
Anyway, messages sent electronically can be intercepted without the user
knowing; so PGP solves a problem totally different to what was
identified by the thread's originator.
>Do you think that non-criminals have no legitimate use for
cryptography?
Ha, no. (and I hope my view on camera encryption hasn't led you to
stereotype me in the 'anti-encryption' category! :)
--
Cor!�
>There's almost no statement I find more terrifying than "the innocent
have
>nothing to fear."
------------------------------
From: "Particle" <[EMAIL PROTECTED]>
Subject: Re: what cipher? (better description)
Date: Thu, 3 Jun 1999 18:52:40 -0400
Thanks for the numerous responses, but I now realize I
made the description a bit brief and not totally exact.
The cipher-text has to be Exactly the size of plain-text,
even if plain-text is 3 bytes long (or less; or more) This is
the system restriction where I want to implement this,
so, there is little I can do about it.
The cipher should generate a random, 128-bit key, and
upon encrypting the file (using that random key), return
that key and the encrypted file to the user. The user,
"remembers" the key, and saves the file in some public
place where everybody may have access to it, but
nobody can get data from it. (the encryption is totally
reliant upon the key)
Everybody who has the key, should be able to read the file
(obviously), and if they write it (modify), they generate
a new key (no re-used keys) and encrypt the whole
file again.
It would also be *nice* to be able to read part of a file,
without having to decrypt other parts. i.e.: seek to a
specific location, and read from there. That's a contributing
factor to keeping the file size constant. i.e.: you always
know where everything is.
Hmm... the type of threat, hmm... well, lets say the
file is a master database containing accounting information
for a major bank. (i.e.: it has to be VERY secure, that's one
of the reason for such a long, randomly generated key)
The file will of course be digitally signed by person modifying
it (or writing it), and those random keys to files will be
distributed using public key algorithms (at this point, I'm
more worried about the first part... since that's the part
that will open-up the system to the outside)
thanks a lot. (I'm reading every single response I get,
so, please cc them to my e-mail... thanks again)
Particle
[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Way/7650
Home of the Java Data Structures 2nd Edition.
> A really good answer to this question depends on other
> factors that have not yet been discussed, and on details
> of the actual application. If I were paying someone
> for their time to help with this, she would probably
> start by asking questions to clarify the problem.
>
> (The following rather long-winded discussion is really
> just an expansion of the above comment. Skip if I'm
> "preaching to the choir".)
>
> For example, it sounds to me as if the problem is to
> encrypt files (on disk) without changing their size,
> but perhaps this isn't everything? Do we want to
> encrypt data for communication, such as e-mail messages
> or perhaps even individual keystrokes? If encrypting
> files is the point, would a minimum file size (to match
> the block size of the chosen cipher) be an acceptable
> constraint? Or do we need to handle, say, files with
> just three bytes in them? And of course, sometimes we
> find we have overspecified the problem, anyway: it may
> be, for example, that encrypting an entire disk drive
> (rather than individual files) solves a problem in a
> simpler way. It just depends on the situation.
>
> Another broad class of questions would deal with the
> threat model. That is, to decide on a cryptographic
> system we need to decide what sorts of attacks to
> defend against, based on a (conservative) estimate of
> the powers and interests of the attackers. For example,
> do we assume that the attackers might be able to modify
> a disk file, so that we need some means of ensuring the
> data is authentic, or are we just worried about keeping
> the data secret?
>
> Various posts in this thread have given advice of one
> sort or another. Using OFB mode to create a stream
> cipher out of a block cipher certainly is useful in
> some situations. Similarly, data expansion may be
> easy to avoid or tricky, depending on other constraints.
> The thing to note is that to decide whether the advice
> is applicable means knowiwng more about your situation.
>
> Here in the newsgroup, just as for a one-on-one
> situation, the answers will be better when the
> question has more context. It just takes longer.
>
> And is sometimes more interesting...
>
> Particle wrote:
> >
> > I'm looking for a stream cipher, or a block cipher
> > that works in 8-bit intervals. (actually, I'm looking for
> > the algorithm, I'm planning on implementing it myself)
> >
> > It is very important that the ciphertext retain the length
> > of plain text. It has to be fast, and secure (preferably,
> > computationally secure). I would use a derivative of
> > RSA, but that's a bit slow.
> >
> > Oh, I'm willing to use keys upto 128 bits, which
> > will be totally randomly generated and secure from
> > intruders.
> >
> > it would also be nice to have a feature of not having
> > to decrypt all the text before a certain point (i.e.: so that
> > I can seek to the middle of the file, get what I need,
> > without ever touching the start)
> >
> > any ideas on a possible algorithm?
> >
> > please cc reply to my e-mail
> > thanks.
> >
> > --
> > Particle
> > [EMAIL PROTECTED]
> > http://www.geocities.com/SiliconValley/Way/7650
> > Home of the Java Data Structures 2nd Edition.
------------------------------
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: DES Effective Security Q
Date: Thu, 3 Jun 1999 16:10:10 -0700
What is the security ramification for choosing INDEPENDENT values for EACH
of the keys scheduled for the 16 DES rounds, rather than the <<official>>
permuted re-selection of 16 - 48 bit keys out of only 56 source bits?????
Will this approach expand the effective DES key size to 16 * 48 (=768)
bits???
Also, is there any security significance to the 1-bit shift offset in the
EXPANSION function in the rounds????
Thanks, Karl M
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PGP Key security?
Date: Thu, 03 Jun 1999 21:44:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (STL137) wrote:
> <<Try to choose a phrase with over 20 characters, mix case, add
numbers,
> punctuation, and purposely misspel a word or two (My dawg haz flez,
> plez!)>>
>
> Nah. Get a wordlist that has thousands of short words in it. Get 128
bits worth
> of random numbers and divide it up into 9 or 10 chunks. Then go
through your
> wordlist and pick out the words that correspond to those chunks. Keep
them in
> the original order. Bam! Instant great passphrase. For *example*
(this is not
> my real passphrase) a 128-bit phrase may go:
> Weasel Baby Iodine Queen Kitty Home Cow Rake Evil Joke
Look at www.tecapro.com/makepass.html for more information on how to
construct a passphrase. You'll find there a list with 4096 words as
well as program that generates random passphrases - everything is in
the public domain so you are free to use it.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: what cipher? (better description)
Date: Thu, 03 Jun 1999 23:17:00 GMT
On Thu, 3 Jun 1999 18:52:40 -0400, in
<[EMAIL PROTECTED]>, in sci.crypt "Particle"
<[EMAIL PROTECTED]> wrote:
>[...]
>The cipher-text has to be Exactly the size of plain-text,
>even if plain-text is 3 bytes long (or less; or more)
>[...]
>
>The cipher should generate a random, 128-bit key, and
>upon encrypting the file (using that random key), return
>that key and the encrypted file to the user. The user,
>"remembers" the key, and saves the file in some public
>place where everybody may have access to it, but
>nobody can get data from it. (the encryption is totally
>reliant upon the key)
I think it would be legitimate to say that this "returned key" is
close to what we normally call a "message key" (or, in this case, a
"file key"). We can almost always encipher a file in place with a
stream cipher if we get a new random key each time.
But we do have to save the file keys, and saving them securely becomes
a legacy of the system. Keys should always be saved (if at all) in
encrypted form, and store for the keys will expand even if the file
store does not. I would like to know why this is acceptable, but if
it is, it is hard to see any problem at all.
For example, if your ciphering mode needs an IV, just tack the IV onto
the original random key and save a "file key" which contains both key
and IV. No problem.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: DES Effective Security Q
Date: 3 Jun 1999 23:23:49 GMT
I think it has been shown that using independent keys does NOT help, at least
not much.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Break this simple cipher
Date: Thu, 03 Jun 1999 22:49:52 GMT
This was my point. You win the knowledge that you are not silly enough
to post random challenges. I posted that to see what people would
say. Here is the actual algorithm, '1. think of a number, 2. write it
in hex, 3. post as challenge'.
Thanks for playing the game, may this be a lesson to others to post
algorithms not random outputs.
Tom
> Five byte Key:
> 6F A1 FC 43 A3
>
> XOR the message with the key (and the key is repeated) to get (in
ASCII):
> "LEFT MR Gh"
>
> The lessons (?):
> 1: Breaking random challenges is usually a waste of time without the
algorithm.
> 2: Breaking challenges without an incentive is usually a waste of
time.
> 3: With an unknown algorithm, a nearly viable solution can be
concocted.
> 4: Even if a message can't be broken correctly (according to the
author), there
> is no guarantee that the algorithm is secure at all.
>
> So what do I win??? :)
>
> -Giff
>
> --
> Too busy for a .sig
>
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: DES Effective Security Q
Date: Thu, 3 Jun 1999 16:34:19 -0700
DJohn37050 <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I think it has been shown that using independent keys does NOT help, at
least
> not much.
This is completely counter-intuitive for a brute-force exposition of the
key. Can you provide a reference for this analysis??? Karl M
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Break this simple cipher
Date: Fri, 4 Jun 1999 00:34:22 GMT
In article <7j70qe$si0$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>This was my point. You win the knowledge that you are not silly enough
>to post random challenges. I posted that to see what people would
>say. Here is the actual algorithm, '1. think of a number, 2. write it
>in hex, 3. post as challenge'.
>
>Thanks for playing the game, may this be a lesson to others to post
>algorithms not random outputs.
Awww. Here is one of my favorite challenges. The ciphertext is:
"umop apisdn we I". What is the plaintext?
------------------------------
From: [EMAIL PROTECTED]
Subject: evolving round keys
Date: Thu, 03 Jun 1999 23:02:39 GMT
I was just wondering why block ciphers have keys which remain
constant? Would there be any benefit of having post/pre white keys
that change per block (with a cycle length of the 2^n where n is the
number of bits per word).
For example one could consider RC5 with post/pre white as
A = A + R[0]
B = B + R[1]
R[0] = R[0] + D1
R[1] = R[1] + D2
for r = 1 to rounds do
A = ((A xor B) <<< B) + R[2r]
B = ((B xor A) <<< A) + R[2r + 1]
next r
A = A + R[2r + 2]
B = B + R[2r + 3]
R[2r + 2] = R[2r + 2] + D3
R[2r + 3] = R[2r + 3] + D4
Where R are the subkeys, and D1 thru D4 are four unique odd numbers,
derived from the truncated fraction of an irrational.
>From the obvious:
1. Cycle length is 2^n
2. CBC mode will not create similar output from similar input unless
repeated on 2^n intervals.
3. If the D values are unique then the no two subkeys will be the same
more then once in a row.
The update could be done quite simply in C as 'A += (R[0] += D1)'
Any thoughts? I guess the closest cipher would be RC4 where the
internal state updates with each iteration...
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Glenn, thine Prophet of Chaos)
Crossposted-To: news.groups,at.test,alt.gothic,sci.math
Subject: Re: Generating Random Numbers
Date: Thu, 03 Jun 1999 22:52:36 GMT
On Tue, 1 Jun 1999 23:10:54 +0100, "Grimace" <[EMAIL PROTECTED]>
wrote:
>
>Rochus Wessels wrote in message ...
>>I didn't write this message.
>>And it deleted my original answer, which
>>were two useful references:
>>
>>http://www.counterpane.com/yarrow.html
>>http://www.cs.berkeley.edu/~daw/rnd/
>
>Ah, interesting. I can't remember if it did that originally...
I think it did; the last time I saw it, it came in massive quantities
and was dubbed a supercedes attack.
Though I could be wrong.
--
Thine Prophet of Kaos.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Is SSL CPU intensive?
Date: Thu, 03 Jun 1999 22:58:02 +0200
Tim wrote:
>
> How CPU intensive is SSL? I would be sending (encrypting with SSL) ~100
> bytes of data per second. I have a 68030 running at 20 MHz (embedded
> server application) and can allow 20%-30% of the CPU for this task.
> Does anybody know of, or where I can get the number of required clock
> cycles per byte for SSL?
>
If it's RC4 (and it most likely is) then I don't think you need
to worry too much.
On a 68030 we're talking about something like 150 clock cycles
per byte. At 20MHz you can do 100k bytes or more per second.
The RC4 inner workings look like this in C:
int x, y;
char state[256];
char encryptByte(char n) {
int temp;
x = (++x) & 255;
y = (state[x] + y) & 255;
temp = state[x];
state[x] = state[y];
state[y] = temp;
return (n ^ state[ (state[x]+state[y]) & 255 ]);
}
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
** 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
******************************
