Cryptography-Digest Digest #659, Volume #9 Fri, 4 Jun 99 18:13:02 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: One-Way hash functions (Giovanni Serafini)
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: DES Effective Security Q (Jim Gillogly)
Re: iButtons (Matthias Bruestle)
Re: Viability of encrypted flash cards? ("Cor!")
Re: Obscure Code ([EMAIL PROTECTED])
Re: Obscure Code (John Savard)
Re: Another source of random numbers (John Savard)
Re: Challenge to SCOTT19U.ZIP_GUY (David Hamilton)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Fri, 04 Jun 1999 20:30:26 GMT
In article <[EMAIL PROTECTED]>, Geoff Thorpe <[EMAIL PROTECTED]> wrote:
>Hi there,
>
>"Douglas A. Gwyn" wrote:
>>
>> Tim Redburn wrote:
>> > Do you understand what is being asked yet ?
>>
>> My suggestion is that he read *and understand* the classic book,
>> "The Elements of Programming Style" by Kernighan & Plauger, or the
>> recently published "The Practice of Programming" by Kernighan & Pike.
>
>SCOTT19U is clearly "winning" something here ... everybody is actually
>battling with him to defend his claims about his software, many are
>trying to interpret his algorithms with his help (because he flippantly
>accuses them of being stupid if they can't understand the source code),
>and all the time we're actually dealing with someone who is not only of
>questionable cryptographic skill, but is clearly of questionable
>programming skill.
>
Thanks for saying I'm "winning" tho it is clear that you don't mean
what you say.
>Hey, he writes poor code. He refuses to adequately document his own
>"techniques" (the mindless accusations that only stupid people don't
Only a few think the coding is poor. I don't have to follow rules that
others blindly follow. And the code is full of many comments. But
it should be clear to any one who has a working knowledge of C and
some baiscs of how a PC works. Yes I don't make every one happy
that would be an impossible job.
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: Giovanni Serafini <[EMAIL PROTECTED]>
Subject: Re: One-Way hash functions
Date: Fri, 04 Jun 1999 22:33:51 +0200
I have found a solution to my problem reading the source code of md5: I
noticed
that we can set the length of the output... So I set it to 64 bit and I was
happy...
Thanks to all which helped me, sending me an email or responding directly in
this
newsgroup...
Giovanni
Giovanni Serafini ha scritto:
> 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).
>
> Thanks.
>
> Giovanni
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Fri, 04 Jun 1999 21:31:02 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>On Fri, 04 Jun 1999 04:42:09 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);
>> ;}
>>
>> The above is where iz is used it really has no meaning since the inputs
>>and outputs of the routine are fully defined you can see that iz is derived
>>from things already defined.
>
>That doesn't make it obvious what they are.
>
>>The section of code your looking at gets
>>executed only once per encryption
>
>That fact is obvious. It still doesn't make it obvious what it does.
>
>Anyway, the reason that I included that section of code, was because
>you wanted me to point out a part of your code that is inconsistent.
>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.
>
>(to anyone wondering, this is actually from a post in another thread,
>not the one that david replied to strangley)
>
>
>> the above was done to make the code
>>easy for some one who wants to modify the code for bit sizes other than
>>19bits
>
>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.
>
>>or in case that want to rotate a different amount than 9 bits. What
>>this code does is to detemince if one can stay in the loop one extra time
>
>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.
>
>(** 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.
>
>>have caluclated this with a different method but thought this was more
>>straight forward.
>
>I can't see how you could possibly make that more difficult to
>read, without **really** trying hard.
>
>>The number if times to do the equation is a function of file
>>length bit field size and bit rotation amount and is differnet for different
>>file lenghts.
>
>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.
>
>>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. It was not hard to see where I allocated the file space
so it could not have been to hard. 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. But I can see where a ivory tower type may think
it is impure but to me it is not. I am allocating a few extra bytes
at top and bottom also that are not used so you can complain
about the wasted space 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.
>
>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.
>
>Every few lines of source code seems to need many other lines to be
>referred to by anyone reading your code, to actually determine what is
>
>going on. You made a small attempt at modularity by using functions,
>but unfortunately it failed miserably, because of wierd dependancies
>like this.
>
>If it was necessary to pass a pointer to a function, when the pointer
>does not reference the start of the allocated block, it would
>probably be a good idea to add a comment explaining first of
>all that this is what is actually happening, and then your reason why.
>
>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.
>You say yourself, that anyone wanting to
>understand your algorithm only has to look at the last few functions.
>That is clearly not true, because of these dependancies.
>
>Until you tidy up your code or describe your algorithm at a higher
>level, it is going to get very little serious attention, and the
>sceptics will persist.
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.
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: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DES Effective Security Q
Date: Thu, 03 Jun 1999 18:15:03 -0700
karl malbrain wrote:
>
> 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
Biham & Shamir (Differential Cryptanalysis of DES, Springer-Verlag 1993)
show it's vulnerable to differential cryptanalysis with 2^61 chosen
plaintexts. Not a very practical attack, but not the level of difficulty
you want from a 56*16-bit key. See Schneier 2nd, p.295.
It's certainly intuitive that it would be harmful against a differential
fault analysis attack, since each key bit now affects only one round.
I'd think you could recover the last-round bits almost directly, and
work your way forward without the complication of key bits affecting
multiple rounds.
--
Jim Gillogly
Trewesday, 14 Forelithe S.R. 1999, 01:02
12.19.6.4.9, 6 Muluc 17 Zip, Eighth Lord of Night
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: iButtons
Date: Fri, 4 Jun 1999 20:28:22 GMT
Mahlzeit
Greg Bartels ([EMAIL PROTECTED]) wrote:
> but using iButton (or simialar) as a means to protect your private
> key used to do credit card transactions over the internet will
> probably suffice enough for most people.
Sure.
> even a one-time-pad is suceptible to
> attack while the key is being stored somewhere,
> There's been fraud long before there were computers.
> if you wait until an electronic device is "fraud proof", you'll
> be waiting forever.
That's why I don't want to store unencrypted keys on devices.
Smart cards/iButtons/similar are IMO good enough to store transaction
or signature keys but not (unencrypted) encryption keys.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
A lot of occult writers have made some amazing guesses as to what
that means. Actually, it doesn't mean a damned thing.
------------------------------
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: Fri, 04 Jun 1999 21:52:07 GMT
Matthias Bruestle wrote in message
<[EMAIL PROTECTED]>...
>Mahlzeit
>
>
>Cor!
([EMAIL PROTECTED])
wrote:
>
>> 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.
>Journalists, Human-rights groups
Why would they use it? (You haven't suggested good, practical reasons.)
Surely if their cameras were seized by some military dictatorship (or
similar), they would get destroyed. End of story. (?)
The point about encrypting the camera was to prevent images containing
incriminating evidence from being *used* by the law or the overwhelming
force which seized it.
>> .... suggest good, practical reasons ....
--
Cor!�
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Obscure Code
Date: Fri, 04 Jun 1999 20:47:43 GMT
Dianelos wrote:
> > There are other ways to make a cipher difficult to analyze even
> > if the cipher itself is public.
wtshaw wrote:
> One of the quickest methods is to undocument sourcecode, and make
> some variable names appear the same or similiar when they are
> different. These tricks make the labor needed to clean up the mess
> considerable. Since some characters are easy to confuse with certain
> others, use that fact
Making source code more difficult to read is not a good idea. This
would be only a small notch above distributing object code alone which
anybody can disassemble with a little effort.
> Another method, alluding in limited respects to Frog, is to branch
> wildly and/or redundantly, as excessively as possible, (...)
Frog is a very simple cipher and I don't think it is difficult to
analyze.
> Another is to build realtime code from data structures, inserting it
> at key points that grossly affect how the program works. (...)
Yes, this is one possibility: build a cipher generator and have it
produce code as a function of a data structure (the key). The cipher
generator itself is public and well documented even though the ciphers
produced and used will remain secret by definition. The cryptanalyst
will have a difficult task analyzing all possible resulting ciphers.
The simplest way to build a cipher that is difficult to analyze is to
build a complicated cipher. Here is one possibility:
Some ciphers use hash functions as a primitive. Hash functions can be
build automatically by having a computer "design" such functions in a
random manner and then test them for quality. Leave the computer
working for days and then choose the best machine produced hash
function. This hash function would include hundreds of machine code
instructions and have no elegance whatsoever. The cryptanalyst would
have the difficult task to study a long section of code that looks
meaningless, uses no structure or mathematical underpinning at all, but
works. My first cipher, GodSave, has a long section of machine
generated hash code.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Obscure Code
Date: Fri, 04 Jun 1999 21:56:49 GMT
"Oliver J. Hanau" <[EMAIL PROTECTED]> wrote, in part:
>Does anyone now if there is any kind of source on producing obscure
>code, i.e. code that is hard for an attacker to analyze/debug?
There is some material on that, at least online. However, it is not
possible to make code so obscure that attacking it is anywhere near as
hard as breaking a reasonably good cipher, so hard-to-debug code can't
really be used to maintain levels of security comparable with what
could otherwise be achieved with cryptography.
One good method to make a program hard to analyze is to use "P-code",
interpreted instructions for a simulated computer. One has to first
disassemble the P-code interpreter before one knows what the P-code
means to disassemble it. Use two levels of P-code, and have the
program decrypt pieces of itself during execution, and this will help
to make things hard.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Another source of random numbers
Date: Fri, 04 Jun 1999 21:51:02 GMT
[EMAIL PROTECTED] wrote, in part:
>Is this idea widely known?
It is true that the digits of pi, for example, have the same
statistical properties as random digits. So, amateurs have suggested
using the digits of irrational numbers as encryption keys quite often.
Several things would be needed to make such a scheme work.
One needs a wide selection of irrational numbers to choose from. If
you are simply choosing from a list of, say, eight well-known
mathematical constants, then you really only have a key that is three
bits long!
And, while some irrational numbers can be calculated efficiently,
others are quite slow to calculate. Even the fast ones are slower to
calculate than digits generated by other techniques which would be
just as secure for cryptography.
But the digits of pi and so on do have one cryptographic use: they are
a good source for the contents of fixed S-boxes, for example. Thus,
Blowfish uses pi, and my Quadibloc uses Euler's constant.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/index.html
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Fri, 04 Jun 1999 22:10:02 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
(snip)
> I have been a programmer for over 30 years.
But this doesn't mean that you have 30 years of good experience. You could be
such a poor programmer that you have, eg, just 1 year of experience repeated
30 times. I stopped programming in 1974 ... perhaps you should have done the
same.
(snip)
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBN1hOSMo1RmX6QSF5AQEtRQf/a6YT7A1INO5ddlfcuXNYAggWC0EGbkHI
vWamys74slJZPMziqapTeza3FcGNnyOcd1ZAGUzAYt+wZQsJA4IDqTyIHNXRlFyG
gQdSRn2dSrk9NUaye7qvr+R4ixGA08csK2r9qf/lHq6u62HAYt3FmaA3cj7+vn1f
FR8dVJvhMwLSFxAtCwpAIcxz8PEthvt1JvfKu0mmuaOf7ki7O7AKKW2x+Dy1Djhr
1pHhPyez7dn5MStPjqfuCDcFaT4NTOB6VD2t5SIKhZlQDXY/+EE4z16np2G1spSa
CU7H1zE2TbP4R7YBQpR5TqwRmNT/tLJKuIkzrDkx8VNT+So8f6KPOw==
=IFBn
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
