Cryptography-Digest Digest #67, Volume #10       Tue, 17 Aug 99 22:13:03 EDT

Contents:
  Re: VEA - Video Encryption Algorithm (Tom St Denis)
  Re: encyrption ("First of One")
  Re: E2 (wtshaw)
  Re: crypto survey ("Douglas A. Gwyn")
  Re: encyrption (Tom St Denis)
  Re: Implementing Rijndael's S-box ("Douglas A. Gwyn")
  Re: encyrption (greg pruitt)
  Re: Blowfish algorithm - Is it foolproof? ("Tom Leylan")
  Re: Q.  a hash of a hash ... ("Brian McKeever")
  Re: encyrption (John Savard)
  Re: CRYPTO DESIGN MY VIEW (Nicol So)
  Relativistic Date Stamping (John Bailey)
  Re: NIST AES FInalists are.... (JPeschel)
  Re: Relativistic Date Stamping (David A Molnar)
  Re: Blowfish algorithm - Is it full proof? (Terry Carmen)
  Re: Do I have a problem with semantics? (Nicol So)
  Re: Please help a HS student with an independent study in crypto (David A Molnar)
  Re: frequency of prime numbers? ("karl malbrain")

----------------------------------------------------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: VEA - Video Encryption Algorithm
Date: Tue, 17 Aug 1999 22:00:33 GMT

In article <7pcd3p$fe2$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> 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.

That sums it up.  All it takes is one 'real' crypto guy to break the
entire system, for everyone!

Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2  Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: "First of One" <[EMAIL PROTECTED]>
Subject: Re: encyrption
Date: Tue, 17 Aug 1999 22:37:47 GMT

CAST was originally designed in Canada by C. Adams and S. Tavares. It's =
resistant to known cryptoanalysis, but then again, it's also a much =
newer algorithm than Triple-DES. As far as I know, CAST is an AES =
candidate, for the purpose of replacing DES in the future.

--=20
--
First of One, primary adjunctive grid Alpha-01, but you may call me =
First of One.

greg pruitt <[EMAIL PROTECTED]> wrote in message =
news:7pcg17$hq4$[EMAIL PROTECTED]...
> i've never heard of cast encryption before. is that stronger than
> triple des & idea has any of them been broken yet?
>=20
> --
> greg pruitt


------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: E2
Date: Tue, 17 Aug 1999 16:28:16 -0600

In article <7pamrr$ljk$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:

> Is anyone else disappointed that E2 was not chosen as an AES finalist?
> 
In the original presentation, don't know if she did Rome also, the
presenter certainly won in the cuteness category. 

The state of the art certainly includes and references all presented
designs.  Not winning in one contest is not the same as forever losing in
all. The future of crypto remains open to new, improved, and tweaked
algorithms and implementations. As we get a clearer and better idea of
what strength really means, we may wish to recycle some ideas in various
loser algorithms of one sort or another to produce something even much
better than any wearing a paper crown.
-- 
All's fair in love, war, and crypto.  ERACE

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: crypto survey
Date: Tue, 17 Aug 1999 21:53:46 GMT

Medical Electronics Lab wrote:
> ...  Unfortunatly again, it's pretty easy to prove that
> dictatorships are more stable and efficient [than] free
> economies.

No, that myth has long been dispelled.

------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: encyrption
Date: Tue, 17 Aug 1999 22:09:13 GMT

In article <7pcg17$hq4$[EMAIL PROTECTED]>,
  greg pruitt <[EMAIL PROTECTED]> wrote:
> i've never heard of cast encryption before. is that stronger than
> triple des & idea has any of them been broken yet?
>

In what sense are you looking?  Are you looking into 'if I encrypt
files with passwords' or 'hyrbrid cryptosystems'?

All of them are secure from a practical standpoint.  I would use CAST5
if you use any (128-bit key).  Avoid 3DES it's just slow and ugly.
IDEA is good and secure.

Basically good choices (or starting choices cuz it depends) for 64-bit
block ciphers are: CAST, IDEA, RC5 and Blowfish.  They have been around
for awhile and have not been strictly 'broken' to the point they are
not usefull (note: only RC5 with it's 'standard' 12 rounds can be
broken faster then exhaustive keysearch).

Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2  Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.research
Subject: Re: Implementing Rijndael's S-box
Date: 17 Aug 1999 21:58:18 -0000




"D. J. Bernstein" wrote:
> Anyway, I don't understand why NIST is worrying about the suitability
> of AES for tinkertoys.

It may be for a similar reason to the fellow who lost his car keys
down the block but was looking for them under the streetlamp.  Or
why some completely harmless gasses have emissions standards.  They
simply measure what they know how to measure.

------------------------------

From: [EMAIL PROTECTED] (greg pruitt)
Subject: Re: encyrption
Date: 17 Aug 1999 22:46:20 GMT

i'm glad to hear that because my public key uses cast encyrption.
greg pruitt

------------------------------

Reply-To: "Tom Leylan" <[EMAIL PROTECTED]>
From: "Tom Leylan" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it foolproof?
Date: Tue, 17 Aug 1999 19:30:19 -0400

Phil Barnett <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...

> Checksum the input. Store the checksum at the end of the input.
> Encrypt it.
>
> After decryption, strip the checksum and recalculate the checksum on
> what's left. If they match, it's likely the same. If you check sum it
> twice or more with different prime numbers, you are more likely to
> prove it's the same.
>
> It's not the encryption technique's job to make sure the output is the
> same as the input. Quite the opposite. If things don't go perfectly,
> it's the encryption techniques job to insure that the output looks
> nothing like the input.

That's good, I mentioned some sort of sentinal value as it just seems to be
necessary.  I don't mean to speak for the original poster (what happened to
him BTW) but I think he was worried about it "looking like the input" but
hey I could have it wrong.  I think he wanted it "right" or "totally bogus."

Tom




------------------------------

From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: Q.  a hash of a hash ...
Date: Tue, 17 Aug 1999 16:40:28 -0700

Anton Stiglic <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You should read his proof as follows:
>
> 1. First I proove that if I found a collision for H, I have one for H^2:
> (this is easy):   if I have x!= y and H(x) = H(y), then
>   of cours H(H(x)) = H(H(y)), and I have found
>   a colision for H^2.
>
> 2. Then I proove that if I found a collision for H^2, I have one for H:
>     if I have x!=y such that H(H(x)) = H(H(y)), then I have one
>     of two cases:
>           a:  H(x) = H(y):  in wich case I have a collison for H.
>           b:  H(x) != H(y):  in wich case I denote x' = H(x) and
>                 y' = H(y).   I can now say that y' != x' and H(x') =
H(y').
>
> So, to conclude, if I have a collison for H, I have one for H^2 (1),
> and, the other way around, if I have a collison for H^2 I have one
> for H (2).
>
> It is a simple and nice proof, it prooves that H and H^2 are equaly
> collision resistant.
>
> Anton

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."
Other than this, the proof allows you to say nothing about the number of
collisions.

Consider this:

Let H be some function H:S->S (where in general S has 2^128 or so elements).
Now H has no easily discernable mathematical structure (or else this could
be exploited), so let's just take it to be a random function.  Thus H(S)
(the image of S under H) is in general much smaller than S (I can't say how
small off the top of my head), and H(H(S)) is even smaller.  This is what
makes it easier to find collisions for H^2 than for H.

For example, take S={a,b,c}, H(a) = a, H(b) = a, H(c) = b.  H has only one
collision (H(a) = H(b)), but H^2 maps everything to a.

Brian




------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: encyrption
Date: Tue, 17 Aug 1999 23:46:48 GMT

greg pruitt <[EMAIL PROTECTED]> wrote, in part:

>i've never heard of cast encryption before. is that stronger than
>triple des & idea has any of them been broken yet?

CAST, like IDEA, is proprietary, while Triple-DES is free. There are
other algorithms available without charge, such as Blowfish, SAFER,
Twofish, and so on, that are alternatives to Triple-DES. Many are
listed in Applied Cryptography, others are among the AES candidates.

John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm

------------------------------

From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 17 Aug 1999 19:54:25 -0400

Douglas A. Gwyn wrote:
> 
> "SCOTT19U.ZIP_GUY" wrote:
> >  Actualluy huffman coding is a subset of arithmetic coding so the two are
> > very close. Actaully if the letter frequency appears as a power of .5 then
> > they are the same assuming the same values assigned to symbols.
> 
> Yes, but the fact is that most actual sources (of message text)
> don't have symbol probabilities that use all the available
> powers of 1/2.  For example, the frequency of the letter "E"
> (upper and lower case combined) in English documents is less
> than 1/8, yet Huffman coding would represent it with enough
> bits to cover a symbol that could occur with probability 1/2.
> That's why in general arithmetic coding can achieve better
> compression than Huffman encoding.

With Huffman coding, the best you can do with a high probability symbol
is to encode it with 1 bit.  Arithmetic coding has no such limitation. 
For a very skewed distribution with a high probability symbol,
arithmetic coding can be significantly better than Huffman coding.

Nicol

------------------------------

From: [EMAIL PROTECTED] (John Bailey)
Subject: Relativistic Date Stamping
Date: Tue, 17 Aug 1999 18:21:09 GMT

LONDON (Reuters) - A British mathematician has discovered a new
application for Albert Einstein's Theory of
Relativity -- cryptography.

Dr Adrian Kent, assistant director of research in the department of
Applied Mathematics and Theoretical Physics at the
University of Cambridge, has used Einstein's discovery that signals
cannot go faster than light to devise a new type of
code.

The new encryption allows an individual to make a prediction with a
guaranteed date stamp that only they can reveal.

Someone could use the code to predict something and unveil the message
after the event with proof that it was made
before it happened.

``We have learned in the last 15 years that quantum physics has
important applications in code-making, but this is the
first serious application of Einstein's relativity theory. It solves
what was up to now thought an impossible problem,''
Kent said in a statement.

``Other important problems in cryptography may well also be solvable
using the same techniques,'' he added.

Kent's research is published in the current issue of Physical Review
Letters, a journal of the American Physical
Society. 

Comment? Exegesis? Debunking?

John

------------------------------

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: NIST AES FInalists are....
Date: 18 Aug 1999 00:41:27 GMT

>"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:

>[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.

Doug, you started this security discussion here when you claimed esoteric
knowledge of the NSA that suggests its cryptanalysts are superior to
the AES cryptanalysts. You ought to not only continue the discussion here,
but offer some evidence. 

Joe


__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


------------------------------

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Relativistic Date Stamping
Date: 18 Aug 1999 00:36:43 GMT

John Bailey <[EMAIL PROTECTED]> wrote:

> Kent's research is published in the current issue of Physical Review
> Letters, a journal of the American Physical
> Society. 

Here's the abstract (the library "here" subscribes to the online version
of the journal) :

Adrian Kent
          Department of Applied Mathematics and Theoretical Physics,
          University of Cambridge, Silver Street, Cambridge CB3 9EW,
          United Kingdom

   (Received 13 July 1998)

   We describe a new classical bit commitment protocol based on
   cryptographic constraints imposed by special relativity. The protocol
   is unconditionally secure against classical or quantum attacks. It
   evades the no-go results of Mayers, Lo, and Chau by requiring from
   Alice a sequence of communications, including a postrevelation
   verification, each of which is guaranteed to be independent of its
   predecessor. �1999 The American Physical Society



If this holds up, then it will be very interesting to see whether it can
used in all the places we normally use bit commitment. Like, when quantum
bit commitment fell, I think it took a lot of other quantum protocols with
it since bit commitment is a primitive in zero-knowledge proofs and
secure multiparty computation. If we can get all that back w/o needing
cryptographic assumptions...well..cool!

 I'd also like to know just what kind of physical equipment I need to
carry this out. 8-)

-David




------------------------------

From: [EMAIL PROTECTED] (Terry Carmen)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Wed, 18 Aug 1999 00:15:39 GMT

On Mon, 16 Aug 1999 10:40:17 -0500, Pradeep Rathi
<[EMAIL PROTECTED]> wrote:

>Hi!
>
>I'm using the blowfish algorithm, written in perl, to encrypt a NUMERIC
>INTEGER VALUE. My concern is if I mess around with the encrypted
>information and then try to decrypt it, is there a possibility of another
>numeric value being returned. To illustarte,

Not only is there a possibility, there's a certainty.

For any given encrypted data, all attempted keys will produce some
output. Changing (damaging) the encrypted data, then decrypting with
the correct key will produce incorrect plaintext.

It sounds like what you want is encryption and validation, not just
encryption. You should calculate a checksum on the input and store it
with the plaintext before encrypting it. Then you can tell if the
decrypted text "correct" or not.

MD5 works nicely for that purpose.

Terry


------------------------------

From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Do I have a problem with semantics?
Date: Tue, 17 Aug 1999 20:49:03 -0400

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: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Please help a HS student with an independent study in crypto
Date: 18 Aug 1999 00:24:39 GMT

Jeff Moser <[EMAIL PROTECTED]> wrote:

> ElGammal, DH, etc] works, How [DES, RCx, AES submissions, etc] works, How
> signatures work, MAC/Hash, etc). What I want to focus on in the course is
> "Why" it works. I'd like to be able to write out proofs for why the methods

Try to get your hands on Neal Koblitz' book _A Course in Number Theory and
Cryptography_. It focuses on the number theoretic/algebraic aspects of the
field, and avoids bringing in much computational complexity, which you
probably don't have yet. As a bonus, it has a great introduction to modern
factoring methods and some elliptic curve crypto stuff. 

> work. I'd like to be able to, for example, show the mathematics of why the
> public key systems work [in depth of Euler Totient/Phi, Galois fields, other
> fields, etc].

It covers all of this. maybe not in incredible depth, but certainly enough
to prove why RSA works.

You might also check out the thread on "online tutorials" -- Helger Lipmaa
posted a URL to a site with lots of interesting stuff, including three
crypto tutorials (one in Polish, though). Of those, I like Oded
Goldreich's "Foundations of Modern Cryptography -- fragments of a book."

If you think of Koblitz as giving you the primitives and showing how they
work, then you can think of Goldreich as the owner's manual -- showing you
what to do with them once you've got 'em. but bad analogies aside, it
covers things like what "secure" really means, zero-knowledge proofs, and
what "pseudo-randomness" means. 

-David Molnar

------------------------------

Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: frequency of prime numbers?
Date: Tue, 17 Aug 1999 18:48:58 -0700


Guenther Brunthaler <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 10 Aug 1999 17:50:00 -0700, "karl malbrain" <[EMAIL PROTECTED]>
> wrote:
>
> >As Bob S has illustrated, you have to take BOTH sides of this
contradiction
> >at ONCE:  P is also provably COMPOSITE (because it's not in the list),
hence
> >a contradiction with your proof that P is PRIME.  Karl M
>
> No, it means that P cannot be prime, but it must. This contradiction
> cannot be resolved if N exists.
>
> Therefore N cannot exist, and so there must be an infinite number of
> prime numbers.

That's a different question beyond the nature of DIALECTICAL contradiction
that belongs to the singularity: does not exist (for you, exists always out
to infinity, for me).  I don't find singularities particularly useful.  Karl
M



------------------------------


** 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
******************************

Reply via email to