Cryptography-Digest Digest #660, Volume #9 Fri, 4 Jun 99 20:13:02 EDT
Contents:
Re: The BRUCE SCHNEIER Tirade (wtshaw)
Re: random numbers in ml ([EMAIL PROTECTED])
Re: what cipher? (better description) ("Particle")
Re: Another source of random numbers (STL137)
Re: what cipher? (wtshaw)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: The BRUCE SCHNEIER Tirade
Date: Fri, 04 Jun 1999 15:43:01 -0600
In article <7j8j0e$2hb0$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tim Redburn) wrote:
>
> I ok I guess I have to spoon feed you to show you how you can get
> exactly 128 bits of security since the concept is above you,
> To get exactlt 128 buts of secruity you would need to be able to type
> in 16 charaters each of which has 256 combinations. This is not feasible
> since cetain patterns not allowed or could abort the program. So here
> is a way you could do it. Let the pass phrase be made of octal characters
> "0,1,2,3,4,5,6,7" then take your 128 bits of key you
> need and rewrite is in hex this makes it 128/3 which equals 43 octal
> characters. Type in these for the password. SInce you get a unique
> S-table for each octal combination you have your 128bit key that could
> be used but becareful all 7's is to big and make sure you use exactly
> 43 octal characters to represent the binary key of your choice.
I think that my octal hash method is as workable here as any, allowing for
3 bits per character, and working from alphabetic characters, only one
case needed. I make a list of seeds from the results, but they need not be
used that way at all.
You need a base string from which to work. The easiest to start with is
the normal alphabet, but any deranged alphabet would likely make the hash
give entirely different results.
Get the number of characters you have, and convert each character to a
digit 0-7 as you encounter it, beginning in normal sequence with each A.
If you reach 7, then reset for 0 for the next assignment, and go to the
next letter in your base sequence if you hit the end of the string. What
you get is a line of 3 bit values the same as your string length. If you
need a shorter sequence, trim the overage.
FOR INSTANCE,THIS IMPLEMENTATION REQUIRES ONE HUNDRED CHARACTERS IN ORDER
TO FUNCTION CORRECTLY.HERE ARE THE RESULTS: Offhand, I don't remember
which base sequence I used, but any will do, with any set of characters;
you might want to include punctuation. Bold face is returned from the
routine to confirm the use of the string which can be up to 250
characters. 300 bits are harvested by this Octal Hash, represented in 20
15-bit values, which can easily be converted to any binary form. You
could just as well do a count of 16 rather than 8 to get another
variation.
OCTAL NUMBERS:
40551 02471 46450 23636 25770 26074 13761 10572 40243 11152
04325 21126 05253 66433 46451 46527 72750 70656 71363 33071
> Note the part that may be confusing you. In order to get some speed
> I make the table not from a binarry number but from a list of remainders
> for speed. You have pointed out and that since I do a mod on each random
> number with a decreasing base that certain remainders are more favored
> than others. on other words for those that have no looked at the entropy
> if I have a random number in range 0 to 7 and need a number 0 to 2 I
> could divide by 3 and get a remainder of 0 to 2 but then there is more
> chance of the remainders 0 to 1 occuring then the remainder 2 since
> 0 resultes from 0,3,6 while 1 restults from 1,4,7 while 2 results
> form 2,5 so it is less likely.
> However when the tables is built from the short key you no longer have
> random input and since the string is repeated over and over you keep
> dividing the same numbers by a decreasing base as you build the table.
> since each number is repreated many times but a dieffernt divsor is used
> I don't think there is a problem of 2 octal sequences as described
> above producing the same sequences. IF there is then I am wrong and
> maybe you can show me the error.
>
>
>
> >>
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.cbm,comp.sys.apple2.programmer
Subject: Re: random numbers in ml
Date: 4 Jun 1999 22:38:06 GMT
Reply-To: [EMAIL PROTECTED] (Matthew Montchalin)
Jeffrey Coffin wrote:
>> When you're trying to express an algorithm, C has the distinct
>> advantage of being understandable to a wide variety of programmers.
>> For writing the fastest possible programs, assembly language is a fine
>> choice. For conveying algorithms, it's not nearly as universal.
Davis Holz wrote:
>but the case that we have here is when we're trying to convey an
>algorithm that takes advantage of the carry states of the 6502. Can't
>really do that in C, because the language has no concept of the carry
>flag, unless you use another variable for it.
Speaking of which, did either the Atari or the Apple II play tricks with
the Carry --- along the lines of the source code I posted earlier --- in
order to generate a random number? Did all the 6502 based systems back in
the 1980's resort to extensive multiplication/division just to generate
random numbers? At least with the Commodore, there just wasn't that much
real estate left in zero page to put aside for use as counters ('virtual'
shift registers, for instance) for the random number generator...
--
------------------------------
From: "Particle" <[EMAIL PROTECTED]>
Subject: Re: what cipher? (better description)
Date: Fri, 4 Jun 1999 19:00:32 -0400
> RC4 seem to an effective algorithm here, if high integrity is not needed
> (RCA allows encrypted data to be undeterministicly modified at bit/byte
> level without requiring decryption)
Just read about RC4... and it seems fairly simple. (and fairly good
for my needs)
as for modifying the file... probably not. I'll use a CRC or one way
hash or something (publicly encrypted of course) to make sure the
file is authentic.
I wonder; it said that I can use 16x16 to encrypt a 16bit value
at a time... (instead of an 8-bit one), but can't I do the 16x16 on
the 8-bit level as well... ie: instead of having 256 values in the
array, each from 0-256, I'll have 0xFFFF values each from
0-256... (seems to make it much stronger...)
btw: how important to security that swap of values in the array,
it would be nice if I could avoid it... (that would mean I can
seek to specific locations in the file without looping for a while
to synch the array with the counter)
thanks.
--
Particle
[EMAIL PROTECTED]
http://www.geocities.com/SiliconValley/Way/7650
Home of the Java Data Structures 2nd Edition.
------------------------------
From: [EMAIL PROTECTED] (STL137)
Subject: Re: Another source of random numbers
Date: 4 Jun 1999 22:59:07 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
<<It is true that the digits of pi, for example, have the same
statistical properties as random digits.>>
No. Pi's normality has not been proven. It could go
"1010101011111010100000101010001010101010" at some point (obviously
not terminating in all one digit, of course).
- -*---*-------
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!"
2^3021377 - 1 is PRIME!
I have tenatively released my E-mail block.
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!
- -*---*-------
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.5 for non-commercial use <http://www.nai.com>
Comment: Key ID 0xAC61CF7C
iQA/AwUBN1hZpnUitDysYc98EQKb9ACfbnJG/8mR1oW7PCpri4lgqFxTGOIAn3qS
JBiiq9JeWSojuacHiyWzkS9R
=QJPf
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: what cipher?
Date: Fri, 04 Jun 1999 16:10:15 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Terry Ritter wrote:
> > On Thu, 03 Jun 1999 09:58:39 GMT, in <[EMAIL PROTECTED]>, in
> > sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> > >It is easy enough to combine the (variable) message sequence number
> > >with the (fixed) key to produce a different set of cryptovariables
> > >for each message.
> > Sure. In general I would call that a "message key," and not having
> > some such thing is a very serious loss. But it *expands* the overall
> > message by the size of the message key or IV, ...
>
> No, it doesn't -- the sequence number can be maintained synchronously
> at both ends of the link. However, typically there will be some
> "message header" containing routing instructions, indicators,
> MCNs, MSNs, etc. *and that overhead would be present regardless of
> the crypto algorithm*. Might as well use the routing-independent
> part to help generate message-unique cryptovariables.
Olson and Gywn both seem to suggest that maintaining a constant data size
through encryption is doable while pushing the details for making it work
to somewhere else. This is liken to putting an expendature off-budgit and
claiming that the money is not being spent.
--
Weathermen prosphesize and insurance companies predict, while both pretend to be doing
the other to get an audience.
------------------------------
From: [EMAIL PROTECTED] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Fri, 04 Jun 1999 23:58:56 GMT
On Fri, 04 Jun 1999 21:31:02 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
>Redburn) wrote:
>><snip>
>>>
>>> if( i19 != i19s){
>>> pf19->a00 = 0x7ffff;
>>> iz = geto19(ppo19, i19-1);
>>> pf19->a00 = 0;
>>> izz = geto19(ppo19, i19-1);
>>> i19s += 0 == ( iz ^ izz);
>>> ;}
>>>
<snip>
>>That part uses "pf19->a00" to set a value, then the macro
>>"geto(.....)" to get the value. This is inconsistent.
>
> Again the setting and getting is not necessialry the some memory
>location so your comment is not ture.
>
What do you mean by that ? pf19->a00 must be accessing the
same allocated block of memory (maybe at a different position) that
geto() accesses. (otherwise iz will always equal izz !!) They are
two different access methods !! That is inconsistent. Either
use macros to both set and get or use the structure to set and get
but stick to one or the other.
<snip>
>>
>>If you want people to reuse / modify your algorithm, then provide
>>a high level description of it.
>
> The C code is the high level discription. It really is not that complicated
>your reading more into it than is there.
>
Yes I've read quite a lot into it, but I haven't found an encryption
algorithm yet. If you say I have read more into it than there is, does
that mean that there isn't an encryption algorithm to find ?
<snip>
>>Which loop ? And what is that loop for conceptually, (is it one round
>>of the algorithm, one pass with a chaining mode , an internal loop
>>specific to your algorithm**, etc) .... ?
>
> There is really on one big loop in this subroutine so it is obvious
>what loop I meant.
>
So what does it do then ? Loops can have millions of different
functions. What does yours do ????
>
>>
>>(** in which case it would require additional explanantion).
>>
>>>meaning cn = E((cn-1 ^ pn) + pn+1) gets to be done one extra time. I could
>>
>>So what is "cn = E((cn-1 ^ pn) + pn+1)" all about then ? Is this the
>>main encryption function of scott19u.zip, and the place where all
>>the security lies ?
>
> E() is the 19 bit look up table.
>And no the fact that the whole file is treated as block
>adds to the security.
>
So it's a variable block size cipher ? ( You did say that files of any
size could be used.)
What is cn-1 and pn (I quess that p refers to plaintext and c refers
to ciphertext, but what is the n and how exactly do they refer to
their corresponding texts ? Does it mean c[n] and p[n] ie c at
position n and p at position n ? ) I can make educated guesses,
but that is all they are - guesses. Guesses of any sort are of
no use for an analysis.
Does cn-1 mean cipher text at position (n-1) or (the value of the
cipher text at position n) - 1 ? Or have I got it completely wrong and
it means something completely different ?
<snip>
>>
>>Would you like to elaborate what that function is ?
>
> I have never written the equation done as a closed form
>function but you can derive it if you wish. Take a virtual file.
>then put the field over lays on it. ( in this case the 19 bits)
>notice at the bottom of of overlay don't match with end of file
>it varies as a function of file lenght. Notice the last 19 bit field
>of file contains 0 to 19 bits. There is also a another 19bit over lay
>that is shift 9 bits and it has a funny ending to The point is the
>one that is at end which may be less then 19 bits can borrow from
>the overflow of the top. If it does one needs to know if the shifted
>encrypted filed fits in the space of the shifted (or rotated file)
>the above code checks for that. It was faster for me than righting
>an equation. Why not make the computer work. It also is sit up
>so that code is eay to mod for different filed lenghts.
>
Any chance of a diagram ?
What do you mean by take a virtual file ? Do you mean the plaintext
as an array of 19bit values (conceptually)?
I am starting to get a picture of what is going on, but it seems
very messy at the start and end of the plaintext - is that the case ?
>
>>
>>>To me this seemed the straight forward way to do
>
>>>this but you can do it differentently.
>>>
>>>
>>
>>I don't want to do it differently, I just want to have a go at
>>analysing your algorithm. Unfortuantely, even after reading
>>the source code, I only have a rough idea of what your algorithm
>>actually is, and a rough idea is no use whatsoever for analysing it in
>>anything other than general terms.
>>
>>
>>On to another point now then, still looking
>>at the same function........
>>
>>-------------------------------------------------
>>void
>>doEnce(p19 * a, un32 x)
>>{
>>
>><snip - other variable declarations>
>>
>> p19 *pp19;
>> po19 *ppo19;
>> void *v;
>>
>><snip - claculations not involving v, pp19, ppo19, a>
>>
>> v = a;
>> pp19 = a;
>> ppo19 = v - 2;
>>
>>-------------------------------------------------
>>
>>Most people would assume that the pointer "a", points
>>to the beginning of an allocated block of memory. (there's
>>no comment to suggest otherwise)
>>
>>But if that were the case, ppo19 would be pointing to 2 bytes before
>>the allocated block - a serious programming error !.
>
> You are trying to strech a point.
>You know that in the method
>there is a rotation of the file so that space is added to the top and
>bottom of the virtual memory file so that the wrapping flows more
>smoothly.
No I don't know that. I was trying to follow your advice
and just concentrate on the doEnce function, but there
are too many non-obvious dependancies on other
parts of the program. The function is not modular enough.
The pointer passed to the encryption function should
have been a pointer to the start of the allocated
memory, then any offsets done in the doEnce function
to make it clearer to anyone reading your code.
ie if the plaintext starts 5 bytes into the block, do the pointer
addition at the beginning of the function, and add a comment stating
something along the lines of
/* Set pointer to the start of the plaintext. */
plaintext_ptr = allocated_memory_ptr + 5;
>It was not hard to see where I allocated the file space
>so it could not have been to hard.
It took me some time to find it inamoungst all the other file handling
code that is not relevant to the encryption part.
>Also since ppo19 = v-2 and v = a
>it is obvious that a is not the top of the memory segment or the
>program would not work.
> So what I did was not an error it was obvious what I did and
>deliberate.
Not at first. Only after confirming the correct memory allocation
is it obvious that it was deliberate.
I never said it was an error, just that it looks to anybody examining
only the encryption function, like it was an error. A function should
be modular, and anybody reading it should not have to look
at code elsewhere to confirm it works correctly.
>But I can see where a ivory tower type may think
>it is impure but to me it is not.
Does that apply to your algorithm as well ? In other words, to
others it would appear imperfect but to you it appears perfect ?
Is that your reason for not wanting others to know what your
algorithm is - because you know they'd consider it imperfect ?
>I am allocating a few extra bytes
>at top and bottom also that are not used so you can complain
>about the wasted space
I'm not interested in how much space you waste, I (any many
others) just want to see code that is written for readablility (or
better still a written description with diagrams).
People could probably get more readable source code for scott19u
by decompiling the executable, than reading the source files you
provide.
>but I was debating how much to rotate
>the file and I may change it in a later version to 23 bits instead
>of 9 or I might change the rotate amount form 9 to 23 each pass
>as a fuction of the key so that it would be harder to analyze.
>
All very 'ivory tower', as you would say, thinking about the future
and all that (and more programmers should do), but it in this case it
makes determining the algorithm harder.
>>
>>However it would appear, that "a" is not actually pointing to the
>>beginning of a block but a few bytes in. It took a long time trawling
>>through the rest of the code to verify this though. After doing
>>that, I am just not prepared to seriously examine your source
>>code in more detail.
>
> Come on this was obvious from the few lines you show so
>way are you making a big deal about it. IT WAS INTENIONAL.
>
It wasn't obviouly intentional. To anyone looking solely at the
function they either have to make the dangerous assuption (yes
it is a dangerous assumption) that the program allocated more
memory before the pointer somewhere else in the program, or
there is a huge bug in the program. Both of
which are very poor alternatives. Making assuptions about code
where it is not absolutely obvious what has been done **will**
lead to misunderstanding at some point.
<snip>
>>
>>It should be possible to read and understand that, or any function for
>>that matter, in complete isolation from the rest of your code. Looking
>>at that function in isolation, it looks like it contains a serious
>>error (when in fact it probably doesn't).
>>
>
> Well I disagree with you on this but that is just becasue we must
>have somewhat different programming styles.
>
What ? - it does contain a serious error ? :-)
......and yes, I have a **very** different coding style to yours !!
<snip>
>
> So what would you have passed to this fucntion. I think the top
>of the virutal file was the best thing to pass and just leave working
>room for the wrapping.
>
>
I usually program in C++ so I'd have programmed the whole
thing in a very different way.
-Tim.
------------------------------
** 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
******************************
