Cryptography-Digest Digest #92, Volume #10 Sun, 22 Aug 99 07:13:03 EDT
Contents:
--- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)
Re: Ciphile Software (David A Molnar)
Quadibloc VI Taking Shape
Re: Angewandte Kryptographie von Bruce Schneier ("Douglas A. Gwyn")
http://drive.to/filly ("filly")
Re: Challenge: mental authentication ("Lassi Hippel�inen")
Re: Crypto 1981-1997 CD-ROM fix (Helger Lipmaa)
Re: Crypto 1981-1997 CD-ROM fix (Helger Lipmaa)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Crossposted-To: talk.politics.crypto
Subject: --- sci.crypt charter: read before you post (weekly notice)
Date: 22 Aug 1999 05:00:40 GMT
sci.crypt Different methods of data en/decryption.
sci.crypt.research Cryptography, cryptanalysis, and related issues.
talk.politics.crypto The relation between cryptography and government.
The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
every three weeks. You should read it before posting to either group.
A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
It is not. It is reserved for discussion of the _science_ of cryptology,
including cryptography, cryptanalysis, and related topics such as
one-way hash functions.
Use talk.politics.crypto for the _politics_ of cryptography, including
Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
export controls.
What if you want to post an article which is neither pure science nor
pure politics? Go for talk.politics.crypto. Political discussions are
naturally free-ranging, and can easily include scientific articles. But
sci.crypt is much more limited: it has no room for politics.
It's appropriate to post (or at least cross-post) Clipper discussions to
alt.privacy.clipper, which should become talk.politics.crypto.clipper at
some point.
There are now several PGP newsgroups. Try comp.security.pgp.resources if
you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
and c.s.pgp.discuss for other PGP-related questions.
Questions about microfilm and smuggling and other non-cryptographic
``spy stuff'' don't belong in sci.crypt. Try alt.security.
Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
comp.compression, comp.security.misc.
Here's the sci.crypt.research charter: ``The discussion of cryptography,
cryptanalysis, and related issues, in a more civilised environment than
is currently provided by sci.crypt.'' If you want to submit something to
the moderators, try [EMAIL PROTECTED]
---Dan
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software
Date: 22 Aug 1999 05:35:44 GMT
In sci.crypt [ Dr. Jeff ] <[EMAIL PROTECTED]> wrote:
> In article <7plk9q$jpd$[EMAIL PROTECTED]>,
> David A Molnar <[EMAIL PROTECTED]> wrote:
>>
>>for me to make any sensible comment, and I haven't reverse engineered
>>their software. I'm not even sure if I can get source code!
> Why does having the source code matter? I'm not trying to pick
> nits but if the information one seeks is included in a help file (or in
> this case several), why would the source code be of any help? I'm not
When I posted this, I was thinking
"Well, I would really like to have a clear description, which I don't. I
don't even have the broad outlines in a fashion I understand (maybe this
reflects more on me than anything else, etc. etc. ). The next best thing
would be some kind of source code as a bare minimum...so I don't have to
reverse engineer the software to comment."
So it was meant for emphasis. Indeed if it is written in a low-level
or obscure language it might be hard to understand.
> not be able to follow the algorithm in that language. What if the code
> is in APL? That would be even harder to follow...
Tangent : In the used bookstore near school, I found a textbook on
"Teaching College Mathematics with APL." Looks interesting, although I'm
not so sure I'd want to have my math course in it.
> I'm not saying anyone should do that. Also not saying they
> shouldn't. Was mostly just wondering why no one ever made mention of it.
I think the thing is that you have to spend time looking at a product or a
design or an algorithm before you can say anything worth posting about it.
If no one has done that, or no sci.crypt readers, then no discussion.
The exception which proves the rule is when the product is very high
profile...then there may be lots of discussion but not all of it signal.
-David
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Quadibloc VI Taking Shape
Date: 22 Aug 99 05:09:36 GMT
After finally getting one of my mad block ciphers to the point of
implementation - although only in the form of a BASIC reference version to
produce test vectors, I've tried to use the lessons learned from Quadibloc
S to produce something that would be easily implementable, and yet include
the powerful "deep nonlinearity" of Quadibloc III, at least to a limited
extent.
At
http://www.ecn.ab.ca/~jsavard/co040709.htm
is a description of Quadibloc VI (it's the page before Quadibloc S due to
a numbering error caused by the fact that I was working on a different
Quadibloc VI at the time; also, some bad links on the Quadibloc S page
have been fixed) but that description is still incomplete, as I'll be
adding the key schedule later.
John Savard
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Angewandte Kryptographie von Bruce Schneier
Date: Fri, 20 Aug 1999 14:49:39 GMT
Buchinger Reinhold wrote:
> Ich w�rde dringend das Buch "Angewandte Kryptographie. Protokolle,
> Algorithmen und Sourcecode in C." von Bruce Schneier (ISBN: 3893198547)
> ben�tigen. Da es aber nicht gerade billig ist, w�rde ich mir es zuerst gerne
> ausleihen. Nur leider wei� ich nicht ob und wo das in �sterreich (Wien)
> m�glich ist.
> Falls jemand das Buch besitzt und nicht mehr ben�tigt, w�rde ich es auch
> gerne zu einem fairen Preis kaufen.
> Vielen Dank f�r 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:
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!
------------------------------
From: "filly" <[EMAIL PROTECTED]>
Subject: http://drive.to/filly
Date: Mon, 16 Aug 1999 14:25:21 +0200
http://drive.to/filly
http://drive.to/filly
------------------------------
From: "Lassi Hippel�inen" <[EMAIL PROTECTED]>
Subject: Re: Challenge: mental authentication
Date: Mon, 09 Aug 1999 13:54:20 +0300
John Savard wrote:
>
> So, the question remains open: can such a system be designed where a
> large number of users, each of whom is not to be able to get into
> another user's account, be (mechanically!) assigned a
> challenge-response protocol of their own?
>
> If we relax the conditions, and allow the user to have a piece of
> paper, where no one is looking over his shoulder, but the line is
> tapped, then the problem becomes easier.
>
> John Savard ( teneerf<- )
> http://www.ecn.ab.ca/~jsavard/crypto.htm
I think the question is still pretty ill defined. How much calculating
(or some other reasoning) capability is a user expected to have? Even
defining a metric for that capability seems difficult!
Also, as a practical implementation matter, what limitations are set on
the user interface? Text or graphic display? Any extra devices allowed?
Anyway, since we are dealing with humans, things are not purely
mathematical any more. Psychology and physiology must also be
considered. Even an ordinary keyboard can be used to measure response
time to a challenge, or intervals between keypresses.
At the moment I don't believe in provably secure authentication (between
the service and the user's brain), because the problem space is so
foggy. At least someone should first define the exact environment.
"Good enough" security is feasible, though. Physiometric systems are an
example, but the user interface is more complex than keyboard+display.
And even they don't authenticate the brain, only some body part that is
assumed to be connected to its original owner...
-- Lassi
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Crypto 1981-1997 CD-ROM fix
Date: Sun, 22 Aug 1999 08:38:38 +0000
lcs Mixmaster Remailer wrote:
> Springer-Verlag has now released the CD-ROM with the entire proceedings
> of the Crypto and Eurocrypt conferences from 1981-1997. These were for
> sale at Crypto 99 this week.
>
> The files are in PDF format, one for each paper. There are a set of
> HTML files which serve as indexes into the proceedings.
>
> Unfortunately the HTML files use upper case for their links, while all
> of the directories and file names are lower case. This does not matter
> on PCs and Macs, which are not case sensitive, but affects my Linux
> system. Is there a way to mount the CD-ROM in Linux which will make it
> treat all files as all upper-case so that the links will work?
>
You can use "mount -o map=3Doff" on a Linux. See man mount... Not that
I like the use of upper case...
Helger
http://home.cyber.ee/helger
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Crypto 1981-1997 CD-ROM fix
Date: Sun, 22 Aug 1999 09:46:13 +0000
Helger Lipmaa wrote:
> lcs Mixmaster Remailer wrote:
>
> > Springer-Verlag has now released the CD-ROM with the entire proceedings
> > of the Crypto and Eurocrypt conferences from 1981-1997. These were for
> > sale at Crypto 99 this week.
> >
> > The files are in PDF format, one for each paper. There are a set of
> > HTML files which serve as indexes into the proceedings.
> >
> > Unfortunately the HTML files use upper case for their links, while all
> > of the directories and file names are lower case. This does not matter
> > on PCs and Macs, which are not case sensitive, but affects my Linux
> > system. Is there a way to mount the CD-ROM in Linux which will make it
> > treat all files as all upper-case so that the links will work?
> >
>
> You can use "mount -o map=3Doff" on a Linux. See man mount... Not that
> I like the use of upper case...
Oops. That was in MIME. "mount -o map=off" is correct.
> Helger
> http://home.cyber.ee/helger
Helger
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Sun, 22 Aug 1999 12:33:05 +0200
[Note: The discussion tree is getting very deep. I am afraid that
it could lead to troulbes with my news reader. So this follow-up
is attached to the root of the tree.]
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > In that particular case the Huffman compression happens (by
> > construction) to end 'exactly' on a byte boundary, so we can forget in
> > the present discussion the general case of ending on a non-byte
> > boundary and hence needing padding (or your 'deletions'), can't we???
> Ok I am trying to follow your logic though different than
> mine.
> > In that particular case the last character of the input file has a
> > Huffman code of 9 bits and the input sequence (by construction) is
> > such that the pre-ultimate byte has only 1 bit free so that the first
> > bit of the 9 bits of the Huffman code gets into the pre-ultimate byte
> > and the remaining 8 bits fill (entirely) the last byte. Are you going
> > to add any zeros in this situation?? (It would be foolish if you would
> > do that.) Are you going to delete the last 8 bits?? (You couldn't do
> > that, because we can assume that there are other input characters that
> > also have a code of 9 bits beginning with 0 and hence if you delete
> > the 8 bits you wouldn't be able to uniquely get back to the original
> > file.) Do you agree with what I write above?? If you don't agree
> Lets say for the sack of argument I am trying to follow
> what you say but I would not word it that way.
> You can use the "DAM EXECTUABLE TO CHECK
> THIS". That being said why would add zeros in the case you said.
> Howeveer many some one can come up with a mod that is still one to one
> and still add zeros for the next word. I guess the first question
> I need to ask you is xxx...y y...y what your are looking at the
> the compressed file or is the the last 2 symbols that came out of
> the pure huffman part of ptogram before the file is actaully written.
> Assumming the latter and assuming the the patterrn has exactly 9 bits
> then they can't all be ones in this case and the file is wwritten out
> as is. But the fact that just becasue there are several possible bit
> patterns that can "span" the last two bytes does not mean that you
> have to always save the last byte to the file that is wasted space.
> If the last symbol spans two bytes I only write it to the file if
> the expansion part is not all ones and the prepart not all zeroes.
> Note this alone is not enough to guarantee that the moded Huffman
> compression is "one to one" You haave to play games with the TREE.
> Which adds nothing to space used since there are many trees that
> compress exactly the same.
In the detailed example I gave the 9 bits were 0 10111010. You
agreed above that these are all written out. So the 'correct' file
terminates there (with neither additions nor deletions that could
take place with your modified Huffman scheme in other more general
situations). Hence we don't have disagreement as to the content
of the last 2 bytes of the 'correct' output file. I must nevertheless
take this opportunity to say here that I have never understood
why you ever attempted to omit writing certain bits out at the end
of the process in case the (unmiodified original) Huffman algorithm
generate these. Why did you ever do modifications to a well-known
algorithm?? Why did you want to make the output file a (very) tiny
bit shorter at all?? Does the saving of one single byte count in
practice? How many bytes does an output file in practice have? Have
you ever computed for a concrete example in practice the percentage
of your 'saving'?? By how much have you complicated your program
logic through your persuit for this trivial 'economy'? Further,
since your device (modification) has not been discussed and examined
in the public, I can't even be sure that your modification is sound
theoretically. (Sorry to say that. Note that a discussion in the
public presupposes that you explain your modification either in plain
English or else in precise and short pseudo-code and not require
others to dig into your lenghty C code or, even worse, to simply run
tests with the program!)
> > Thus said, it should be clear that in my example the original file
> > will be encoded such that there is no filling bits (padding), nor
> > any of your mentioned 'deletions'. Hence I repeat that the last 2
> > bytes of the (correct) output file are exactly of the form
> > xxxxxxxy yyyyyyyy. (Any disagreements up to here???) To be concrete,
> > let's assume that these are xxxxxxx0 10111010. Now the 'wrong' file
> > is by constrution the correct file minus the last byte. Hence the
> > 'wrong' file terminates with xxxxxxx0. Let's now apply the Huffman
> > uncompressing algorithm parallely to both files and follow these two
> > processes step by step (side by side). All the steps are obviously
> > the same up to the point when the xxxxxxx above get processed
> > (decoded). (Do you agree??) Now the process handling the correct file
> So far we agree which I find truely amazing since we usually
> can't agree on anything. Maybe I think we agree but maybe we both
> interpt what you said above differently. In which case I can actaully
> only state if you mean what I mean by what you wrote in the preecding
> paaragraph we agree.
I have stated some questions in the preceeding paragraph. So I
expect some answers from you.
> > can further proceed. It finds first the 0 bit. Since 0 alone isn't
> > a valid code in our case (see below) it continues to fetch further
> > bits till a valid Huffman code is obtained -- in the present case it
> > happens (by construction) that it has to fetch exactly 8 more bits
> > in order to obtain a valid code. Thereafter it encounters the end
> > of file and terminates normally and correctly, there being no more
> > bits hanging unprocessed. (That 0 alone is not a valid Huffman code
> > in our case is because by our assumption there is a valid code
> > beginning with 0 and longer than 1 bit, namely 9 bits in total.
> > Do you agree with this?? If not, please say so!) On the other
> Only to the extent of my preceeding comment and to the assumption
> that your talking about the long case.
See my comment above and what follows.
> > hand, the other process similarly gets (after finishing with the x's)
> > the 0 bit. But this 0 is at the end of the (wrong) file processed by
> > it. As said above, 0 is not a valid Hoffman code. What should now this
> > process do in this situation??? I have in the previous post listed a
> > few possibilities, but unfortunately none of these is a 'normal'
> > termination!! Now please say clearly and directly what in your opinion
> > the process handing the 'wrong' file will do and how it can do that?
> > (Could it probably 'guess' the 8 bits that I have deleted or else do
> > anything else than the possible actions that I listed previously?????)
>
> in the above case the program would have noticed ( assuming we
> are looking at decompression now) that it got previously a valid
> symbol the x's. Since theer is still from 1 to 7 ( not eight ) bits
> left it checks to see if they are all zero. They are all zzero so
> the x's maarked the last symbol. I think you may be confused in
> that you think this is an error. It is not. In there two examples
> if you decompress them and recompress then you get the starting
> files back. There is still the preserve one to one ness of the
> compression decompression routines.
> Even though we went through this one example this time I bet
> you still don't have aa clue as to what I am talking aboutt.
> Sure I made a mess of english mistaaakes but you have an executabe
> you should have a hex dump and hex editor if not I can give you
> one. You can check this your self.
No, we can exercise with pencil and paper for this trivially simple
case, can't we????? As I explained, the 'wrong' file ends with the
byte xxxxxxx0. The process handling it, after having successfully
decoded away all bits including the x's, now picks up the 0. But
here it finds that the file ends. There are no further bits available!!
So why did you write 'there is still 1 to 7 bits left'??? There is
NOTHING left at this time point!! Hence it can't normally proceed
and must terminate abnormally!!
M. K. Shen
------------------------------
** 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
******************************
