Cryptography-Digest Digest #823, Volume #12 Tue, 3 Oct 00 07:13:00 EDT
Contents:
Re: Ciphers and Unicode and... (Guy Macon)
Re: My Theory... (David Rush)
Re: My Theory... (David Blackman)
Re: Another Rijndael/AES rumor (Jim Gillogly)
Re: Idea for Twofish and Serpent Teams (Mok-Kong Shen)
Re: It's Rijndael (Serge Paccalin)
Re: is NIST just nuts? (Jim Gillogly)
Re: is NIST just nuts? (Jim Gillogly)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Ciphers and Unicode and...
Date: 03 Oct 2000 09:43:22 GMT
This is a bit of a change of topic, but I am very interested in various
methods of representing information, and have created the following
document. (Section 10.0 touches on cryptography.) Comments welcome.
*************************************************************************
THIS IS A ROUGH DRAFT THAT I AM PASSING AROUND FOR COMMENTS. PLEASE EMAIL
FEEDBACK TO [EMAIL PROTECTED] SO THAT I CAN IMPROVE THIS DOCUMENT!!
*************************************************************************
0.0
Guy Macon's Documentation Standards
Revision 0.04
Guy Macon
11/3/2000
1.0
Purpose:
1.1
The purpose of this document is to define the data formats to be used in
Guy Macon's engineering projects.
2.0
Scope:
2.1
In most cases this document is advisory only. This document is mandatory
only in cases where an applicable Requirements Document makes conformance
to this document a requirement.
3.0
Overview:
3.1
Engineering documentation should be usable for a minimum of twenty years
so that we can support older equipment. In the case of patent litigation,
sufficient engineering documentation to prove prior art may be required
for as long as the patent holder exists. This requirement cannot be met
if we store our documents in data formats that are proprietary to a
specific vendor, have secret file structures, or are nonstandard in any
way. Our documents must survive even if our favorite software vendors go
out of business. (Care to try to edit a document stored in Wang,
Electric Pencil, WordStar, WordPerfect for DOS, or Lotus 123 formats?
All of them were market dominators in their day...) This document was
inspired by my experience with a company that has over 30,000 carefully
worded and formatted documents in WordPerfect 5.1 for DOS format.
4.0
Bad Formats:
4.1
The following formats are known to be proprietary, nonstandard, rare, too
new, or otherwise undesirable:
4.2
Graphics Interchange format (.gif):
GIF files are covered by a Unisys patent. After years of allowing free
use, Unisys/CompuServe started charging GIF users. This should be a
lesson for anyone who chooses a proprietary format as a "standard".
4.3
Microsoft Word (.doc), Excel (.xls). Write (.wri) Rich Text (.rtf),
Bitmap (.bmp), and other Microsoft proprietary formats.
Microsoft has a history of making new versions of their software that are
not backward and forward compatible with documents saved with older
versions of the same software. Converters are available for many (but not
all) older formats, but the conversions are one way. If John Doe using
Microsoft Write (.wri) under Windows 3.11 sends a document to Jane Doe who
uses Windows NT 4.0, Jane cannot edit the document. Instead, a conversion
takes place and the document is converted into WordPad format. WordPad
cannot save in Write format. This means that Jane cannot make a
correction to John's document without making the document unreadable on
John's computer. These situations can be triggered by an upgrade to an
application or even by applying the latest Service Pack. Word, Excel,
Rich Text, etc, all lack forward/backward compatibility with older
versions of the same format. In many cases there is no apparent reason
to change the file format except as a method of forcing users to upgrade.
Conversion programs appear to be purposely made to be imperfect and
formatting is often changed by them.
4.4
Non-standard HTML as used by Netscape Navigator and Microsoft Internet
Explorer.
Both corporations are attempting to fill the Internet with documents that
can only be viewed with their software. long term archivability is not a
priority for either corporation - in fact they both have a business model
that profits from forcing document authors to follow shifting standards.
4.5
Extensible Markup Language (.xml) WWW Consortium Recommendation.
This may be the format of the future, but it's too new for us to adopt it
at this time.
4.6
Standard Generalized Markup Language (.sgml).
SGML is the basis of HTML and XML, and can be used to create a wide variety
of incompatible file formats. For our purposes the HTML subset of XML will
suffice.
4.7
Adobe Acrobat (.pdf) format
PDF lacks forward and backward compatibility - you need the latest acrobat
reader to read the latest .pdf files. In many cases the latest version of
acrobat reader will not run on older hardware. Alas, there is no current
standard that will work as a direct replacement for the Adobe proprietary
PDF format.
4.8
Joint Photographic Experts Group, all implementations except JFIF
Strictly speaking, JPEG refers only to a family of compression algorithms;
it does *not* refer to a specific image file format. The JPEG committee
was prevented from defining a file format by turf wars within the
international standards organizations. In the absence of official
standards, a number of JPEG program writers have written incompatible
implementations and as a result their programs aren't 100% compatible
with anyone else's. The closest thing we have to a standard JPEG format
is JFIF (JPEG File Interchange Format).
4.9
TIFF (.tff)
The TIFF 6.0 spec for incorporating JPEG is not widely implemented, partly
because it has some serious design flaws. NextStep systems are the only
ones making any significant use of TIFF 6.0 style TIFF/JPEG. TIFF is far
more complex than JFIF, and is generally less transportable because
different vendors often implement slightly different, non-overlapping
subsets of TIFF.
4.10
PNG (Portable Network Graphics) Specification
PNG is defined in W3C Recommendation RFC-2083 and is on a standards track
under the purview of ISO/IEC JTC 1 SC 24 and is expected to be released
eventually as ISO/IEC International Standard 15948. It is intent of the
standards bodies to maintain backward compatibility with the current PNG
specification. I will consider adding it to my approved formats list when
and if the standard is approved. PNG seems to be better designed than most
other formats - if and when it is a standard, I will likely want to make it
one of my preferred standards.
4.11
Any document that contains macros, scripts, Java objects, or any other
executable objects.
Macros, scripts, etc. mean that you must not only read the file, but also
execute some code. This decreases the chances that the document will be
usable years from now. In addition, macros, scripts, etc. are a security
problem, and may contain worms, viruses, or data bombs.
4.12
Any document that loses information when displayed, printed, or copied on
a monochrome device.
Meeting this requirement can be as simple as putting a small print "RED"
in the corner of a red colored box. Failure to make documents monochrome
friendly causes problems for users who lack color copy machines, and is a
violation of the Americans with Disabilities (ADA) act as it applies to
the colorblind and visually impaired.
6.0
Good Formats:
6.1
The following formats are known to be standard, and are acceptable for
use in engineering documentation.
6.2
ASCII (American Standard Code for Information Interchange) as defined in
ANSI_X3.4-1968, ANSI_X3.110-1983, ISO-IR-99, CSA_T500-1983 and ISO 8859-1.
This is the preferred format for purely textual information, and is the
most universal of all standards. Use it whenever possible.
6.2.0 ASCII Rules:
6.2.1
The subset of ASCII to be used shall use only the following characters.
NULL and TAB characters are interpreted differently on different systems
and shall not be used.
Table 1: Allowable ASCII characters with ANSI names
Char Hex Name Char Hex Name
0A LINE FEED (LF) 0D CARRIAGE RETURN (CR)
< > 20 SPACE <!> 21 EXCLAMATION MARK
<"> 22 QUOTATION MARK <#> 23 OCTOTHORPE
<$> 24 DOLLAR SIGN <%> 25 PERCENT SIGN
<&> 26 AMPERSAND <'> 27 APOSTROPHE
<(> 28 LEFT PARENTHESIS <)> 29 RIGHT PARENTHESIS
<*> 2A ASTERISK <+> 2B PLUS SIGN
<,> 2C COMMA <-> 2D HYPHEN-MINUS
<.> 2E PERIOD </> 2F FORWARD SLASH
<0-9> 30-39 NUMBERS <:> 3A COLON
<;> 3B SEMICOLON <<> 3C LESS-THAN SIGN
<=> 3D EQUALS SIGN <>> 3E GREATER-THAN SIGN
<?> 3F QUESTION MARK <@> 40 COMMERCIAL AT
<A-Z> 41-5A CAPITAL LETTERS <[> 5B LEFT SQUARE BRACKET
<\> 5C REVERSE SLASH <]> 5D RIGHT SQUARE BRACKET
<^> 5E CIRCUMFLEX ACCENT <_> 5F LOW LINE
<`> 60 GRAVE ACCENT <a-z> 61-7A LOWER CASE LETTERS
<{> 7B LEFT CURLY BRACKET <|> 7C VERTICAL LINE
<}> 7D RIGHT CURLY BRACKET <~> 7E TILDE
Please note that ASCII does not have characters such as "Underscore".
(Underscore is an attribute like Bold or Italic. It resembles Low
Line when applied to a Space character) or "Dash" (En-dash is as wide
as the letter "n", Em-dash is as wide as the letter "M" - concepts that
only apply to proportional fonts. ASCII is a character set, not a Font.)
Use Hyphen-Minus instead of "Dash".
6.2.2
In released documents each line shall be less than 78 printable characters
long (75 is preferred), left justified, and without hyphenation. Please
note that modern text editors such as UltraEdit will convert this format
to and from long line format (no line feed or carriage return until end of
paragraph) for more convenient editing, and that the long line format is
preferred for unreleased drafts, except when posted to USENET.
6.2.3
Each line shall be terminated with one of the following sequences,
in descending order of preference:
Carriage Return followed by Line Feed
Line Feed followed by a Carriage Return
Carriage Return alone
Line Feed alone
Software developers are encouraged to write code that outputs lines with
Carriage Return followed by Line Feed, and that accepts input with any of
the above line termination sequences.
6.2.4
Two spaces between sentences and no trailing spaces are preferred but
not required.
6.2.5
If possible, ASCII documents should be printed with a non-proportional
font (10, 11, or 12 point Courier or Courier New preferred) without bold,
italic, or underline attributes.
6.3
HyperText Markup Language (.htm .html)
6.3.0
HTML Rules:
6.3.1
The approved version of HTML is the version defined in rfc1866 from the
W3C Network Working Group. HTML is an application of ISO Standard
8879:1986 Information Processing Text and Office Systems; Standard
Generalized Markup Language (SGML).
6.3.2
Nonstandard extensions and implementations such as the ones used in
in Netscape Navigator and Microsoft Internet Explorer are not allowed.
6.4
Independent JPEG Group JFIF (commonly misnamed "JPEG") as defined in
Annex B of ISO DIS 10918-1.
JPEG is not a file format. JPEG is a compression scheme. JPEG File
Interchange Format (JFIF) is a file format which allows JPEG images
to be exchanged between a wide variety of platforms and applications.
Nearly all files on the Internet that are called "JPEG" are really JFIF
files.
6.5
Computer Graphics Metafile (.cgm) as defined in ANSI X3.122-1986 and
8632:1992 Parts 1-4, Version 1 CGM only.
Computer Graphics Metafile can handle vector graphics and images. It
stores pictures in a way which is independent of any particular software,
computer or graphics device. CGM offers the first standard method of
storing a vector-based image type. Vector images allow for greater detail
and clarity at multiple zoom levels. Also, they are usually much more
compact than the equivalent bitmap. CGM is used by a number of other
standards including the Office Document Architecture (ODA) standard, ATA
within the commercial aviation industry, J2008 within the automotive
industry and the CALS (Computer-aided Acquisition and Logistics Support)
US Dept of Defense specification.
6.0
Revision Control:
6.1
All engineering documents shall be archived on a network file server
in such a way that no single or double failure will make the document
permanently unavailable. The electronic file on the file server shall
be considered to be the current version. All paper copies are to be
considered to be out of date and obsolete at the moment of printing.
The best that you say about the paper copy is that it was the latest
version several seconds ago.
6.2
All printed copies should contain automatically computer generated time
stamps. Any changes to a document should automatically result in a new
time stamp. Updating of revision numbers is at the discretion of the
author - readers shall consider the timestamp authoritative and the
revision level to be advisory only.
7.0
Working with nonconforming file formats:
7.1
It is inevitable that some engineers will use applications that have
nonstandard file formats. There are too many useful tools that are
proprietary. When nonstandard file formats are used, the engineer shall
do the following before releasing the document:
7.1.0
Save the file in as many formats as possible.
7.1.1
Give serious consideration to creating a standard document that shows the
same information.
7.1.2
Store the document on as many media as possible. An ASCII file on
an 8 inch disk formatted for Kaypro CP/M is hard to read on a PC
with CD-ROM and 3.5" floppy. Be sure to store copies on as many
servers as possible, as server data tends to be backed up and to
get transferred as new computers and media formats are added to the
organization.
7.1.3
Make nine hard copies on acid free paper (vellum or Mylar preferred) with
archive quality ink and store three copies in each of three different
locations. Make microfilm copies if you can.
8.0 Revision History:
08/10/1999: Revision 0.00 - Initial prerelease
04/15/2000: Revision 0.01 - Minor edits, put bad formats section above
good format section.
04/17/2000: Revision 0.02 - Added section of media formats and things
that I haven't decided on yet.
11/03/2000: Revision 0.04 - Added mention of Unicode and UTF, added
reference to Gnu CopyLeft FDL.
9.0 Copyright:
Copyright (c) 2000 Guy Macon
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation.
A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.
The author grants everyone permission to use this document for any purpose,
as long as proper credit is given on any copy that is posted to the
Internet.
For personal or corporate use, permission is granted to pretend that this
is your own work, with or without modifications. If you modify it, I would
appreciate it if you emailed me a copy - I might want to incorporate your
changes.
10.0 Things I haven't decided on yet - discussion welcome!
Postscript and Encapsulated postscript.
Unicode, Unicode UTF-8 encoding, Java UTF-8 encoding
Tex and LaTex
A method of enciphering data that is likely to be available 20
years from now, plus a way of not losing or revealing the
passphrase over 20 years.
1 2 3 4 5 6 7
123456789012345678901234567890123456789012345678901234567890123456789012345
(Guide to help me to stay below 75 characters/line - to be removed later)
*************************************************************************
THIS IS A ROUGH DRAFT THAT I AM PASSING AROUND FOR COMMENTS. PLEASE EMAIL
FEEDBACK TO [EMAIL PROTECTED] SO THAT I CAN IMPROVE THIS DOCUMENT!!
*************************************************************************
------------------------------
From: David Rush <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: 03 Oct 2000 10:51:52 +0100
"Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:8rb78n$ijl$[EMAIL PROTECTED]...
> > So the millions of 32-bit i386+ chips are not included in this
> > thought? Also how slow is Twofish on a ia64 anyways?
>
> Since I happen to have on hand the figures from a paper presented at AES3:
>
> On an IA-64 simulator (an actual CPU was not available),
That is such bullshit. At the least, SourceForge has an Itanium in
it's compile farm, and I'm quite sure that they would have allowed
it's usage to benchmark the candidates. Are you trying to say that
NIST couldn't get an IA-64 box w/Linux for themselves?
I mean, incompentence *is* a significant factor in the US Gov, but
this is a bit beyond belief.
david rush
--
Thieves respect property. They merely wish the property to become
their property that they may more perfectly respect it.
-- The Man Who Was Thursday (G. K. Chesterton)
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: My Theory...
Date: Tue, 03 Oct 2000 21:12:04 +1100
David Rush wrote:
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > news:8rb78n$ijl$[EMAIL PROTECTED]...
> > > So the millions of 32-bit i386+ chips are not included in this
> > > thought? Also how slow is Twofish on a ia64 anyways?
> >
> > Since I happen to have on hand the figures from a paper presented at AES3:
> >
> > On an IA-64 simulator (an actual CPU was not available),
>
> That is such bullshit. At the least, SourceForge has an Itanium in
> it's compile farm, and I'm quite sure that they would have allowed
> it's usage to benchmark the candidates. Are you trying to say that
> NIST couldn't get an IA-64 box w/Linux for themselves?
>
> I mean, incompentence *is* a significant factor in the US Gov, but
> this is a bit beyond belief.
>
> david rush
Read it again, loser. "a paper presented at AES3". IE, some researcher,
who is probably at some obscure university or company that Intel has
never heard of, did the testing and presented the results to the AES3
conference. NIST could probably get hold of an Itanium if they really
wanted to, but some random researcher would find it more difficult.
You could reasonably ask why NIST relied on outside researchers to do
most of the testing and analysis, instead of doing it all in-house.
There are reasonable answers to this question, but you're such an
arrogant loser that you probably don't want to know.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Another Rijndael/AES rumor
Date: Tue, 03 Oct 2000 10:31:27 +0000
Paul Rubin wrote:
>
> This came through an anonymous remailer to the cyphperpunks list a
> few days ago:
>
> At 9:50 PM +0200 9/30/2000, Nomen Nescio wrote:
> >1. There is a single winner.
> >2. It is not an American design.
> >If so, this rules out MARS, RC6, and Twofish. But now comes the
> >third rumor:
> >3. The winner is not covered by any patent or patent claim
> >identified or disclosed to NIST by interested parties.
>
> >Assuming this is true, there is only one algorithm that is not
> >explicitly mentioned in Hitachi's claim: Rijndael.
>
> This makes it plausible that staying away from patents was a factor in
> Rijndael's selection.
The NIST report (yes, I know it's fat) talks about IP attacks without
mentioning Hitachi by name in Section 4, Intellectual Property Issues.
The conclusion is:
After comments were analyzed, and the review process was completed,
IP was not a factor in NIST's selection of the proposed AES algorithm.
Consistent with its practice for FIPS, however NIST intends to state
in the proposed AES FIPS that U.S. and foreign patents may cover
cryptographic devices implementing the standard.
This looks to me like NIST's IP review decided the Hitachi claim was
not a credible attack. While "Nomen Nescio" may indeed have gotten
hold of a real rumor, his/her conclusion that it had to be Rijndael
rather than Serpent may not have been justified.
--
Jim Gillogly
Hevensday, 12 Winterfilth S.R. 2000, 10:20
12.19.7.10.16, 12 Cib 19 Chen, Ninth Lord of Night
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Idea for Twofish and Serpent Teams
Date: Tue, 03 Oct 2000 12:44:48 +0200
Helger Lipmaa wrote:
>
> Tom St Denis wrote:
>
> > Do what RSA did and make your own "Symmetric Cipher Standards" and
> > ignore the govt.
> >
> > Tom
>
> There was a thread recently in this newsgroup, about the general
> attitude that guys who understand nothing about security try to strut
> and to demand and to insult those who know better.
And to give advices to those who know better.
M. K. Shen
------------------------------
From: Serge Paccalin <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Tue, 3 Oct 2000 12:43:26 +0200
On/Le Tue, 03 Oct 2000 00:55:32 GMT,
[EMAIL PROTECTED] wrote/a �crit
in/dans sci.crypt...
> On Mon, 2 Oct 2000 18:16:58 +0200, Serge Paccalin
> <[EMAIL PROTECTED]> wrote, in part:
>
> >Just a question: since they chose a Belgian algorithm, will they
> >have the nerve to forbid its export?
>
> The export of the algorithm from Belgium is OK. Export of products
> *made in the US* _using_ that algorithm will, indeed, be restricted as
> per usual.
So, the US authorities still think that people that can design a
fairly good encryption algorithm cannot implement it in a working
product? :-)
> Although the US restrictions are now not what they were.
Fortunately.
--
___________
_/ _ \_`_`_`_) Serge PACCALIN
\ \_L_) [EMAIL PROTECTED]
-'(__) L'hypoth�se la plus �labor�e ne saurait remplacer
_/___(_) la r�alit� la plus bancale. -- San-Antonio (1921-2000)
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Tue, 03 Oct 2000 10:51:30 +0000
"Herbie T. Mac" wrote:
> As far as shortening the key length from 64 to 56 bits, that too
> *strengthened* the algorithm with respect to DES' differential
> vulnerability. 64-bit DES is equally as difficult to crack using
> differential cryptanalysis as 56-bit. The change made DES faster
> (encryption) while not compromising the intended security or reducing the
> time it took the NSA to crack it (assuming they ever bothered).
>
> They did us a tremendous favor, given the absurd amount of time the DES
> has been used.
I disagree. The linear and differential attacks require a lot
of information to execute: 2^43 or 2^47 chosen plaintexts. In
practice this severely limits the applicability of the attack.
While the differential attack is certainly of great theoretical
interest, in practice it's far more difficult to execute than
a 2^56 brute force key search. Note that differential analysis
would not have broken the RSA challenges, for example -- only
three blocks of known plaintext were available in each case,
and no chosen plaintext. Similarly, Stage 9 of Simon Singh's
challenge in "The Code Book" had no known plaintext, much less
chosen plaintext. These are much closer to the situation
pertaining in the real world.
If the DES key had been left at 64 bits, the EFF machine Deep
Crack would require over a year for a sure crack, rather than
two days with the 56-bit DES key. A much more expensive machine
would need to be constructed for 64 bits -- one that might be
out of the range of a non-profit organization.
I'd much rather have the protection of a 64-bit cipher with
a DC attack of 2^47 chosen plaintexts than a 56-bit cipher
with the same DC resistance.
If this is a favor, I certainly hope they don't do us any more
of them.
--
Jim Gillogly
Hevensday, 12 Winterfilth S.R. 2000, 10:33
12.19.7.10.16, 12 Cib 19 Chen, Ninth Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: is NIST just nuts?
Date: Tue, 03 Oct 2000 11:05:58 +0000
Oh, and another thing.
"Herbie T. Mac" wrote:
> As far as shortening the key length from 64 to 56 bits, that too
> *strengthened* the algorithm with respect to DES' differential
> vulnerability. 64-bit DES is equally as difficult to crack using
> differential cryptanalysis as 56-bit. The change made DES faster
> (encryption) while not compromising the intended security or ...
How do you figure reducing the key from 64 to 56 bits made DES
faster? It's just a matter of using all 64 supplied bits in the
key schedule instead of ignoring or (worse) checking the "parity"
bits, so even the key setup time needn't be any different.
--
Jim Gillogly
Hevensday, 12 Winterfilth S.R. 2000, 11:01
12.19.7.10.16, 12 Cib 19 Chen, Ninth Lord of Night
------------------------------
** 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
******************************
