Cryptography-Digest Digest #289, Volume #11 Thu, 9 Mar 00 17:13:01 EST
Contents:
Re: Big Float project ("Tom St Denis")
Re: An archiver with secure encryption ("Tom St Denis")
Re: Actually, I have a sign "Be Aware of Dog" on the garage door of the house,
where I am living .. it is a lie .. (JimD)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher
([EMAIL PROTECTED])
Re: sci.crypt Cipher Contest Web Site (Bob Silverman)
Re: avoid man-in-the-middle known plaintext attack using a stream cipher (David A.
Wagner)
SHA-1 and Patents confusion with Hitachi (Benjamin Gittins)
Re: NIST, AES at RSA conference ([EMAIL PROTECTED])
Re: Best language for encryption?? (Darren New)
Re: Universal Language (Darren New)
Re: NIST, AES at RSA conference (D. J. Bernstein)
Re: sci.crypt Cipher Contest Web Site (SCOTT19U.ZIP_GUY)
Re: SHA-1 and Patents confusion with Hitachi (John Savard)
Re: Free-MAC mode (David A. Wagner)
Re: NIST, AES at RSA conference (Terry Ritter)
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Big Float project
Date: Thu, 09 Mar 2000 20:34:31 GMT
Mike Rosing <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I tried to get Tom StDenis to host this, but his ISP said no. So you
> can
> find the Big Float project on my web page:
> http://www.terracom.net/~eresrch/float
>
> I promise the code has bugs :-)
>
> The idea is to compute the number of points on an elliptic curve. With
> luck
> I'll have Kobliltz curves in a few weeks.
>
> Patience, persistence, truth,
> Dr. mike
I would love to get into what you are doing [math is always fun]. Problem I
don't know what the heck you are talking about. Could you suggest a place
to read in your book for a brief on it?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: An archiver with secure encryption
Date: Thu, 09 Mar 2000 20:36:01 GMT
Steve A. Wagner Jr. <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> *** The United States government may restrict download of this software.
> ***
>
> Fully enabled Shareware -- http://mndrppr.home.mindspring.com/
>
> I hope you find it useful, and send me some comments either way.
>
> Algorithms: Triple-DES, TwoFish (256bit), BlowFish (448bit)
>
> Compression: Store, Zip4, Zip6, Zip9, and an added proprietary method
> for large redundancies.
>
Why not just use deflate?
http://www.cdrom.com/pub/infozip/zlib/
As for the ciphers, why use 448 bit keys? Is this a symmetric system or
does PK get used anywhere?
Tom
------------------------------
From: [EMAIL PROTECTED] (JimD)
Crossposted-To:
alt.politics.org.cia,soc.culture.russian,soc.culture.nordic,soc.culture.israel,soc.culture.europe
Subject: Re: Actually, I have a sign "Be Aware of Dog" on the garage door of the
house, where I am living .. it is a lie ..
Reply-To: JimD
Date: Thu, 09 Mar 2000 20:48:47 GMT
On Thu, 09 Mar 2000 08:04:12 -0700, "Tony T. Warnock"
<[EMAIL PROTECTED]> wrote:
>Outsider wrote:
>
>>
>> If you want a good sign, place a sign that says the following on
>> your front and back doors.
>>
>> ===============================
>> Trespassers will be shot.
>> Survivors will be shot again.
>>
>> (picture of gun)
>>
>> ===============================
>
>I once saw a similar sign that said: "Trespassers will be shot. Survivors
>will be held for ransom."
In our local computer shop: 'What remains of anyone caught shoplifting
will be handed over to the police'.
--
Jim Dunnett.
dynastic at cwcom.net
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 9 Mar 2000 20:48:07 GMT
How will the attacker tell that his attack has been unsuccesful or succesful,
and how will he be able to try 2^16 or even 2^9 times? I have implicitly
assumed that both the sender and the receiver are perfectly trusted.
(Otherwise the OTP would have been the first thing to go - it's too big to
hide from a nosey user.)
But yes: There may, generally speaking, certainly be weaknesses invloved if
one is using only a 16-bit feedback buffer.
In a previous article, <[EMAIL PROTECTED]> writes:
>In article <8a0tv2$eu4$[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
>> P[I]: Ith byte of plain text,
>> C[I]: Ith byte of cipher text,
>> S[I]: Ith byte of an OTP,
>> B[I]: The 16-bit feedback buffer at step I, where B[0] is the IVector,
>> B[I,0], B[I,1]; The least and most significant byte of B[I] respectively.
>> E_K: A 16-bit table lookup cipher.
>>
>> The symbol "|" denotes concatenation. B[I] = B[I,0]|B[I,1].
>>
>> Encryption algorithm:
>> 1. B[I] := E_K(B[I-1,1]|C[I-1] xor S[I-1])
>> 2. C[I] := P[I] xor B[I,0] xor S[I]
>>
>> Decryption algorithm:
>> 1. B[I] := E_K(B[I-1,1]|C[I-1] xor S[I-1])
>> 2. P[I] := C[I] xor B[I,0] xor S[I]
>
>Because the feedback "pipe" is only 16 bits wide, there are plenty
>of birthday attacks here one may mount. In particular, if you modify
>two adjacent bytes of ciphertext, the probability that this change
>fails to propagate is something like 1/2^16, so just try 2^16 times;
>and it may be possible to get that down to something like trying 2^9
>times (using the birthday paradox).
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Thu, 09 Mar 2000 20:51:06 GMT
In article <WPAx4.1$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> I put together a web site with the a draft of the requirements for
entries.
> I need feedback on the requirements and suggestions from everyone
planing on
> participating
Might I suggest to anyone who is planning on participating:
If you actually have time to spend on examining the security of
symmetric ciphers, that you instead select one of the AES candidates
and spend time analyzing it instead?
AES is important. If you have spare time, why not spend it on something
important, instead of wasting it on a 'cipher' that will never see
the light of day?
If you want to be taken *seriously* by the crypto community, I can think
of no better way of doing so than by exposing a weakness in one of the
AES ciphers.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: avoid man-in-the-middle known plaintext attack using a stream cipher
Date: 9 Mar 2000 12:38:41 -0800
In article <8a92m7$30v$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> How will the attacker tell that his attack has been unsuccesful or succesful,
His bank account gets credited by some huge amount.
> how will he be able to try 2^16 or even 2^9 times?
Keep trying until you hit paydirt.
------------------------------
From: Benjamin Gittins <[EMAIL PROTECTED]>
Subject: SHA-1 and Patents confusion with Hitachi
Date: Thu, 09 Mar 2000 21:06:01 GMT
I am somewhat confused.
sha / sha-1 designed by nsa [schnier:applied crypto]
on the IEEE p1363 standards web site, in patent letters...
http://grouper.ieee.org/groups/1363/letters/NIST.txt
"
NIST published the SHA for public comment on January 31, 1992. Since
NIST did not patent the SHA algorithm, NIST has no rights to license
with respect to the use of SHA or SHA-1.
"
friendly enough ...
then..
Hitachi, Ltd., Intellectual Property Office
http://grouper.ieee.org/groups/1363/letters/Hitachi.txt
"
If IEEE adopts a standard on the above RIPEMD-160, RIPEMD-128 and SHA-1
hash functions, Hitachi Ltd. is willing to grant non-exclusive, non-
transferable licenses on fair, reasonable and non-discriminatory terms
and conditions under any of its patent rights, under which it has the
free right to grant licenses and to the extent necessary to comply with
this standard, to any party which has submitted or will submit an
equivalent undertaking with respect to this standard.
"
Now, does this mean
1 ) Hitachi claims patents on SHA-1?
2 ) That royalties are due, for an algorithim made freely available by
its authors?
3 ) Is this patent actively enforced?
4 ) What are these said dues we must pay to ceaser?
similar issue with RIPEMED-160 by its authors.
http://grouper.ieee.org/groups/1363/letters/Bosselaers.txt
??????
Hitachi Patents: in the U.S.
US4982429: Encipher method and decipher method
http://www.patents.ibm.com/details?pn=US04982429__
US5103479: Encipher method and decipher method
http://www.patents.ibm.com/details?pn=US05103479__
Abstract:
There are provided an encipher method of enciphering message data made
by a microcomputer or the like at a high speed by using encipher keys
which have previously been stored in a smart card or the like and a
decipher method of deciphering the ciphertext made by the encipher
method at a high speed by using the encipher keys. The encipher method
and the decipher method are suitable for, particularly, a 32-bit
microcomputer and include a process expressed by the function Rot2 i(x)
(i=2, 3, 4) in each process. Rot2 i(x) is the process to circular shift
a data train x of 32 bits to the left or right by 2i bits (i=2, 3, 4).
What are other peoples thoughts, experiences with this.
Ben
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST, AES at RSA conference
Date: Thu, 09 Mar 2000 21:14:44 GMT
In article <8a7f0b$ssv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (John Savard) wrote:
> > [EMAIL PROTECTED] (Bo D�mstedt) wrote, in part:
> >
> > >Terry Ritter has presented a whole bunch of convincing
> > >arguments. Not even a formal mathematical proof
> > >would convince some people.
> >
> > Funny you should say that, because one of the major problems with
his
> > argument is that, while he correctly (I'm convinced) that his
> proposal
> > is an effective method of achieving considerably stronger encryption
> > in practice, his rationale for establishing the need for stronger
> > encryption than just using Triple-DES or the AES is the lack of a
> > _formal mathematical proof_ that they're strong enough. Since even
> > after his proposal is applied, this lack still exists, I'm not
> > surprised that a number of people have essentially replied, "what's
> > the point"?
>
> Frankly, I'm surprised that you -- and, presumably, they -- continue
> to miss the point. This continued confusion almost seems willful.
>
> Correct: The problem we have with cryptography is that it cannot
> be treated like virtually any other product in society. Only
> cryptography has us depend upon something which not only cannot
> be proven; strength which cannot even be tested or success
> verified. Because we all depend upon "common sense" built up
> from our experiences in other contexts, this uniqueness is a
> very serious problem.
>
> Yes, the problem is that cipher strength cannot be proven. Yes,
> after my proposals are applied, cipher strength *still* cannot
> be proven. But since that is not the intent of my proposals,
> that seems hardly to be a telling argument.
>
> The intent of my proposals is to address the possibility that
> the single cipher we would normally use forever is in fact
> insecure. This is a single-point fault, and we cannot test for
> such faults, nor can we prove they do not exist. Because a
> broken cipher will reveal our data forever, we must change
> ciphers to regain security, so we must have different ciphers
> to change to, and we must have a system which supports changing
> ciphers with minimal intrusion.
>
> I hope this is the last time I see the specious argument
> against my proposals from this particular author.
>
> > Now, there is a comeback to that: if, whatever you do, you can't
> prove
> > your ciphers will keep your secrets, then, doesn't it at least seem
> > reasonable to do *whatever you can* to improve your chances - and
so,
> > if your computer can encrypt your message in Triple-DES or AES in
the
> > 'blink of an eye', wouldn't it be more sensible to let the computer
> > take 5 seconds to encrypt your message _as thoroughly as is
currently
> > practical_ if your secrets are important to you?
> >
> > However, what I feel is the real obstacle to any widespread use of
> > something like Terry Ritter's multi-ciphering proposal is this:
> >
> > The prospect of someone coming up with an attack against one of the
> > current five AES finalists, for example, that renders it dangerously
> > weak seems remote to many people, including myself. The prospect
that
> > someone might find a much improved method of factoring, or a much
> > better way to find discrete logarithms, seems like a considerably
> more
> > realistic threat.
>
> Frankly, I find the above logic seriously disturbing: It
> essentially consists of "I think a cipher is secure, therefore
> it must be secure." That is wishing, not science.
>
> There is a lot of arrogance to the idea that the repetitive
> application of the same simple ciphering functions in "rounds"
> is not a fundamentally breakable construction.
>
> In any case, the issue is not the strength which we cannot
> know, but instead the data risk which we can. If we really
> have something at risk, we simply cannot continue to depend
> on one cipher to carry that load over all time. If we do,
> we are making our precious data the ideal target.
>
> > Since his proposal or similar methods cannot address that threat,
and
> > since a great many people _insist_ on the convenience of public-key
> > encryption for key management in most applications, the lack of
> > interest his proposal is generating is not surprising.
>
> Presumably, public-key methods can be increased in strength
> arbitrarily. Multiple such methods also could be used in
> sequence, for example. While my proposals have been directed
> to the data cipher, they are easily and immediately extended
> to public-key ciphers as well. Obviously.
>
That would imply users holding multiple digita certs , one for RSA, one
for ElGAMAL , one for Elliptic curve etc...would comlpicate things
wouldnt it...key management issues?
As a sideline there are rumours that the "Not So Allknowing" does not
trust public key systems implicitly, and that Firefly is a hybrid
system.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Best language for encryption??
Date: Thu, 09 Mar 2000 21:25:56 GMT
Paul Schlyter wrote:
> Which there almost are: if a floating-point type is converted to/from
> an integer type, some actual conversion is done, otherwise the bit
> pattern is just copied. This originate from the K&R C paradigm
> "Everything is an int" (including pointers, and excluding only
> structs/unions and floating-point types).
Pointers were never "just ints" in K&R C. They just had silent type
conversions back and forth.
> syntax: the semantics behind it is usually just a copying of some
> bit pattern (the only exception being when casting a floating-point
> type to/from an integer type or another floating-point type).
Nope. If you're using a machine where (for example) the null pointer isn't
represented by a zero, or where pointers have different bit orders or bit
patterns than integers, it certainly does convert pointers to integers on
casts, and back again. I'm not sure whether you're allowed to lose
information if you cast a char* to a long, then to an int*, then back again,
but there are architectures where a char* and an int* are two different size
pointers.
John Myre wrote:
> silly. I don't think you can say C is "weakly typed", at least
> not the current standard, because the compiler will actually
> check stuff for you if you let it.
I think that C is called "weakly typed" not only because of the casts that
let you cast things to that which they aren't, such as casting "struct x" to
"struct y". It's also because C lets you do things at run time like point
pointers off the end of an array and clobber stuff you shouldn't be able to
clobber. Altho theoretically possible at run time to catch such things, I've
never seen a compiler generate code that will.
> Consider, in contrast, things
> like Smalltalk and LISP, or even early C.
Smalltalk and Lisp are both strongly typed. The difference is that the
values are typed, rather than the variables. The C compiler can't catch
whether you're indexing off an array, and Smalltalk can't catch if you have
the "wrong" class in a variable. The difference is that C will crash and
Smalltalk won't when you hit that error.
> With regard to the original question (see subject), I think that
> in fact type-checking makes encryption algorithms harder to write,
> in general, because we usually need to convert data values (e.g.,
> between text, bit strings, and numbers).
Actually, it's only a problem if your strong typing doesn't allow those
operations. What is easy and what isn't is orthoganol to type checking. If
you have a "bit string" type you can convert to and from, it's all easy.
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Universal Language
Date: Thu, 09 Mar 2000 21:32:06 GMT
[EMAIL PROTECTED] wrote:
> Huh? Esperanto doesn't have grammatical gender. Whatever gave you that
> idea? See <http://www.esperanto.net>.
An Esperanto book I bought probably 20 years ago. Either they've updated the
language to simplify it even more, or I'm misremembering something. Ah well.
Sorry about that.
--
Darren New / Senior MTS / Invisible Worlds Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no safety in disarming only the fearful.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: NIST, AES at RSA conference
Date: 9 Mar 2000 21:34:57 GMT
John Savard <[EMAIL PROTECTED]> wrote:
> his proposal is an effective method of achieving considerably stronger
> encryption in practice,
No. There is no reason to believe that Ritter's encryption function is
stronger than simpler, faster functions with the same key length.
---Dan
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: sci.crypt Cipher Contest Web Site
Date: Thu, 09 Mar 2000 22:43:24 GMT
In article <8a92ro$3kj$[EMAIL PROTECTED]>, Bob Silverman <[EMAIL PROTECTED]> wrote:
>In article <WPAx4.1$[EMAIL PROTECTED]>,
> "Adam Durana" <[EMAIL PROTECTED]> wrote:
>> I put together a web site with the a draft of the requirements for
>entries.
>> I need feedback on the requirements and suggestions from everyone
>planing on
>> participating
>
>
>Might I suggest to anyone who is planning on participating:
>
>If you actually have time to spend on examining the security of
>symmetric ciphers, that you instead select one of the AES candidates
>and spend time analyzing it instead?
>
>AES is important. If you have spare time, why not spend it on something
>important, instead of wasting it on a 'cipher' that will never see
>the light of day?
>
>If you want to be taken *seriously* by the crypto community, I can think
>of no better way of doing so than by exposing a weakness in one of the
>AES ciphers.
>
>
AES is a fucking joke. The only time it would be worht looking at is when
they finally pick a final cnadidate becasue we can be sure it will be weak
so the NSA can read what is encrypted with it.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: SHA-1 and Patents confusion with Hitachi
Date: Thu, 09 Mar 2000 15:06:19 GMT
Benjamin Gittins <[EMAIL PROTECTED]> wrote, in part:
> 1 ) Hitachi claims patents on SHA-1?
It is possible that, before MD5 was invented at RSADSI, Hitachi
developed and patented some type of message digest or block cipher
algorithm which they claim first embodied certain ideas used in MD5
and the later, and closely similar, SHA-1.
You are quite right that the NSA is not, as far as we know, a research
subsidiary of Hitachi.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Free-MAC mode
Date: 9 Mar 2000 13:26:09 -0800
In article <[EMAIL PROTECTED]>,
Adam Back <[EMAIL PROTECTED]> wrote:
> encryption is:
> y_i = E_k( x_i + y_{i-1} ) + x_{i-1}
>
> In practice to make a MAC out of this you would append a fixed block to the
> message and verify that this fixed block was preserved on decryption. This
> block could be public, or [...]
When the check-block is public, there are truncation attacks.
To forge a message M, set M' = M||B||S, where B is the fixed block
used to check integrity and S is any suffix you like. Obtain the
MAC'ed encryption of M' to get ciphertext C'; then truncate C' to the
length of M||B. Since -- in your mode -- the encryption of the prefix
is the same as the prefix of the encryption, the result will be a
valid encryption of the message M, as desired. This is an integrity
failure which shows that the MAC is not secure, when the check-block
is public.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 09 Mar 2000 22:08:53 GMT
On 9 Mar 2000 21:34:57 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt [EMAIL PROTECTED] (D. J. Bernstein) wrote:
>John Savard <[EMAIL PROTECTED]> wrote:
>> his proposal is an effective method of achieving considerably stronger
>> encryption in practice,
>
>No. There is no reason to believe that Ritter's encryption function is
>stronger than simpler, faster functions with the same key length.
Typically, we have a claim: No logic, no reasoning, no evidence.
Absent actual mathematical proof otherwise, it is *undeniable* that
the possibility exists that any particular cipher *may* be weak.
Cipher weakness and strength are necessarily contextual, and weakness
may occur for unknown hidden opponents even while learned academics
experience and testify to strength.
There is ample reason to believe that using multiple different ciphers
in sequence might hide weakness in a particular cipher: First, we
don't expect the same weakness in each cipher, so the attack probably
will not break the full "stack" of ciphers. Next, we don't expect an
attack on a single cipher to easily be applied when the cipher is
protected by two other ciphers. But even if the attack *is* applied,
and one cipher *is* broken, the data are still protected by the other
two ciphers, which of course is the whole point.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
