Cryptography-Digest Digest #68, Volume #10 Wed, 18 Aug 99 05:13:05 EDT
Contents:
All or Nothing (Thinker)
How to Authenticate server identity (yoni)
Re: Cracking the Scott cryptosystems? (SCOTT19U.ZIP_GUY)
Re: Q. a hash of a hash ... ([EMAIL PROTECTED])
Re: Do I have a problem with semantics? ("rosi")
Re: Q. a hash of a hash ... ([EMAIL PROTECTED])
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: compress then encrypt? (SCOTT19U.ZIP_GUY)
Re: Relativistic Date Stamping ("Douglas A. Gwyn")
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: Digital simulation (wtshaw)
Re: NIST AES FInalists are.... ("Douglas A. Gwyn")
Re: Relativistic Date Stamping (David A Molnar)
Re: VEA - Video Encryption Algorithm (Stefan Lucks)
----------------------------------------------------------------------------
From: Thinker <[EMAIL PROTECTED]>
Subject: All or Nothing
Date: Mon, 16 Aug 1999 18:07:00 -0700
Can anyone tell me where i could find detailed source code, or at least
a good description, of Ronald Rivest's All or Nothing Message hashing?
I'm looking for code more than anything else b/c i plan to be utilizing
this in a program later on.
--Thinker
Ummm... feel free to reply to me personally as i don't know whether or
not i'll be able to check this newsgroup often.
------------------------------
Date: Mon, 16 Aug 1999 12:40:04 +0200
From: yoni <[EMAIL PROTECTED]>
Subject: How to Authenticate server identity
I try to think how can I verify a response came from a certain trusted
server. I have a basic problem - I need to use keys (public, private)
but those should be kept on the client disk and therefore can be stolen
and used for impersonating. Even the Kerberose protocol can fail if the
key is stolen.
Is there a different way if I know the server is trusted and cannot be
accessed by unauthorized users ?
Is there a safe way to save keys on file ?
I'm a begginner in this field so maybe I miss the main point.
Thank you,
Yoni.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Cracking the Scott cryptosystems?
Date: Wed, 18 Aug 1999 04:34:09 GMT
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>
>Let's go further and reduce the size of the s-box to SCOTT8 or even
>SCOTT16 and fix the blocksize to 64 or 128 bit.
>
>In this case it doesn't look like a strong cipher: At least SCOTT8 would
>produce lots of weak s-boxes and you would have to use a huge number of
>wraps to get something as strong as the commonly used blockciphers.
>
IF youi want to look at a small version. It was meant to be a tool but
scott4u.zip Is the system shrink down to a 4 bit block with only 16 entries.
This is the size that gives 40 bits for the key so it is kind of a joke.
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]
Subject: Re: Q. a hash of a hash ...
Date: Wed, 18 Aug 1999 02:52:27 GMT
John Myre <[EMAIL PROTECTED]> wrote:
> The proof below is not valid (reasoning follows):
>
> Anton Stiglic wrote:
[...]
> > It is a simple and nice proof, it prooves that H and H^2 are equaly
> > collision resistant.
> Consider, for example, H(x) defined as, say, shifting right by one bit
> (and so discarding the low order bit). Now H(x) = H(y) means that x
> and y are the same except (perhaps) for their low order bit. But
> H(H(x)) = H(H(y)) even when x and y differ in *two* bits. In other
> words, H^2 plainly has *more* collisions than H.
>
> The problem with the proof is that although H^2 only has collisions
> due to H, it does not necessarily have the same number of them.
I have to disagree. The collision resistance I know
of doesn't refer to the number of collisions, but to
the difficulty of finding them. Your pair of H and
H^2 is not a counterexample, since their degree of
collision resistance is tied at diddly-squat.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: Do I have a problem with semantics?
Date: Tue, 17 Aug 1999 23:06:45 -0400
Dear Nicol,
Thanks for the response. Think I can have a simple answer but not
too sure if it be long. This is perhaps the exact point: mathematical
fact. And one thing I did not miss in my guess is this one. I thought it
would be around fact, conjecture, or assumption. Let me go an (kind of)
indirect route: If a mf, first (sorry to be a bit picky) it runs against
your
definition of 'provably secure' in some sense. There is nothing to prove,
for one; there is no conjecture the prove depends on, for another. So I
may appear to be twisting things by asking, what is this 'provably secure'
again? Then if we say it is the process that can be proven to be secure,
then there is a bit 'semantics'. The '4-5' should not be in the picture as
you never need to prove that. But let me have my reservations about the
'4-5'. Secondly, without quantumn we have (kind of) quantumn (remember
your own words MF, i.e. no assumption)? I can say I believe it, but do you
think that is too much against intuition? Thirdly, assume the def. for 'ps'
does not change, where is the conjecture (for the proof of the process/
protocol)? Please do not think I want an argument for its own sake. Do I
have it that you did read Paper?
Back in original focus: It is NOT whether from 4-5 one can get to 5-5.
It is: how do you get this 4-5 in the VERY FIRST PLACE? and guarantee
it? Please consider a concrete example at the point you can 'almost'
guarantee it. I think I gave a hint: ask the author(s) how the bits were
obtained. What do you think they were obtained? I sense I have a high
probability of guessing (i.e. your answer(s)) right.
I do not want to miss this: I CAN be wrong.
Thanks (pressed for time, will be more concrete if you do not see it).
--- (My Signature)
P.S.
I would like to once again express my gratitude for your comments both
here and elsewhere, including the thread in which NPh was looked at. I
saw your independent thinking which is very precious to me. You saw
Turing-reducible and brought our attention to many-one reduction. Be
either or both right or wrong, be they different or the same, it does not
change the real thing: TRUTH. But we need independent thinking,
the courage to bring our views, new ideas, etc. We do not have to be
always right. But we can certainly afford to not always follow suite.
Thanks.
Nicol So wrote in message <[EMAIL PROTECTED]>...
>rosi wrote:
>>
>> The second is the question asking for the assumption(s) that I feel
>> missing in Paper. This I think is obvious if you read Paper and give
>> the concept a bit more thought. I would like to refer to something you
>> said that I believe says more or less the exact thing: the not explicitly
>> stated assumption (NOT conjecture). Your words:
>>
>> 5 unknowns but 4 equations
>>
>> You also said, I am aware, that it is 'loose', but I am not picky.
However,
>> it is exactly the place we can not afford to be loose. The simple
question
>> to put this in focus is: How come that the fifth equation can not be
>> obtained? Is this a conjecture? Is this an assumption? What do you think
>> about this assumption? Hint for your reading of Paper: how reasonable
>> is the assumption if it be one?
>
>The reason you cannot narrow down the solution set to a unique
>combination of 5 values is because you don't have enough constraints.
>Assuming that the system of equations is not degenerate, there are
>infinitely many combinations of 5 values that satisfy the 4 equations.
>In order to narrow the solution set down to a unique combination of
>values for the unknowns, you need additional constraint(s). In linear
>systems, that means additional equation(s).
>
>Consider this: I tell you that I have a number in mind which happens to
>be the y-intercept of a straight line passing through the point (1,1).
>Can you figure out what the number is?
>
>You can't, because there are infinitely many numbers consistent with my
>description. You need additional constraint(s), which you don't have.
>No amount of computation can overcome the under-specification.
>
>The above is not a conjecture, nor is it an assumption. If I need to
>give it a label, I'll just call it a simple mathematical fact.
>
>Nicol
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Q. a hash of a hash ...
Date: Wed, 18 Aug 1999 03:43:12 GMT
Brian McKeever wrote:
> Anton Stiglic wrote:
> > It is a simple and nice proof, it prooves that H and H^2 are equaly
> > collision resistant.
> You've drawn the wrong conclusion from the proof.
> The only valid conclusion one can draw is "H is
> collision-free if and only if H^2 is collision-free."
I think that's equivalent to the conclusion he did
draw. According to Menezes, van Oorshot and Vanstone,
/Handbook of Applied Cryptography/,
Collision resistance - it is computationally infeasible
to find any two distinct inputs x, x' which hash to the
same output
"Collision resistant" and "collision free" are synonyms.
The former is gaining favor, since "free" suggest
nonexistence, rather than inability to locate. I think
"Collision free" will live on since it looks better in
research paper titles of the form "Function x is not
collision free".
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Wed, 18 Aug 1999 04:07:13 GMT
JPeschel wrote:
> but offer some evidence.
Frankly, it's not at all clear what you would find
persuasive that I am at liberty to offer. You might
draw your own conclusions from the combination of
already available evidence such as my employer,
location, recent research (previously mentioned here),
and accurate transcription of the Kryptos sculpture.
Or you could judge whether I would lie on the basis
of my reputation; I've been active in Usenet and
precursor ARPAnet/Internet mailing lists since the
early 1980s, so there should be plenty of data.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: compress then encrypt?
Date: Wed, 18 Aug 1999 04:27:23 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> ... I really can't understand why finding such routines is hard.
>> I suspect it is becasue the NSA which is so interested in reading
>> everyines mail. Has kept the open crypto people away form such
>> pursits since it would be of a great aid as a first step before
>> encypting. ...
>
>I think we don't need a consipracy to explain this.
>First of all, there *are* some implementations of other
>lossless compression methods; witness a Web site I
>mentioned in another thread.
>Secondly, for the most part the compression step can
>be performed *independently* of the mix-it-up encryption
>algorithm, so people studying the latter don't need to
>concern themselves with the former.
I agree it can and shoulf be done seperately form the encryption.
But it is part of keepin crypto secure. Ans most lossless compression
systmes have not been designed to be of a form that is good to encrypt.
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: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Relativistic Date Stamping
Date: Wed, 18 Aug 1999 04:12:03 GMT
John Bailey wrote:
> ``... this is the first serious application of Einstein's relativity
> theory.''
That's pretty funny!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Wed, 18 Aug 1999 04:46:41 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>> >SCOTT19U.ZIP_GUY wrote:
>> >>
>> >
>> >> >I don't see how you requirement can be realized. If you have a file
>> >> >A compressed to B and the last symbol written to B consists of, say,
>> >> >4 bits. If I delete the last bit of B to become C, then on
>> >> >uncompressing C the software will find the last 3 bits of C that it
>> >> >can't decode. So this 'wrong' file C obvioulsy will be determined
>> >> >to be an invalid file. Or do I miss something?
>> >
>> >>
>> >> AS usual you don't understand and I am not sure that I can help you
>> >> I don't want to go on forever with you like I have in the past.
>> >> But TAKE A LOOK AT THE CODE. YOU HAVE THE PROGRAM.
>> >> That said lets see if I can help. The files invovled are all wirtten
>> >> in a whole number of bytes. So you can't delete "one bit".
>> >
>> >It is only a matter of scale. If the constraint is that the file is to
>> >be in whole numbers of bytes (indeed quite reasonable in practice),
>> >I can consider the case where the last byte is deleted. Avoiding
>> >also to discuss the end filling problem, let's assume that the last
>> >symbol output has 9 bits and that the last bit is at byte boundary.
>> >Now on uncompressing the program will find at the end of the 'wrong'
>> >file one bit that it can't decode, there being 8 deleted bits
>> >missing. (Isn't this a good example?)
>> >
>> >M. K. Shen
>>
>> Look at my code and you will see how this is handled. You can hand code you
>> examples and watch to see what happens. Trust me the code handles it.
>>
>> http://members.xoom.com/ecil/compress.htm
>
>Your codes are difficult to read, being poorly commented. Would you
>please give a few lines of pseudo-code or just plain Englich of
>how the software, when encountering the 1 bit said above, react?
>I certainly can hand code if you give sufficient information on that
>point. (Note, for example, Knuth in his book doesn't give C code,
>but anyone reading his text can code the algorithms he described.
>Please be good engough to do similarly. My experience of reading
>your code is unfortunately such that I am unable to extract the
>algorithm from your code. Sorry for that.)
>
>M. K. Shen
I don't write well and I think the code speaks for itself. I mean your
can test it and look at a series of dumps. But basically it some times
does not write out the last bits and the decompression routine knows what
the droped bits are. But some times it adds extra bits to pad the byte out
when its is short. But the fact that I limit the 1's to a max of 8 in huffman
tables and the all 0's to a min of 8. But I feel the C code is more important
than any explaintion on my part. I mean look you have the executable
like I said at the start of this thread we have gone round and round on
scotti6u. Since you said you would write it up. You never did. I get tired
of wirting to you when is goes no where. If you see an example on my
webpage that confuses you. I will give words as to what it did in that case.
But there would be more errors in a total explaintion of every possilbe case.
But if you see one that confuses you tell me and I we attempt to give
a verbal explantion.
http://members.xoom/ecil/compress.htm
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] (wtshaw)
Subject: Re: Digital simulation
Date: Mon, 16 Aug 1999 21:30:09 -0600
In article <7p2390$hju$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> Christy Fulcher <[EMAIL PROTECTED]> wrote:
> > Im am looking for a way to simulate an encryption algorithm in
> > electronic workbench
> > (or similar), for a project in electronics. My knowledge so far
> consists
> > of simple
> > circuits like and, not, xor etc. Could anyone help me in suggesting an
> > algorithm that can
> > be implemented using these tools.
...
>
> If you truly are into electronics you should note any cipher or program
> can be done with XOR/AND gates ...
The question is of simplicity. I suggest that many of the standard digital
circuits are useful, made up of complex arrays of simple gates. Such
things are what I did for years, to make control circuits which were
immune to noise, recognized only their counterparts at the other ends of
the link(s), were difficult to spoof, and dependable.
In standalone systems, you start with basic communications lock. It
matters greatly where you want to start, as you could run digital to
digital without an analog interface for a short distance, with one, for
many miles on your system wires alone.
If you are running through a computer, get a simple comlock with the
system first. Choose wisely and simply. Basic non-encryptive
functionality is always first.
>
> BTW, why did you post 4 times?
>
My count is seven.
--
All's fair in love, war, and crypto. ERACE
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST AES FInalists are....
Date: Tue, 17 Aug 1999 04:02:41 GMT
[EMAIL PROTECTED] wrote:
> Do they send you a memo or what?
If you want to discuss security issues, there are appropriate
channels for that, and Usenet is definitely *not* one of them.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Relativistic Date Stamping
Date: 18 Aug 1999 07:36:23 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> John Bailey wrote:
>> ``... this is the first serious application of Einstein's relativity
>> theory.''
> That's pretty funny!
Fortunately the paper seems to be much less nutty than the news article.
(I didn't download a copy from the online journal, and if you want a copy
then don't e-mail me. actually, it's probably on the author's web page or
in a physics preprint archive somewhere, haven't checked)
More on that later after I read (vs. skim) the thing, although I doubt
I'll catch any subtle errors in physics.
-David
------------------------------
From: Stefan Lucks <[EMAIL PROTECTED]>
Subject: Re: VEA - Video Encryption Algorithm
Date: Wed, 18 Aug 1999 10:17:27 +0200
> Here's a link to a description of VEA, an encryption algorithm designed
> to work within the MPEG compression/decompression process. It is noted
> in the text that it is not very secure against real cryptographers,
> however it can be useful for privacy and securing pay-per-view.
>
> http://www.acm.org/sigmm/MM98/electronic_proceedings/shi/
I had a look at that paper some time ago, and was quite disappointed (to
say the least):
First, the kind of cipher the authors have "invented" is well known for
decades: It is just a one-loop Vernam cipher. Specifically, it is using
the binary alphabet {0,1} instead of {a,...,z} as it was usual in the
times of Vernam. The (seemingly) new idea is to encrypt the "most
important" (my words) bits of a video stream, such that when these bits
are missing, the whole stream is completely corrupted.
The authors compare the performance of their cipher with the performance
of DES, while comparing it with a modern stream cipher would be more
appropriate.
If you can find any bias in the encrypted bits, or a linear relationship
with a small bias (I am sure, such a bias can be found in MPEG video
streams) it is trivial to find at least some the key bits.
One BIG drawback of the cipher is that as the adversary learns more and
more key bits, the stream becomes less and less corrupted.
Thus, you don't need a good cryptographer to break VEA.
Further, in the paper, you find funny nonsense like
Previous studies of cryptography have focused on text data. The
encryption algorithms developed to secure text data, such as DES
DES [Stin] and RSA [Stin], ...
In the reference given, the textbook of Stinson [Stin], I cannot find
any section which would support the above.
[Stin] Douglas R. Stinson, "Cryptography Theory and Practice." CRC
Press, Inc., New York, 1995.
For what is the VEA good?
"... useful for privacy"? Perhaps to keep out your kid sister.
"... and securing pay-per-view"? The whole pirate scene must be rolling on
the floor and laughing out loud.
Perhaps, it would be a nice student homework to attack this cipher ...
CONCLUSION: Forget VEA -- it is snake oil.
--
Stefan Lucks Th. Informatik, Univ. Mannheim, 68131 Mannheim, A5, Germany
e-mail: [EMAIL PROTECTED]
home: http://th.informatik.uni-mannheim.de/m/lucks/
===== Wer einem Computer Unsinn erzaehlt, muss immer damit rechnen. =====
------------------------------
** 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
******************************
