Cryptography-Digest Digest #86, Volume #10 Fri, 20 Aug 99 19:13:03 EDT
Contents:
Re: Angewandte Kryptographie von Bruce Schneier (John McDonald, Jr.)
Re: Angewandte Kryptographie von Bruce Schneier (Rochus Wessels)
Re: compress then encrypt? (SCOTT19U.ZIP_GUY)
Re: Human-Readable Encryption (Newbie) (John Savard)
Re: Where to find ("karl malbrain")
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big ("Michael T.
Babcock")
Re: Where to find (Tom St Denis)
Re: NIST AES FInalists are.... (John Savard)
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Re: LFSRs in a5 (Ian Goldberg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John McDonald, Jr.)
Subject: Re: Angewandte Kryptographie von Bruce Schneier
Date: Fri, 20 Aug 1999 18:52:36 GMT
On Fri, 20 Aug 1999 14:49:39 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>No being fluent in German, I ran the above through www.systransoft.com's
>automatic translator and came up with this amusing result:
> I became urgently the book " applied cryptography. Logs, algorithms
> and SOURCE code in C." of Bruce Schneier (ISBN: 3893198547) need.
> Since it is cheap however not even, I became it first gladly
> check-out counters. Only unfortunately white I not whether and
> where in Austria (Vienna) is possible. If someone possesses the
> book and no more necessarily, I would buy it also gladly at a fair
> price. Thank you for notes already in advance!
Off topic... Go ahead and stop reading if you don't care about German.
Douglas,
My German is a bit rusty, but I can explain a few of the oddities that
you note. German is a little different then English as far as
sentence structure goes. For instance, in English we would say 'I
would like to go into the movie theater.'
In German, this sentence becomes 'Ich m�chte ins Kino gehen,'
or literally translated, 'I would like to in the theater go.' (Is it
m�chte, or m�ge, or w�nschen? Its been tooooo long...)
Verbs are _always_ (IIRC) in the second position in the
sentence. Complex verbs place the helper verbs in the second position
and the actual verb goes to the end of the sentence.
So if you follow this, cut and paste a few verbs from the end of
sentences to the middle where they belong (in English) the sentences
make a whole lot more sense, no?
Hope this helps.
---
John K. McDonald, Jr. Alcatel, USA
[EMAIL PROTECTED]
--
"I speak for me and not this company"
TO SPAMMERS:
Please note important defininitions:
The Telephone Consumer Protection Act
of 1991, Title 47, Chapter 5,
Subchapter II, Section 227.
------------------------------
From: Rochus Wessels <[EMAIL PROTECTED]>
Subject: Re: Angewandte Kryptographie von Bruce Schneier
Date: 20 Aug 1999 21:43:17 +0200
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
> Buchinger Reinhold wrote:
> > Ich w=FCrde dringend das Buch "Angewandte Kryptographie. Protokolle,
> > Algorithmen und Sourcecode in C." von Bruce Schneier (ISBN: 3893198547)
> > ben=F6tigen. Da es aber nicht gerade billig ist, w=FCrde ich mir es zue=
rst gerne
> > ausleihen. Nur leider wei=DF ich nicht ob und wo das in =D6sterreich (W=
ien)
> > m=F6glich ist.
> > Falls jemand das Buch besitzt und nicht mehr ben=F6tigt, w=FCrde ich es=
auch
> > gerne zu einem fairen Preis kaufen.
> > Vielen Dank f=FCr Hinweise schon im Voraus !
>
> No being fluent in German, I ran the above through www.systransoft.com's
> automatic translator and came up with this amusing result:
> =09I became urgently the book " applied cryptography. Logs, algorithms
> =09and SOURCE code in C." of Bruce Schneier (ISBN: 3893198547) need.
> =09Since it is cheap however not even, I became it first gladly
> =09check-out counters. Only unfortunately white I not whether and
> =09where in Austria (Vienna) is possible. If someone possesses the
> =09book and no more necessarily, I would buy it also gladly at a fair
> =09price. Thank you for notes already in advance!
He tries to borrow the book or purchase a used one, to save money.
And I bookmarked your translator for fun. Not for use. ;-)
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: compress then encrypt?
Date: Fri, 20 Aug 1999 20:42:55 GMT
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
>One little note: it is impossible to compress uniformely random data.
I think you mean that it is impossible to compress to a smaller size
on the average all the files in a given set where the enropty is all ready a
max. For example 2 brother get together they by this random data generator
they got from you they create 16 long random data streams to send as
a message. The NSA get wind of this and with the hard installed on there
snooper they compresss the 16 long message down to one bit and store it
in a file so as to keep track of what the brothers are sending to each other.
>That is, say you have a (suposevly good) compression function
>C:X -> Y, where you compute elements (x) that are uniform-
>randomly choosen from X, then your function could reduce the size
>of some outputs, but will blow up for others (that is , instead of
>compressing, you expand your input). Compression algo. rely on
>the fact that they are not used for all x in X, or mostly, there is heigher
>probability of choosing x in S, where S is a subset of X. English texts,
>for example, form a small subset of the sets of all finit strings of letters.
>Code written in Java is another example.
>
>One conclusion, if you want your encryption algo to produce stuff that
>looks like random, then yes, it is a good test to try compressing it with
>different algos... it should not compress to much, some entries should
>blow up.
>
IF you use my method so that the input can be the set of all files of
nozero finite length.Then the compression program will actuall make the
average file somewhat longer in lenght. However if you use the decompression
program it will also make the average length longer but that average will be
longer than what the compression program did. That being said test it
on any file that you may want to encrypt. It will most likel get smaller
unless it is an ecrypted file or a zipped file. Most useful data files will
get smaller.
>anton
>
>
>
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] (John Savard)
Subject: Re: Human-Readable Encryption (Newbie)
Date: Fri, 20 Aug 1999 20:00:00 GMT
<[EMAIL PROTECTED]> wrote, in part:
>I am looking for algorthims (even a weak cipher will do nicely) that will
>encrypt a message into a human-readble encrypted form. Specifically I would
>like to specify a resulting numeric range that could correspond to the ASCII
>character set (e.g. ASCII 32-126, or {space} through {~}). I would also
>like to be able to decrypt (is this implied?).
Even PGP does this: binary encrypted output is converted to printable
character form in a process called 'armor' so that it will be more
easily transmitted through the Internet.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Subject: Re: Where to find
Date: Fri, 20 Aug 1999 12:48:08 -0700
David Hamilton <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> You overestimate your importance to me (and everybody else I guess). In
fact,
> I don't hate you and you don't piss me off.
(...)
>
> By the way, have you cracked IDEA yet? You did say you would didn't you?
Your comments indicate your OWN lack of professionalism. Stating one's
intentions is a matter of professional courtesy. Holding someone to their
dreams or aspirations is not an OBJECTIVE discussion, leaving your own
intentions open to interpretation. Karl M
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Fri, 20 Aug 1999 20:22:46 GMT
In article <7phvdg$4ea$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Wagner) wrote:
>Since the parameters for the AES competition are already
>set for us by NIST, these real-world design principles are irrelevant
>to the AES competition -- even if NIST's framework is somewhat sub-
>optimal, it's probably too late to change it.
I wonder. Surely the AES competition is not an academic
exersize framed by NIST's specifications for the contest;
after all the AES will be an important primitive in many
real-world COMSEC systems. You cannot analyze primitives
independently of their context. I think it would serve
security better if the public researchers investigated for
weaknesses in the AES finalists when only a few known or
chosen plaintexts are available, because this is the
appropriate attack model in the real world. Why not assume
that "only" a thousand known plaintexts are available and
compare the finalists under this assumption alone?
I have suggested to NIST that in order to compare ciphers in
a sensible manner a "cost" function for an attack must be
agreed beforehand. I think this cost function should grow
very quickly if too many known plaintexts are required. It
is interesting to think about how other parameters (weak
keys, chosen plaintexts, memory, work, etc) should affect
the attack cost function.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Wed, 18 Aug 1999 20:40:19 -0400
From: "Michael T. Babcock" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers,alt.comp.lang.learn.c-c++,comp.lang.c++
Subject: Re: How to write REALLY PORTABLE code dealing with bits (Was: How Big
Actually, Tom StDenis was right if he was referring to the count of bits in a
byte (which is probably what was in the back of his mind somewhere) as there
is no definition in ANSI C for the SIZE of a byte in bits.
However, he is wrong in flatly stating (as you pointed out) that there is "no
definition" for a byte in ansi C ... they are not defined as a keyword
however, simply as a term. They are not identifiers either (to my knowledge).
byte *string; isn't going to get me far in an ANSI C compiler ...
> Martin Ambuhl <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > That's not true. There is no definition of 'byte' in ANSI C. sizeof()
> > > returns the length of 'chars' it requires to store the object.
> >
> > To avoid appearing a fool, it helps to not make flat statements that are
> > completely untrue. They indicate not only a lack of knowledge but a
> > reckless disregard for the truth. From the standard (ISO 9899:1990) we
> > find the following definition that you just assured us does not exist:
> >
> > 3 Definititions and conventions
> >
> > 3.4 byte. The unit of data storage large enough to hold any member of
> > the basic character set of the execution environment. It shall be
> > possible to express the address of each individual byte of an object
> > uniquely. A byte is composed of a contiguous sequence of bits, the
> > number of which is implementation-defined. The least significant bit is
> > called the low-order bit; the most significant bit is called the
> > high-order bit.
> >
> >
> >
> > --
> > Martin Ambuhl [EMAIL PROTECTED]
> >
> > __________________________________________________________
> > Fight spam now!
> > Get your free anti-spam service: http://www.brightmail.com
> >
--
_____/~-=##=-~\_____
-=+0+=-< Michael T. Babcock >-=+0+=-
~~~~~\_-=##=-_/~~~~~
http://www.linuxsupportline.com/~pgp/ ICQ: 4835018
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Where to find
Date: Fri, 20 Aug 1999 20:18:47 GMT
In article <7pi9j9$2o5i$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Hamilton) wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >
> >>In article <[EMAIL PROTECTED]>,
> >>[EMAIL PROTECTED] (Preditor31) wrote:
> >>>Where can I find an encryption and a decrytion program? Also how
would I
> >>>go
> >>>about learning how to break encryption?
>
>
> >>> Thomas
> >
> >> While I would suggest you go to my site. But your sure to get much
> >>asdvice as to why you should not.
> >
> >
> >- From the cryptography point of view, David A. Scott and his
software are not
> >to be trusted. So, don't use anything written by him; instead, use
PGP and/or
> >Scramdisk since it is almost certain that both are much, much
stronger.
> >
> >Here are 5 reasons for my view.
> >
> >1) David A. Scott has poor native (English) language skills and this
might
> >mean he has poor programming skills.
> >
> >2) David A. Scott is fixated on code. He seems not to realise that
> >programming and cryptography are much more than just coding.
> >
> >3) David A. Scott designed all the algorithms and code used in his
software
> >and, with one exception, he can't remember the names of people who
> >'commented' on it. 'Commenting' isn't good enough anyway: formal
inspection
> >processes are needed. The algorithms used in PGP and Scramdisk were
developed
> >by teams of cryptographers with distinguished reputations.
> >
> >4) With PGP, there are newsgroups and mailing lists that can help
with
> >queries. Scramdisk has its own newsgroup as well. There are no such
things
> >for David A. Scott's software.
> >
> >5) David A. Scott said, in the past, that he would crack IDEA. But
he now
> >studiously ignores questions asking whether he has succeeded. (Guess
why.)
> >
> >So, don't entrust your security and privacy to David A. Scott and his
> >software?
> >
> >
> >David Hamilton.
>
> As you can see David Hamiltion is one of my favortie haters. I piss
him off
> a lot. But if you follow some of the other posts. It was noted that
David
> Wagner ( another dam david) who also hates my guts bragged about how
> bad my code was and that is new super dooper Slide attack would prove
it
> was junk. Guess what after several weeks of trying it was shown to be
> UNBREAKABLE by the new awarding winning slide attack. Just thought
> you would like to know some of the facts.
Funny... you didn't comment on any other points...
funny slide attacks doesn't work against most ciphers with round
keys... funny stuf....
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: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST AES FInalists are....
Date: Fri, 20 Aug 1999 20:55:30 GMT
[EMAIL PROTECTED] wrote, in part:
>I think it would serve
>security better if the public researchers investigated for
>weaknesses in the AES finalists when only a few known or
>chosen plaintexts are available, because this is the
>appropriate attack model in the real world. Why not assume
>that "only" a thousand known plaintexts are available and
>compare the finalists under this assumption alone?
I can't agree with that, because then *all* the finalists would turn
out to be absolutely secure, and we might have ended up with MAGENTA.
DES is a very strong design; scaling up DES to 128-bit blocks and
256-bit keys, _even if done clumsily_, would produce something that
would be invincible under that condition.
For that matter, so would LUCIFER, which is very weak against a
differential (requiring many known plaintexts) attack.
Also, strength with an unlimited number of known plaintext has some
useful properties. It allows encryption to be offered on a "utility"
basis; a user of a timesharing system can communicate securely without
being able to compromise the sessions of other users.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NIST AES FInalists are....
Date: Fri, 20 Aug 1999 23:37:49 GMT
In article <7pkg5b$fjf$[EMAIL PROTECTED]>, David A Molnar
<[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>
>> chosen plaintexts are available, because this is the
>> appropriate attack model in the real world. Why not assume
>> that "only" a thousand known plaintexts are available and
>> compare the finalists under this assumption alone?
>
>I can think of two reasons not to :
>
>1) it's unlikely that attacks will be found which use only a thousand
>known plaintexts before time is up. If that happens, it will leave us
>with five ciphers all "equally secure" under that assumption.
>
>2) more of a quibble, but a thousand known plaintexts may be too small.
>Consider using AES to encrypt a high-bandwidth channel between two office
>buildings, or between an office building and the outside world. If an
>adversary can compromise part of the traffic, say by taking a job in the
>building on one end, then it can gain access to large numbers of known
>plaintexts.
>
>To make this more concrete, imagine that I work in a company which uses
>AES to encrypt data being sent to an overseas office. I can send anything
>I want to my colleagues on the other end of the line, but I can't read the
>CEO's mail. If both of our messages are encrypted with the same key over
>the link (which hopefully they would not be), then a chsen-plaintext
>attack aimed at recovering the CEO's mail is possible.
>
>If we know that AES is vulnerable after seeing X chosen plaintexts with
>the same key, howevr, then we can take steps to prevent this, say by
>changing keys before that many blocks have been encrypted. It gives us
>some idea of when it's not safe to use the cipher. Even if X is
>"unreasonable" or "academic" in size, it's still some information.
>
>
> > is interesting to think about how other parameters (weak
>> keys, chosen plaintexts, memory, work, etc) should affect
>> the attack cost function.
>
There are other factors to consider. Such is do any of the keys produce
the same results. What is the cycle lenght of the cipher. That is for any
key is the resulting cycles the same or does it vary with the key if it
varies with the key what is the shortet cycle length. Since like for a small
number of mappings what is the underlining complexity interms of the
S-tables equivalent for each cipher. Can that same S-table or set of S-tables
be generated with less complxity. Does any one care about these features
in the so called AES candidates.
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] (Ian Goldberg)
Subject: Re: LFSRs in a5
Date: 19 Aug 1999 17:47:09 GMT
In article <7ph40m$tj4$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> Maciej Maciejonek <[EMAIL PROTECTED]> wrote:
>> I'm looking for any information about LFSRs used in a5.
>> I know that this binary stream cipher consist of three short Fibonacci
>> LFSRs of sizes 19,22 and 23 respectively.
Funnily enough, we (David Wagner, myself, and Lucky Green) just announced
at the Crypto 99 rump session that we have a 2^16-time (read: real time)
break of A5/2. (Implemented in code, and everything.)
A5/2 is the (weaker) version of A5 used in a bunch of countries that weren't
"cool" enough to get A5/1. (Australia uses A5/2, for example. Rumor has
it that China is currently upgrading from A5/0 (identity cipher) to A5/2.
Hong Kong, funnily enough, uses A5/1, since it was installed under British
rule. There are a bunch of other A5/2 countries, but I don't have a list
handy.)
Here are the taps for the registers:
/* Feedback taps, for clocking the shift registers.
* These correspond to the primitive polynomials
* x^19 + x^5 + x^2 + x + 1, x^22 + x + 1,
* x^23 + x^15 + x^2 + x + 1, and x^17 + x^5 + 1. */
#define R1TAPS 0x072000 /* bits 18,17,16,13 */
#define R2TAPS 0x300000 /* bits 21,20 */
#define R3TAPS 0x700080 /* bits 22,21,20,7 */
#ifdef A5_2
#define R4TAPS 0x010800 /* bits 16,11 */
#endif /* A5_2 */
What else would you like to know?
>I have source code for it if that helps... ask in private email.
Be careful; the "alleged A5/1" published in a number of places, including
Applied Cryptography, is _not_ the correct algorithm. The taps are in the
wrong place, for example.
We'll be publishing the (real) A5/1 and A5/2 source (with test vectors),
as well as the A5/2 break, as soon as we add some comments and can find
an export-restricted site on which to host it.
- Ian
------------------------------
** 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
******************************
