Cryptography-Digest Digest #867, Volume #12 Sat, 7 Oct 00 21:13:01 EDT
Contents:
Re: Signature size ("Joseph Ashwood")
Re: It's Rijndael (Sam I am)
Re: Choice of public exponent in RSA signatures (DJohn37050)
Re: Block Cipher Question (Tim Tyler)
Re: Mr. Zimmermann, Mr. Price when can we expect this feature ? (Rich Wales)
Re: Deadline for AES... (Mok-Kong Shen)
Re: Advanced Encryption Standard - winner is Rijndael (Anonymous)
Re: Advanced Encryption Standard - winner is Rijndael (David Schwartz)
Re: Advanced Encryption Standard - winner is Rijndael (David Schwartz)
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Signature size
Date: Fri, 6 Oct 2000 17:04:57 -0500
> > > ... in which all but 32 bits are chosen by the
attacker.
>
> > Exactly, but since the instruction is known to be
32-bits,
> > the instruction itself is fixed.
>
> I don't see what you're getting at here. Either the
message is <= 32 bits
> and there is no need to use a CRC, or it is greater than
32 bits, and
> the attack I posted applies. In either case, using a CRC
in the way you
> described is a bad idea.
I was encouraging the use of the CRC as a check for whether
or not the package had been tampered with basically by
expanding the instruction to 64-bits in some deterministic
way. Because the CRC would be encrypted in the same block as
the instruction it can be considered to be a tamper evident
system, or more accurately as a sparse mapping of 32-bit
instructions to a 64-bit space, with internal methods of
detecting probable tampering (as opposed to padding with
random numbers), the goal was to certify the instruction,
and with a shared secret CRC polynomial it can be determined
(as long as not a single block is compromised). There are
other methods, and some better methods, but given what I
took to be the original posters level of knowledge, I didn't
think tamper-resilient codes were necessarily within the
available options.
Joe
------------------------------
From: Sam I am <[EMAIL PROTECTED]>
Subject: Re: It's Rijndael
Date: Sat, 07 Oct 2000 15:09:19 -0700
On Sat, 07 Oct 2000 15:55:40 GMT, [EMAIL PROTECTED] wrote:
> Two bits of wisdom:
>
> 1. <snip>
>
> 2. If naked AES is used, why not always use 256 bit keys? I don't
> really buy the efficiency argument. Show me exactly where the slightly
> greater work factor for handling larger keys is really significant?
> Possibly there are some cases, so let them worry about what to do or
> how to inter-operate with the rest of the world that sticks to 256
> bits. As a relative outsider, I always find it strange how
> cryptologists worry about bits as if they were worth their weight in
> gold. Maybe this is a meme remnant of a time decades ago where crypto
> was always done in hardware and where CPUs were rare and expensive
> thing.
The answer to your question is that in some systems AES at 128-bits will
be a burden on available compute power, and requiring more rounds would
just increase this burden. For example, in the real-time industrial
control environment, most of the process-connected equipment is required
to operate and communicate on less than 40 mW -- perhaps 1/1000 the power
used by a typical notebook computer. This is not an arbitrary power
limit; it is established by the ignition properties of H2 and similar
explosive substances, and by the need for multiple pieces of equipment to
share the same buried kilometer-long twisted pair (which carries both
power and signal ling).
Historically this market has used near-d.c. 4-20 mA point-to-point analog
signaling. Today it is transitioning to digital multi-drop bus
structures. Unfortunately, the higher signaling frequencies of digital
systems makes "outside-the-fence" eavesdropping possible. The
commoditization of such networks also facilitates surreptitious taps and
therefore wholesale eavesdropping and command spoofing. Thus there is a
need for confidentiality of economically valuable data, as well as for
authentication of potentially dangerous commands.
Rijndael and Twofish were the two round-2 candidates that best met the
needs of this market. We are very happy with the NIST choice, and have
told them so.
Tom Phinney
US Technical Advisor for IEC/SC 65C (industrial communications standards)
Convenor, IEC/SC 65C/WG 1 and /MT 9 (fieldbus standards)
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Choice of public exponent in RSA signatures
Date: 07 Oct 2000 22:54:09 GMT
PSS is in P!363a which is a draft. not in P1363, which is a standard.
Don Johnson
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Block Cipher Question
Reply-To: [EMAIL PROTECTED]
Date: Sat, 7 Oct 2000 22:31:13 GMT
musashi_x <m u s a s h i _ [EMAIL PROTECTED]> wrote:
: Something got me thinking recently...(I am, of course, a crypto-newbie). I
: have a question about CBC output. If you were to encrypt something with,
: say, Blowfish in cipher block chaining mode and then remove the first 7
: characters of the output, wouldn't that make cryptoanalysis a great deal
: harder? From what I understand every block is dependent/related to the
: first block, so wouldn't keeping the first 7 characters either altered or
: missing (until end-recipient manually adds them in) really screw things up
: for analysis?
This sounds very similar to using an IV.
I can't see any great advantages over using an IV. Can you?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp,alt.security.scramdisk
Subject: Re: Mr. Zimmermann, Mr. Price when can we expect this feature ?
Date: 7 Oct 2000 23:09:11 -0000
I tried posting something on this topic yesterday, but it didn't show
up on Deja.com. I suspect a large block of armored PGP text in my
posting may have tripped a "no binaries" filter, so I'm going to try
again (for the record).
"pgp651" wrote:
> We should have now OFFICIALLY this option from NAI in PGP,
> in PGP v262
As I noted a few days ago, it is probably futile to expect NAI to
offer =any= changes to PGP 2.6.2 (an old version which predates both
PGP Inc. and NAI's acquisition of PGP Inc.).
However, I agree with the concept that a widely respected descendant
of 2.6.2 with support for larger RSA keys (for those who wish to use
them) ought to become available.
To that end, I'm offering (below) my own patch to PGP 2.6.3ia (the
"international" version which has been on www.pgpi.org since 1996).
This patch is simple enough that, if you trust 2.6.3ia, presumably
you'll also trust the result of the patch.
I've also uploaded this patch, as well as a gzip'ed, signed copy of
the patch, to my Web site; you can find them at:
http://www.webcom.com/richw/pgp/263i-4k-patch (plain text)
http://www.webcom.com/richw/pgp/263i-4k-patch-gz.asc (gzip/signed)
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
========================================================================
The following patches will allow PGP 2.6.3ia to generate and process
RSA keys up to 4,096 bits in length.
The old warning about PGP 2.6.3ia not being for use in the USA has
also been removed, now that the RSA patent has expired.
These changes are effective ONLY if the source is NOT compiled with
the "-DUSA" option.
I believe these patches are bug-free, but I accept no liability; use
the patched version at your own risk.
The PGP 2.6.3ia source can be found on www.pgpi.org (the "International
PGP" site run by St�le Schumacher in Norway). It's called "2.6.3i"
on this site, but it includes a set of bug fixes from March 1996 which
are described at: http://www.pgpi.org/files/pgp263ia-patch.shtml
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
########################################################################
--- src/mpilib.h.orig Tue Aug 29 05:03:30 1995
+++ src/mpilib.h Fri Oct 6 09:08:35 2000
@@ -321,7 +321,15 @@
#endif /* mp_smul */
#define MIN_KEY_BITS 384
+#ifdef USA
#define MAX_KEY_BITS 2048
+#else /* USA */
+/*
+ * MAX_KEY_BITS changed from 2048 to 4096
+ * by Rich Wales <[EMAIL PROTECTED]>, 06oct2000
+ */
+#define MAX_KEY_BITS 4096
+#endif /* USA */
/* MAX_BIT_PRECISION is upper limit that assembly primitives can handle.
It must be less than 32704 bits, or 4088 bytes. It should be an
--- src/randpool.h.orig Fri Jul 15 05:59:32 1994
+++ src/randpool.h Fri Oct 6 09:08:38 2000
@@ -1,7 +1,15 @@
#include "usuals.h"
/* Set this to whatever you need (must be > 512) */
+#ifdef USA
#define RANDPOOLBITS 3072
+#else /* USA */
+/*
+ * RANDPOOLBITS changed from 3072 to 10240
+ * by Rich Wales <[EMAIL PROTECTED]>, 06oct2000
+ */
+#define RANDPOOLBITS 10240
+#endif /* USA */
void randPoolStir(void);
void randPoolAddBytes(byte const *buf, unsigned len);
--- src/pgp.c.orig Wed Apr 24 10:34:19 1996
+++ src/pgp.c Fri Oct 6 09:09:59 2000
@@ -101,6 +101,7 @@
Version 2.6.2i - 7 May 95
Version 2.6.3(i) - 18 Jan 96
Version 2.6.3(i)a - 4 Mar 96
+ Version 2.6.3(i)a+4K - 6 Oct 00 - [EMAIL PROTECTED]
*/
@@ -193,7 +194,7 @@
" Amiga 68000 version by Rob Knop <[EMAIL PROTECTED]>";
# endif
#else
-static const char __DOSVer[] = "$VER: PGP 2.6.3ia (04.03.96)"
+static const char __DOSVer[] = "$VER: PGP 2.6.3ia+4K (06.10.00)"
# ifdef _M68020
" Amiga 68020 version by Peter Simons <[EMAIL PROTECTED]>";
# else
@@ -205,10 +206,11 @@
/* Global filenames and system-wide file extensions... */
#ifdef USA
char rel_version[] = _LANG("2.6.3a"); /* release version */
-#else
-char rel_version[] = _LANG("2.6.3ia"); /* release version */
-#endif
char rel_date[] = "1996-03-04"; /* release date */
+#else /* USA */
+char rel_version[] = _LANG("2.6.3ia+4K"); /* release version */
+char rel_date[] = "2000-10-06"; /* release date */
+#endif /* USA */
char PGP_EXTENSION[] = ".pgp";
char ASC_EXTENSION[] = ".asc";
char SIG_EXTENSION[] = ".sig";
@@ -390,13 +392,15 @@
#ifdef USA
fputs(LANG(signon_legalese), stderr);
#endif
- fputs(
#ifdef USA
+ fputs(
LANG("Export of this software may be restricted by the U.S. government.\n"),
-#else
-LANG("International version - not for use in the USA. Does not use RSAREF.\n"),
-#endif
+ /*
+ * Non-RSAREF warning removed (now that RSA patent has expired)
+ * by Rich Wales <[EMAIL PROTECTED]>, 06oct2000
+ */
stderr);
+#endif
get_timestamp((byte *) & tstamp); /* timestamp points to tstamp */
fprintf(pgpout, LANG("Current time: %s\n"), ctdate(&tstamp));
========================================================================
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Deadline for AES...
Date: Sun, 08 Oct 2000 02:17:35 +0200
David Hopwood schrieb:
>
> Mok-Kong Shen wrote:
> > David Crick wrote:
> > > Mok-Kong Shen wrote:
> > > >
> > > > > Would you please point out what is incomplete in the
> > > > > documentation of *any* of the finalists?
> > > >
> > > > The most conspicuous one and about which I have the
> > > > most concern is that there are lots of numbers (numerical
> > > > constants) whose derivation is not clear to the reader,
> > > > i.e. these cannot be reproduced by them in some way. This
> > > > provides an essential ground to nurish doubts about the
> > > > absence of backdoors. Certainly it hinders a proper
> > > > understanding and hence probably also analysis.
> > >
> > > Section 7 of the Rijndael submission document explains the
> > > reasons for the design choices. Is there anything in there
> > > that you are not happy with?
> >
> > I want specifically to be able to re-calculate every
> > number that is in a cipher.
>
> As far as I can see this is satisfied for Rijndael. What specific
> number do you think can't be recalculated?
>
> > If certain groups of numbers
> > are said to have been chosen to lead to a certain property,
> > I like to be able to run a program to verify that that
> > property is indeed (optimally) achieved.
>
> Section 7 and the sources it references ([LiNi86] and [Ny94])
> provide enough information to do that.
By recalculation I mean one has to start from some
concepts of the author of a cipher and obtain certain
numbers the same as given and 'only' these numbers.
I have currently only the AES document. Could you please
tell how the affine transformation of ByteSub is arrived
at, i.e. why is this particular transformation chosen?
Thanks.
M. K. Shen
------------------------------
Date: Sat, 07 Oct 2000 17:32:46 -0700
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
From: Anonymous <[EMAIL PROTECTED]>
Is there truly ANYONE stupid enough to believe ANY government would
adopt an encryption standard that DIDN'T have a back door for unlimited
government access?!?!?!
This is just the software version of the "clipper" chip- only >this
time<, the government didn't repeat their earlier mistake of admitting
they have the capability to easily decrypt the data.
But in all fairness, the US government >has< established itself as a
decade-long enemy of encryption that they can't easily decrypt.
It's a safe bet the government chose the Rijndael encryption method
because they can >already< decrypt it.
jungle wrote:
>
> FOR IMMEDIATE RELEASE: Oct. 2, 2000
>
> Contact: Philip Bulman (301) 975-5661 G 2000-176
>
> A worldwide competition to develop a new encryption technique that can be used
> to protect computerized information ended today when Secretary of Commerce
> Norman Y. Mineta announced the nation's proposed new Advanced Encryption
> Standard.
>
> Mineta named the Rijndael (pronounced Rhine-doll) data encryption formula as
> the winner of a three-year competition involving some of the world's leading
> cryptographers.
>
> "Once final, this standard will serve as a critical computer security tool
> supporting the rapid growth of electronic commerce," Mineta said. "This is a
> very significant step toward creating a more secure digital economy. It will
> allow e-commerce and e-government to flourish safely, creating new
> opportunities for all Americans," he said.
>
> Computer scientists at the National Institute of Standards and Technology, an
> agency of the Commerce Department's Technology Administration, organized the
> international competition in a drive to develop a strong information encryption
> formula to protect sensitive information in federal computer systems. Many
> businesses are expected to use the AES as well.
>
> The proposed selection of Rijndael as the AES will be formally announced in
> the Federal Register in several months, and NIST then will receive public
> comments on the draft Federal Information Processing Standard for 90 days.
>
> Researchers from 12 different countries worked on developing advanced encoding
> methods during the global competition.
>
> NIST invited the worldwide cryptographic community to "attack" the encryption
> formulas in an effort to break the codes.
>
> After narrowing the field down from 15 formulas to five, NIST invited
> cryptographers to intensify their attacks on the finalists. The agency and the
> world cryptographic community also evaluated the encoding formulas for factors
> such as security, speed and versatility.
>
> The Rijndael developers are Belgian cryptographers Joan Daemen (pronounced
> Yo'-ahn Dah'-mun) of Proton World International and Vincent Rijmen (pronounced
> Rye'-mun) of Katholieke Universiteit Leuven. Both are highly regarded experts
> within the international cryptographic community.
>
> NIST organized and managed the competition with considerable private-sector
> cooperation.
>
> The competing AES candidates were sophisticated mathematical formulas called
> algorithms. Algorithms are at the heart of computerized encryption systems,
> which encode everything from electronic mail to the secret personal
> identification numbers, or PINs, that people use with bank teller machines.
>
> When approved, the AES will be a public algorithm designed to protect
> sensitive government information well into the 21st century. It will replace
> the aging Data Encryption Standard, which NIST adopted in 1977 as a Federal
> Information Processing Standard used by federal agencies to protect sensitive,
> unclassified information.
>
> DES and a variant called Triple DES are used widely in the private sector as
> well, especially in the financial services industry.
>
> The effort to establish the AES reflects the dramatic transformation that
> cryptography has undergone in recent years.
>
> Just a few decades ago the science of cryptography was an esoteric endeavor
> employed primarily by governments to protect state and military secrets. Today,
> millions of Americans use cryptography, often without knowing it. Most people
> who use automated teller machines have used cryptography because the secret
> PINs required by the machines are encrypted before being sent to a computer
> that makes sure the number matches the card.
>
> Others use information encryption when they make a purchase over the Internet.
> Their credit card numbers are encrypted when they place an order.
>
> Hundreds of encryption products currently employ DES or Triple DES, and such
> systems have become almost ubiquitous in the financial services industry.
> Consequently, the selection of the AES may affect millions of consumers and
> businesses.
>
> NIST requested proposals for the AES on Sept. 12, 1997, and a variety of
> organizations around the world responded with enthusiasm. Each of the candidate
> algorithms was required to support key sizes of 128, 192 and 256 bits. For a
> 128-bit key size, there are approximately
> 340,000,000,000,000,000,000,000,000,000,000, 000,000 (340 followed by 36 zeros)
> possible keys.
>
> NIST evaluated the candidate algorithms and received invaluable assistance
> from cryptographers at computer security companies and universities around the
> world. Good security was the primary quality required of the winning formula,
> but factors such as speed and versatility across a variety of computer
> platforms also were considered. In other words, the algorithms must be able to
> run securely and efficiently on large computers, desktop computers and even
> small devices such as smart cards.
>
> NIST and leading cryptographers from around the world found that all five
> finalist algorithms had a very high degree of security. Rijndael was selected
> because it had the best combination of security, performance, efficiency,
> implementability and flexibility.
>
> The AES competition was organized by computer scientists in NIST's Information
> Technology Laboratory. A lengthy technical analysis of the AES candidates is
> being posted on NIST's web site today at www.nist.gov/aes.
>
> After the public comment period, NIST will revise the proposed standard�if
> appropriate�and submit it to the Secretary of Commerce for adoption as an
> official federal standard. This process is expected to be complete by the
> spring of 2001.
>
> Press contacts for the Rijndael team:
>
> Joan Daemen Tel: +32 2 724 55 08, Fax: +32 2 727 62 50 [EMAIL PROTECTED]
>
> Vincent Rijmen Tel: +32 16 32 18 62, Fax: +32 16 32 19 86
> [EMAIL PROTECTED]
>
> read all at http://www.nist.gov/public_affairs/releases/g00-176.htm
--------== Posted Anonymously via Newsfeeds.Com ==-------
Featuring the worlds only Anonymous Usenet Server
-----------== http://www.newsfeeds.com ==----------
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Sat, 07 Oct 2000 17:50:23 -0700
Anonymous wrote:
>
> Is there truly ANYONE stupid enough to believe ANY government would
> adopt an encryption standard that DIDN'T have a back door for unlimited
> government access?!?!?!
> This is just the software version of the "clipper" chip- only >this
> time<, the government didn't repeat their earlier mistake of admitting
> they have the capability to easily decrypt the data.
> But in all fairness, the US government >has< established itself as a
> decade-long enemy of encryption that they can't easily decrypt.
> It's a safe bet the government chose the Rijndael encryption method
> because they can >already< decrypt it.
So what good would this do them? They couldn't, for example, admit
decrypted data into evidence because that would make it obvious that
they could break the cipher. They couldn't even use the information
indirectly to aid prosecution, because that would mean an ever-widening
circle of law-enforcement personnel who knew that the cipher was broken.
I give very little weight to poorly reasoned arguments advanced
anonymously.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Advanced Encryption Standard - winner is Rijndael
Date: Sat, 07 Oct 2000 17:51:14 -0700
Anonymous wrote:
>
> Is there truly ANYONE stupid enough to believe ANY government would
> adopt an encryption standard that DIDN'T have a back door for unlimited
> government access?!?!?!
> This is just the software version of the "clipper" chip- only >this
> time<, the government didn't repeat their earlier mistake of admitting
> they have the capability to easily decrypt the data.
> But in all fairness, the US government >has< established itself as a
> decade-long enemy of encryption that they can't easily decrypt.
> It's a safe bet the government chose the Rijndael encryption method
> because they can >already< decrypt it.
So what good would this do them? They couldn't, for example, admit
decrypted data into evidence because that would make it obvious that
they could break the cipher. They couldn't even use the information
indirectly to aid prosecution, because that would mean an ever-widening
circle of law-enforcement personnel who knew that the cipher was broken.
About all they could use it for are issues of the highest national
security, where the decrypts and information relating to them, were held
in to the smallest number of people possible.
I give very little weight to poorly reasoned arguments advanced
anonymously.
DS
------------------------------
** 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
******************************
