Cryptography-Digest Digest #642, Volume #9 Thu, 3 Jun 99 00:13:03 EDT
Contents:
Re: The BRUCE SCHNEIER Tirade (SCOTT19U.ZIP_GUY)
Re: random numbers in ml ([EMAIL PROTECTED])
Re: Smart Cards (Hideo Shimizu)
Re: One-Way hash functions (Gregory G Rose)
Re: New Computer & Printer for Dave Scott (STL137)
Re: PGP Key security? (STL137)
Re: 8Bit encryption code. Just try and break it. (Pierre Abbat)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Thu, 03 Jun 1999 02:10:04 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>On Wed, 02 Jun 1999 01:56:35 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
> Redburn) wrote:
>>
><snip>
>>>identical to the problems of using a OTP, and therefore if someone
>>>finds a practical use for scott19u.zip then they would be better
>>>off going for the proven OTP.
>>
>> I think you are being mislead in that you feel one needs to use
>>the long key feature. You could in theory use almost any file as
>>the source of keyenc.key And then use a short phrase of 128 bits
>>or whatever your heart desires. It is just that you don't have to
>>use a short key of less than a thousand bits unless you really
>>have your heart set on it.
>>
>
>The problem with scott19u.zip is that a 128bit key given to the
>algorithm, does NOT produce 128bits of security. There
>is a loss of entropy during the S-Box setup method.
>
You have shown that the if one uses a uniformily random file that
the entropy is less than the maximum if a uniformly random key
was used. However it is still over one million bytes. Now if one is
using any file for the keyenc.key file and then use 16 charcters as
the pass word you do not have 128bits since for one reason one can not
enter all combinations of 256 bits for each character so one would have
to type a longer string i am not sure how long I guess it depends on the
ascii charter subset you use and but one can calulate the number of
characters needed. You can still get the 128 or 200 or what ever you little
heart desires. For those that what entropy that matches severy possilbe
S table I have code at my site but I feel most people would be happy
with a million bytes or so.
<snip>
>
>I don't actually run the software, for the reason you mention amongst
>others, but even the doEnce function is hard to follow due to the
>nonsense variable names used.
Well I liked the names used if you don't change the names in your
copy of the code. My god what is in a name they only represent numbers
so I can't think what you want there and I am sure if I made long names
they would have no meaning. Hell it reminds me if code I write for an
interial navigation system people bitched no names so made a table
of names up. Like DAS was equal in table to Directionary Analog Scaler
this made people like you happy. But it was goobly gook I used DAS
as a varibale since it was my name. By the way the code worked but
I doubt if anyone has any idea why.
The doEnce function is the main encryption routine it is very short
on input you have a pointer to location in memory while the virtual
file is laid out and the other input is the number of bytes in the file
on output the virtual file has overlaid the other file in memory and it
is the output file and the lenght in is exactly the same as lenght out.
The rest should be easy to follow in the routine it is very short.
>
>>>
>>>The macros used for the 19bit access also make it extremly hard
>>>to read, but add nothing to security - the NSA, MI6 , DFS, and other
>>>gourps (only joking on the DFS one before any complains) would give
>>>new recruits the task of 'deciphering' your source and then
>>>it would probably only take a few days to crack your algorithm
>>>(Yes - that is my opinion based solely on the fact that you, the
>>>designer, couldn't accurately determine the
>>>effective key length of your own algorithm)
>>>
>>
>> It took a long time to develop those macros I had many more but the
>>compiler barfed when the level got deeper.
>
>I don't blame it.
I do the macros make it more like a good macro assembler which are the
best kind so you can build you own high level code. I don't have a good
macro assembler like the good old PDP machines of yesterday.
>
>>The macros were meant to
>>make it easier in the main program since they hanfle most of the problems
>>of 19bit access on a machine that really was made to do 8 16 or 32 bits.
>>
>
>Personally, I don't like code hidden away in macros, just to 'make
>things easier'. This means that you have to trust the macro writer did
>his / her job properly. Why not use functions instead ?
Finctions are slower during execution time.
>
> And stick
>to one method, there seem to be places in your code where you use
>one method to access the tables one minute, then another the next.
>
like where in the code do you mean?
>>
>>>Every time you reuse a key, you double the amount of information
>>>that an attacker has as to the value of the key. With all your
>>>paranoia over security, million bit keys, etc, I would have thought
>>>that reusing a key would be the last thing you would do.
>>
>> Well you thought wrong
>
>So Shannon was wrong then? All his work on unicity distance was
>rubbish ? Is that really what you're saying ?
No I am saying your wrong about me. I do reuse keys sorry to pop
your bubble.
>
>With the size of key that you are using, it is likely that for a few
>megabytes of ciphertext, there are a many keys that would give
>sensible decryptions, however, if the number of ciphertexts gets
>large enough, then there will be fewer and fewer possible keys.
>This makes deciphering easier. If you want maximum security then
>change keys often, and don't re-encrypt the same plaintext twice.
All it means if your using the same key over and over and the
enemy knew it than yes like any method if you find a key that unlocks
the messages your done. but the trick is finding that key.
>
>>however in the next version I may have the ability
>>of a changing key each time 2 people exchange messages the key they use
>>would change. I feel this is an important feature that is lacking. It also
>
>How do you propose this, without causing all the practical problems
I will use data from one of the passes to create a mod in the keyenc.key file
automatically after a successful decrytion set. Hay this is in the futrue it
is not here yet.
>of a OTP ?
>
>>makes it such that if the NSA or other group was saving your old encrypted
>>messages then even you would not be able to recover the previous keys.
>>
>
>
>
>>>
>>>As far as I can tell, but for the reasons mentioned above - ie
>>>hard to read source code, I can't be sure, I think that the
>>>main security of scott19u.zip lies in substituting from the
>>>key dependant S-Box.
>>
>> The reason the Key is so long is that I wanted the ability for
>>any single cycle S-table to be used. However I am writting and
>>will put out a program that allows one using AES or IDEA or
>>what ever and still be able to use "wrapped PCBC" however
>
>So is "wrapped PCBC" where you believe the security of your
>algorithm lies ?
>
The security is in 2 places one the 19 bit S-table with the
effective keylength of up to one million bytes plus. And yes
since a larger block size usually adds to the security of encryption
that is why hardly any one use 8 bits. and know things look headed
to 128 bits or more. THe problem is the files are not in block mutuples
of this size. So the best thing is to treat the whole file ( or largest
pratical block for the use) as a single block. So yes a lot of the
security is in the "wrapped PCBC" that is why I am writting code that
ancii (I hope) it allow others to use it with the AES candidate of choice.
I already see one problem my open of a read only file will be "rb" though
on most machine one should use "r" I am not going to worry about little
things like that and hope some brains are used when looking at the code.
>
><snip>
>
>>>Becasue of the size of the key, it is not possible to memorize it, so
>>>some means of securely storing it is necessary. most people
>>>have only small amounts of information that needs really securely
>>>storing (ie their bank details, medical records, emails etc, in which
>>>case if they have a way of securely storing the scott19u.zip key, then
>>>why not just use that means to store the data they need securing.
>>>
>>
>> Well you can use any size you want so it is as easy to rember
>>as anything else.
>
>So long as you are not bothered what the exact level of security is.
>Scott19u.zip's S-Box setup routine loses entropy from the key.
>
Yes you showed that it does lose entopy so you can pat your self on
the back. If one uses a random file one can still get very possible key
but and the enrtopy is still over one million bytes which I think is still
larger than 128 bits. But for the truely parinod if they can actually get
a random file large enough I have a routine that increases the entropy
of the pick. Again you seem to think you have found something weak
and if it makes you happy and it seems it does pat your self on the
back. But pat your self more if you can prove the enropy is less than
a million bytes.
Also if one types in a fixed number of symbols say 80 for a pass pharse
and use any file for keyenc.key then any change of characters at all in
that phrase causes a unique S-table. Sorry to disapoint you but there is
no loss each change produces a unique encryption key.
>>
>>>
>>>Also,long keys, while offering potentially high security (dependant of
>>>course on many other factors), have to be stored somewhere.
>>>They are then vulnerable to searches by police with search warrants,
>>>MI6 etc sneaking into your house etc. While 128bits might not offer
>>>huge security (dependant on your opinion) they are at least
>>>memorizable and if handled properly, ie not written down, they are
>>>secure from search warrants, intruders etc.
>>
>> use a 128bit key as your password to some other file which you copy
>>to keyenc.key when you run the program no problem.
>
>For the third time, scott19u.zip's SBox set up routine loses entropy
>from the key. You will get less security than you think.
Again you still get more than a million byte which is a hell of a bit
longer than 128 and you should know you did the calculations or did
you forget how it was done. Don' get me wrong you did great work.
But unfortunately you haven't made any progress since then.
>I did in the past, and found them to be inaccurate, so I will not be
>wasting any more time reading them.
Hay you want a description He was willing to do it. Yes he made a
few mistakes. But at least he was willing to get off his ass and take
a look at it. He felt it was worth looking abd I think over all he wrote it
up better than I could have.
>Who better than the algorithms designer ?
I think Paul Onions could write it up if he felt like it.
I don't Bruce could since this is to different than the
weak stuff he plays with and he has no intension of
ever helping one enter the crypto club since it might
mean competaion. I think Terry Ritter could but not
sure he want to spend time on a free one. But he might
patent around the idea.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: 3 Jun 1999 02:37:03 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
Matthew Montchalin wrote:
| >Using the MAS-128 symbolic assembler for the C-128,
John Savard wrote:
| Do you mean the computer manufactured by Commodore, with the ability
| to execute both 6502 instructions (with Commodore-64 compatibility)
| and Z-80 instructions (running CP/M), with 128 K of RAM?
Eyup.
| Let's see if I can make sense out of your algorithm.
|
| In pseudocode inspired by C,
Ayiyi!
| it would be something like:
|
| byte random(void)
|
| static byte seed[5]
| static byte temp1, temp2
|
| byte i,j
|
| i = seed[0] xor temp1
| temp1 = i >> 1
| i = seed[0] + temp1
| seed[0] = temp1 + i <<< 1
|
| i = seed[1] xor temp2
| temp2 = i >>> 1
| i = seed[1] + temp2
| seed[1] = temp2 + i <<< 1
|
| i = seed[0]
| for j = 0 to 3
| seed[j] = seed[j+1]
| next j
|
| seed[4] = i
| return i
I think 'C' tries too much to insulate the programmer from the cold
reality of 6502 assembly language, and the great significance of
the 'Carry' --- as you seem to mention next:
| but if rol does a nine-bit rotate, including the carry bit, then your
| actual routine would be somewhat different.
Yes, one must naturally be familiar with the actual instruction set
employed by the 6502 (ahem, 6510, as found in the C-64, er, 8502, as found
in the C-128) in order to be able to make heads or tails out of the source
code that was supplied. Of course, as you speculated, ROL does indeed
move the Carry into Bit 0 of the Accumulator, just as ROL moves the Carry
into Bit 0 of the Accumulator. However, the LSR that you were looking at
moves a zero into Bit 7, and forces Bit 0 into the Carry. The very first
LSR was very important. Note that ADC uses and affects the carry also.
Altogether, the routine uses the Carry to work its magic. A microprocessor
that fetches very large amounts of data at a time, and moves the Carry very
far away from the bit-twiddling engine of performing Exclusive Or's,
Halving, and Rolling Doubling, and then Adding, would not produce as
confusing a mass of bits. ;)
I don't think 'C' can so easily represent the tricks employed in 6502
assembly language.
| >Lines 260 through 290 were inspired by the routine that Jim Butterfield
| >posted a couple months ago.
|
| And you mean the Jim Butterfield who wrote a lot of programs for the
| PET and other Commodore computers? I'm pleasantly surprised to hear he
| is still active.
He's still around. :)
| >The bias, regardless of seeding (assuming at least minimal
| >seeding, as given above, in seeds 1 and 2), is towards bytes
| >with an equal distribution of 0's and 1's, which is a good thing.
|
| For some applications, bias is never a good thing.
Well, when I mentioned a 'bias' towards generating bytes with half their
bits set, I meant that you *could *generate 65,356 or more bytes (say, in
a file for that purpose), and *later* examine it for 'unusual' runs. As
it stands with the routine right now, you are pretty unlikely to get a
'run' of a dozen or more zero bytes. That's what I meant by a 'bias.'
Now, to get rid of the bias, you just use a bigger algorithm built
with the same kind of bit-twiddling as originally given, but with a bigger
seed. I don't know how big of a seed you would have to use to generate a
series of bytes (somewhere within its sequence) that spelled out:
"Now is the time for all
good men to come to the
aid of their country."
:)
| Quasi-random numbers, with a more even distribution than that of random
| numbers (which pseudorandom numbers strive to imitate) are a valid field
| of study, but they can't just be plugged in everywhere where pseudorandom
| numbers are desired.
One of the things I was wondering about, was just how long the 'period' of
the algorithm was, assuming someone really needed to generate that many
random bytes, until they started to repeat in such a way that a Truly
Intelligent person (or computer) could start predicting the bytes before
they came out. If you know what the period is, you can re-seed it on the
completion of each sequence.
--
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Smart Cards
Date: Thu, 03 Jun 1999 11:43:58 +0900
See http://www.scdk.com/
"Steven H. McCown" wrote:
>
> Sorry for the cross post, but does anyone know of any sites that deal with
> SW development for Schlumberger Smart Cards? Their tech support site is a
> bit slow.
>
> Thanks,
>
> Steve
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: One-Way hash functions
Date: 2 Jun 1999 19:57:57 -0700
In article <[EMAIL PROTECTED]>,
Giovanni Serafini <[EMAIL PROTECTED]> wrote:
>Hi! I'm new here and I need to program a one-way hash function like MD5,
>but with an output of only 64 bit; I know it's easy to break, but for my
>needs it's good; my question: where can I find information about one-way
>hash functions with 64 bit output? (eventually with C-Code).
Use MD5, and XOR the first 64 bits and the last 64
bits to yield your result. Even better, given
Dobbertin's results, use SHA-1, throw away 32
bits, and XOR the halves of what is left.
(Actually, there's no reason to believe that the
XOR step helps, but if the underlying hash is
secure, it can't hurt. If the underlying hash is
broken, the XOR might still help in some way.)
Alternatively, take a block cipher with a 64 bit
block (eg. DES), and use it in one of the iterated
hashing modes (see the Handbook of Applied
Cryptography, by Menezes, van Oorschot, and
Vanstone, pp339-343). For example, to
use Matyas-Meyer-Oseas (ISO standard 10118-2):
Pad your message M to a multiple of 64 bits. (This
is a subject in its own right. The MD5/SHA method
seems to be good, which is: Append a single '1'
bit, and enough zero bits so that there's just
room in the last block for an agreed-upon size
number, which is the length in bits of the input.)
Have an agreed-upon 64 bit initialisation vector, and
call it H[-1].
You need a function that takes 64 bit blocks and
turns them into keys. For DES, this is simply
"correct (or ignore) the parity bits".
Iterate: H[i] = M[i] XOR E(M[i], H[i-1])
(that is, encrypt the blocks of your message,
using the last hash output as the key, and XOR
that with the message.)
The last output is your hash.
You won't find dedicated hash functions with 64
bit outputs, because they're insecure. Please
don't attempt to invent your own. (Note: I'm
assuming that you know what you're talking about
when you say "for my needs it's good". Most people
get this wrong. If coincidences can break
security, the birthday attack applies, and you
need 128 bits to get security of 64 bits.)
hope that helps,
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
QUALCOMM Australia VOICE: +61-2-9181 4851 FAX: +61-2-9181 5470
Suite 410, Birkenhead Point http://people.qualcomm.com/ggr/
Drummoyne NSW 2047 B5 DF 66 95 89 68 1F C8 EF 29 FA 27 F2 2A 94 8F
------------------------------
From: [EMAIL PROTECTED] (STL137)
Subject: Re: New Computer & Printer for Dave Scott
Date: 3 Jun 1999 03:35:48 GMT
<<You know, he could be the next Ron Rivest. >>
Surely you don't mean that.
-*---*-------
S.T.L. ==> [EMAIL PROTECTED] <==
~~~ My quotes page is at: http://quote.cjb.net ~~~
~~~ My main website is at: http://137.tsx.org ~~~
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!"
I block all unapproved E-mail. If you wish to talk to me, post to alt.test.9
with the subject "Moo" and your E-mail address in the body. I will unblock you
as soon as I sign on next. 2^3021377 - 1 is PRIME!
If you see a message of mine posted on two newsgroups, then it is because I
have replied to a crossposted message. I *never* crosspost of my own accord!
-*---*-------
------------------------------
From: [EMAIL PROTECTED] (STL137)
Subject: Re: PGP Key security?
Date: 3 Jun 1999 03:39:05 GMT
<<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
-*---*-------
S.T.L. ==> [EMAIL PROTECTED] <==
~~~ My quotes page is at: http://quote.cjb.net ~~~
~~~ My main website is at: http://137.tsx.org ~~~
"Xihribz! Peymwsiz xihribz! Qssetv cse bqy qiftrz!"
I block all unapproved E-mail. If you wish to talk to me, post to alt.test.9
with the subject "Moo" and your E-mail address in the body. I will unblock you
as soon as I sign on next. 2^3021377 - 1 is PRIME!
If you see a message of mine posted on two newsgroups, then it is because I
have replied to a crossposted message. I *never* crosspost of my own accord!
-*---*-------
------------------------------
From: Pierre Abbat <[EMAIL PROTECTED]>
Subject: Re: 8Bit encryption code. Just try and break it.
Date: Wed, 2 Jun 1999 23:36:18 -0400
On Fri, 28 May 1999, Phoenix wrote:
>>thanks for trying to break my code. If you decrypt it ignore the
>contents of the message it was typed awhile back.
>
> If you succeed e-mail:
> [EMAIL PROTECTED]
========================================
Content-Type: text/plain; name="code.txt"
Content-Transfer-Encoding: 8bit
Content-Description:
========================================
Please:
1. Do not use the MIME type text/plain (or text/*) for binary files. Use
application/octet-stream or something more specific.
2. Use base64 encoding for binary files.
3. Put the message on the Web or FTP and post the URL to news. This is not a
binary group.
4. Include the algorithm when challenging us to break a cipher.
phma
------------------------------
** 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
******************************
