Cryptography-Digest Digest #715, Volume #12      Tue, 19 Sep 00 08:13:01 EDT

Contents:
  Simple hash function ("dexMilano")
  Stream cipher ([EMAIL PROTECTED])
  Re: [Q] Design criteria for sboxes in Tiger/192 ? (Ross Anderson)
  Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an  (Mok-Kong Shen)
  Re: Simple hash function (David Blackman)
  Re: Optimization for speed question. (Christian Bau)
  Re: Simple hash function ("dexMilano")
  Re: Intel's 1.13 MHZ chip (Robert Stonehouse)
  Re: Simple hash function (Anders Thulin)
  Re: Lossless compression defeats watermarks (Ross Anderson)
  Re: Chosen and known attacks - are they possible ?? (Guy Macon)
  Re: "Secrets and Lies" at 50% off (Felix von Leitner)
  Re: Double Encryption Illegal? (Guy Macon)
  Re: QUESTION ABOUT ALGORITHMS (Runu Knips)
  Re: Weak keys in RC4 (Guy Macon)
  Re: Stream cipher (Runu Knips)
  Re: Simple hash function (Runu Knips)
  Re: Q: Crypto-PC (Runu Knips)
  Re: Software patents are evil. (Runu Knips)

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

From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Simple hash function
Date: Tue, 19 Sep 2000 10:13:02 +0200

I'm loloking a very simple/fast hash function to identify if a record in a
table has been modified since last check.

I've seen standard hash but they'r too heavy to execute in a demon process
(that works in background with a low CPU consumption).

I've not problem of protection/integrity because all changes should be safe,
it's just a way to understand if the record has been modified by another
application.

Any suggestion will be welcome

dex



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

From: [EMAIL PROTECTED]
Subject: Stream cipher
Date: 19 Sep 2000 08:42:16 GMT

I work for a company which is developing a conditional access system for
the European digital audio broadcast project and I am trying to implement
a stream cipher with low resource requirements and (guess what) good
cryptographical properties, i.e. it should be small and secure. The data
to be encrypted is mostly binary (audio streams). Furthermore, the
encryption algorithm should be free and not patented (no RC4 or SEAL or
Shareware). Currently, the whole system is being implemented in software,
but plans exist to realize it in hardware.
Can anyone recommend a suitable algorithm? In AC of Schneier resp. HAC
of Menezes a few generators based on LFSRs are mentioned, e.g. such as
the shrinking / self-shrinking generator, the alternating step generator
or the knapsack alg., but only little information about their security
is given (mostly because they were too new at that time). I don't know 
if there have been any successful (practical) attacks against on these
algorithms, but maybe someone can supply me with more up-to-date
information than that stated in the books (or other algorithms I don't
know about yet).

Thanks,
Andi
 

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

From: [EMAIL PROTECTED] (Ross Anderson)
Subject: Re: [Q] Design criteria for sboxes in Tiger/192 ?
Date: 19 Sep 2000 08:46:47 GMT

In article <[EMAIL PROTECTED]>,  Runu Knips 
<[EMAIL PROTECTED]> writes:

>It also has a nice paper which describes almost
>everything except the design of the Sboxes. Does
>anyone have any information (or an idea) how they
>have been constructed ?

For how we designed the Tiger S-boxes, see the `S-box
generation documents' at:

http://www.cl.cam.ac.uk/users/rja14/#Cryptanalysis

Ross

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an 
Date: Tue, 19 Sep 2000 11:08:08 +0200



Kostadin Bajalcaliev wrote:
> 
[snip]
> Main question is what is the essence of security, how to define and name
> that phantom substance the designers put in their work. And make the rest of
> us to wander how a simple design as RC5 or Blowfish can be secure on one
> side. On other the homemade cipher having kilometers (or miles if you
> prefer) of code and complicated mathematical theory behind may serve just as
> scholar example of weak design.

We have indeed discussed long ago that there is no
rigorous and practically applicable scientific unit
for measuring the strength of an encryption algorithm 
like second, Newton etc. The security of applying
an algorithm depends on the environment and the
user's evaluation of the security can at best be
a more or less subjective value. One never knows
whether the best esteemed cipher will not be easily
broken by a new method in the future, nor even that 
it has not already been broken by some secret agency. 
The majority of ciphers don't have good and complete 
documentation and almost invariantly contain constants 
that a third party has no information to reproduce. 
Thus even the question of presence of backdoors 
cannot be definitely answered. So was DES, and so 
will also AES, very deplorably, be. Therefore one 
should always make some intelligent choice of the 
encryption algorithms to be used and must in 
particular be well conscious that one is oneself 
(alone and nobody else) responsible for the decision 
in making that choice. Past discussions in the group 
pointed out that multiple encryption with different 
algorithms could be one of the viable possiblities 
that deserve one's consideration in case no single 
available algorithm seems to be entirely satisfactory 
according to one's own (subjective) evaluation.

> I have no intention to play the role of neither Aristotle, nor I thing to
> have King Solomon power of judgement. But I am trying to answer that simple
> question. What make the cipher secure? Even I have included my own design in
> the thesis as an example it is not my intention to convince you that I have
> invented the best cipher ever since. On the contrary other design clearly
> named in the thesis already having the label 'secure' contain a realization
> of the theory discussed.
> 
> I hope you will find a little time to read my thesis, it is not the regular
> amateur-eureka-work.

I'll read your work. But I am quite sure even now that 
the above given question of what makes ciphers secure 
can't have any absolutely satisfactory answer, for the 
simple reason that there exists no rigouros measure of 
security of encryption algorithms as explained above.

M. K. Shen
======================
http://home.t-online.de/home/mok-kong.shen

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

From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: Simple hash function
Date: Tue, 19 Sep 2000 20:09:50 +1100

dexMilano wrote:
> 
> I'm loloking a very simple/fast hash function to identify if a record in a
> table has been modified since last check.
> 
> I've seen standard hash but they'r too heavy to execute in a demon process
> (that works in background with a low CPU consumption).
> 
> I've not problem of protection/integrity because all changes should be safe,
> it's just a way to understand if the record has been modified by another
> application.
> 
> Any suggestion will be welcome
> 
> dex

Adler32 is about as light as they get. It's only 32 bits, but that's
enough for some applications. You can find it buried in the source code
to zlib, see
http://gailly.net/index.html#zlib
Also described in one of RFC 1950 or 1951, i forget which.

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

From: [EMAIL PROTECTED] (Christian Bau)
Crossposted-To: comp.lang.c
Subject: Re: Optimization for speed question.
Date: Tue, 19 Sep 2000 10:56:02 +0100

In article <G7vx5.3241$[EMAIL PROTECTED]>, "Tor Rustad"
<[EMAIL PROTECTED]> wrote:

> The error probability of Miller-Rabin is easy to control, to me proving
> something on a computer beond a 2^{-80} error probability does not make the
> proof better.
> 
> For sake of argument, let us increase the security margin to 2^{-160}.
Then if a
> provable prime algorithm gives a different result than Miller-Rabin did, which
> method is right?
> 
> My bet would be the algorithm which used the less CPU time...

So why did anybody bother proving Fourier's Last Theorem, when it was
known for some time that a^n + b^n = c^n has no solutions in positive
integers a, b and c for 2 < n < 125000, so the chances of finding a
counter example were about 1 in 10^(-300000) ?

Why does anybody try to prove the Goldbach hypothesis, which is known to
be true with a margin of error < 10^(-1000000) ?

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

From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Re: Simple hash function
Date: Tue, 19 Sep 2000 11:55:47 +0200

thx for suggestion.
I'll look for it.

dex

"David Blackman" <[EMAIL PROTECTED]> ha scritto nel messaggio
news:[EMAIL PROTECTED]...
> dexMilano wrote:
> >
> > I'm loloking a very simple/fast hash function to identify if a record in
a
> > table has been modified since last check.
> >
> > I've seen standard hash but they'r too heavy to execute in a demon
process
> > (that works in background with a low CPU consumption).
> >
> > I've not problem of protection/integrity because all changes should be
safe,
> > it's just a way to understand if the record has been modified by another
> > application.
> >
> > Any suggestion will be welcome
> >
> > dex
>
> Adler32 is about as light as they get. It's only 32 bits, but that's
> enough for some applications. You can find it buried in the source code
> to zlib, see
> http://gailly.net/index.html#zlib
> Also described in one of RFC 1950 or 1951, i forget which.



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

From: [EMAIL PROTECTED] (Robert Stonehouse)
Subject: Re: Intel's 1.13 MHZ chip
Date: Mon, 18 Sep 2000 10:14:58 GMT

"Abyssmal_Unit_#3" <[EMAIL PROTECTED]> wrote:
>thanks for tip of History @ IEEE
>
>yes, we had an early line printer that was a band or chain type. was quite rapid at 
>spewing paper and was dangerous to listen to
>when the protective acoustic cover was removed for maintenance.

The cover was not just acoustic. If the chain broke, the letters
came out like bullets.
[EMAIL PROTECTED]

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

From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Simple hash function
Date: Tue, 19 Sep 2000 10:25:45 GMT

dexMilano wrote:

> I'm loloking a very simple/fast hash function to identify if a record in a
> table has been modified since last check.

  Hash functions are practically always approximate -- that is, you just might
get a false positive or negative. If that's OK, fine.  If it isn't, it
seems easier to increment a counter in the record when it is changed, and to
clear it when the check is made -- that would also allow you to detect the number
of times the record has changed since the last check. 

-- 
Anders Thulin     [EMAIL PROTECTED]     040-10 50 63
Telia Prosoft AB,   Box 85,   S-201 20 Malmö,   Sweden

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

From: [EMAIL PROTECTED] (Ross Anderson)
Subject: Re: Lossless compression defeats watermarks
Date: 19 Sep 2000 10:35:24 GMT

In article <8ps1ov$rt4$[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Matthew Skala) writes:

>If a watermarking scheme works perfectly (in the sense of being
>inmperceptible by humans) and a lossy compression scheme works perfectly
>(in the sense of maximizing compression without harming perceptual
>quality) then compressing and decompressing a signal will have the effect
>of removing the watermark.

Fabien Petitcolas and I pointed this out in `On the limits of steganography',
IEEE Journal on Selected Areas in Communications (J-SAC) vol. 16 no. 4, pp 
474-481: http://www.cl.cam.ac.uk/~fapp2/papers/jsac98-limsteg/ section IV C
- though I think the term to use is `perfect compression' rather than
`lossless compression' (the latter is usually taken to mean that a perfect
copy of the original input can be reconstructed algorithmically)

>Going in the other direction, if you have a watermarking scheme that
>survives lossy compression, then that implies some deficiency in either
>the watermarking scheme or the lossy compression or both: either the
>watermark is altering the perceptible part of the signal, or the lossy
>compression is transmitting some imperceptible information.

Exactly so,

Ross

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

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Chosen and known attacks - are they possible ??
Date: 19 Sep 2000 10:49:13 GMT

Bryan Olson wrote:
>
>
>"kihdip" asked:
>
>> The models are frequently used to describe an attack form:
>> - Ciphertext only
>> - Known plaintext
>> - Chosen plaintext
>> - Chosen ciphertext
>>
>> Forgive my ignorance, but are the known and chosen attacks
>> only teoretical ?? If not: How would an attacker get a
>> chosen plaintext encrypted ?? (His goal is to find the key,
>> so obviously he cannot encrypt the plaintext himself)
>
>Even the most theoretical-sounding actually happens.
>Consider a subscription satellite-TV service.  The content
>is sent encrypted, and each subscriber has a
>tamper-resistant box that decrypts it.  Now suppose a pirate
>wants to make working decryption devices.  He can subscribe
>to get a box, then introduce his own data and see what comes
>out - the chosen ciphertext attack.

That sounds like a chosen plaintext attack to me.


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

From: Felix von Leitner <[EMAIL PROTECTED]>
Crossposted-To: comp.security,comp.security.misc
Subject: Re: "Secrets and Lies" at 50% off
Date: Tue, 19 Sep 2000 10:40:47 GMT

> But... exactly WHAT is the purpose of this group?

It's called sci.crypt.
So it's about the science of cryptography.

Bruce's book is probably very good and very important to read but it is,
if I understood him correctly, expressly not about cryptography.

So I suggest he should limit his advertisements to crypto-gram, his
mailing-list.

Felix


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

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Double Encryption Illegal?
Date: 19 Sep 2000 10:53:02 GMT

root@localhost <[EMAIL PROTECTED]> wrote:
>
>He said that applying Ceaser cipher twice does not enhance security.  He
>was correct in that statement.  

You mean I shouldn't be applying ROT-13 twice?  Several experts have
told me that applying ROT-13 twice is *so* secure that an attacker
with infinite resourses can't even tell what algorithm I used...


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

Date: Tue, 19 Sep 2000 13:24:44 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: QUESTION ABOUT ALGORITHMS

Terry Ritter wrote:
> >Fortunately I neither live in USA nor need your patents.
> >As I've already stated in my original posting :-)
> 
> As far as I am aware the European patents for the IDEA cipher do in
> fact cover software implementations.

Yep, but I talked about YOUR patents.

Too, I don't need IDEA, I prefer Blowfish ;-)

Well, at least the IDEA patent covers a reasonable
amount of research, it is really a nifty piece of
code, and AFAIK they allow implementations in OSS
without licensing.

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

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Weak keys in RC4
Date: 19 Sep 2000 11:30:14 GMT


Patrick Schultz wrote:
>
>I have seen it said several times that good implementations of RC4
>discard the first 512 bytes generated.  How does this compare with the
>proposal for ciphersaber-2, that you run the entire state array mixing
>loop multiple times?  Are these two techniques both even addressing the
>same problem?  If they are, are there advantages/disadvantages to using
>either one?  The link for the ciphersaber faq, if anyone would like to
>see it, is http://ciphersaber.gurus.com/faq.html.

Ciphersaber-1 imperfectly addresses the problem by limiting the key
to less than 54 bytes.  Assuming an ASCII key and plaintext, there
is 1 chance in 1134 that the second character only of the plaintext
will be unaltered with a 41 byte key, 1 chance in 539 with a 54 byte
key, and 1 chance in 209 with a 74 byte key (which is why ciphersaber
limits the key to 54 bytes)  If the second character of the plaintext
has no information (is fixed or random), then this information leak
is of no use to an attacker.  Cyphersaber-2 has no such weakness.

There is a method of achieving the desired result and still be readable
with ciphersaber-1, which cannot decrypt Ciphersaber-2 cihertext.

Adding a random number of random characters to the beginning and
end of the plaintext before feeding it to ciphersaber does the
trick, and also addresses some other potential shortcomings of
Ciphersaber-1.  If the decrypted plaintext is to be read by a
machine you need some sort of begin of file and end of file
identification, but if it's for a human to read, you can skip
that - the human eye is very good at finding where the nonesense
stops and the message begins.



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

Date: Tue, 19 Sep 2000 13:33:52 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Stream cipher

[EMAIL PROTECTED] wrote:
> I am trying to implement a stream cipher with low resource requirements
> [...] the encryption algorithm should be free and not patented (no RC4
> or SEAL or Shareware).

RSADSI has a trademark and trade secret "RC4". Because the algorithm has
been published anonymously  1994 in this newsgroup, it isn't a secret
anymore. Everyone can use it freely IF AND ONLY IF one calls it
"Arcfour"
instead of "RC4", because RSADSI still has the trademark on "RC4".

> Currently, the whole system is being implemented in software,
> but plans exist to realize it in hardware.

Arcfour isn't designed for hardware implementations.

The best cipher for these requirements would be AFAIK Serpent, which is
not too fast in software, but really fast and easy to implement in
hardware, but it is a block, not a stream cipher.

Well, I'm very curious if something knows something better :-)

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

Date: Tue, 19 Sep 2000 13:42:12 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Simple hash function

Anders Thulin wrote:
> dexMilano wrote:
> > I'm loloking a very simple/fast hash function to identify if a record in a
> > table has been modified since last check.
> 
>   Hash functions are practically always approximate -- that is, you just might
> get a false positive or negative. If that's OK, fine.  If it isn't, it
> seems easier to increment a counter in the record when it is changed, and to
> clear it when the check is made -- that would also allow you to detect the number
> of times the record has changed since the last check.

Hmm but if we have some, say, good 128 bit long checksum (not really
a cryptographic hash of course) of the record, the chance that the
record keeps the same checksum after a modification is 1:2**128,
which is "never" in practice, while a single program which forgets
to increment the counter will modify the records without notice.

The best solution would be, of course, if there would be a version
management in the database itself, so we just have to check if the
version hasn't changed.

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

Date: Tue, 19 Sep 2000 13:47:29 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Q: Crypto-PC

David Hopwood wrote:
> Since writing a truly secure operating system is beyond the current state
> of the art (and apart from a few interesting research projects like Eros
> <www.eros-os.org>, no one is even trying to change that), I'm highly
> skeptical that approaches like Crypto-PC will make any real difference.

I might be totally wrong, but AFAIK the most secure OS is OpenBSD ?
Even if I would immediately know what security features I would like
to add to it, see the linux kernel patches on www.openwall.org.

Too, you argue about keyboard and monitor: how can ANY OS change
their behavior ?!?!? It is a question of the hardware, not the
software, isn't it ?

But thank your for that link. Another interesting OS project ! :-)

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

Date: Tue, 19 Sep 2000 14:04:58 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.

Bill Unruh wrote:
> The courts do not grant patents. The patent office does. The courts can
> decide if a patent is valid. If you can show that the patent is
> "patenting math" then the courts will find it invalid.

Well consider the patent on rotation. A japanese company recently
claimed that most of the AES finalist violate their patent. So
what is their patent ? Using rotation in encryption !!!!!!!

Not to note that using rotation is the oldest concept of
encryption, even the first of all ciphers, the caesar one, was
a rotation in 26 alphabetic characters, this patent was also given
long after, for example, DES has been published (DES rotates the
key bits), and this is a practical example how people patent maths.

If you can get a patent on "using rotation in encryption", you
can also get a patent on any piece of math you wish, don't you ?
Why don't you patent "using addition in mercantile computations
to get the sum of something" ? Hey, its patentable ! Maybe
nobody has been so original to patent it yet ! But I'm not sure
about that, of course.

> Patents an copyrights are both monopoly rights granted by the govenment.
> They may have a social benefit. They also have a social cost, as the
> USSR found in their granting of monopoly rights to businesses.  Society
> should make sure that they get back a lot for the grant of such monopoly
> rights.

Software patents will, for example, destroy free software if we
can't hinder it. I can't see how you want to get such losses
back.

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


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