Cryptography-Digest Digest #631, Volume #12 Thu, 7 Sep 00 15:13:01 EDT
Contents:
Re: Carnivore article in October CACM _Inside_Risks (Barry Margolin)
Re: Losing AES Candidates Could Be a Good Bet? (Mok-Kong Shen)
Re: Losing AES Candidates Could Be a Good Bet? (Mok-Kong Shen)
Re: Losing AES Candidates Could Be a Good Bet? (Mok-Kong Shen)
Extended deadline for Cryptographers' Track RSA Conference 2001 (Ludovic Rousseau)
Re: Carnivore article in October CACM _Inside_Risks (Barry Margolin)
Re: Carnivore article in October CACM _Inside_Risks (Barry Margolin)
R: Multiplicative inverse problem... ("Cristiano")
Re: Losing AES Candidates Could Be a Good Bet? (SCOTT19U.ZIP_GUY)
Re: Losing AES Candidates Could Be a Good Bet? (James Felling)
Re: Losing AES Candidates Could Be a Good Bet? (James Felling)
Re: Carnivore article in October CACM _Inside_Risks (David Lesher)
----------------------------------------------------------------------------
From: Barry Margolin <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto
Subject: Re: Carnivore article in October CACM _Inside_Risks
Date: Thu, 07 Sep 2000 17:54:59 GMT
In article <[EMAIL PROTECTED]>,
-m- <[EMAIL PROTECTED]> wrote:
>Paul Rubin wrote:
>> Put a hardware authentication token in the box?
>
>As I understand it microprocessors have serial numbers embedded in the
>silicon. I was very much against that idea a year or two ago. It looks
>better and better every day -- IF AND ONLY IF we get rid of some of the
>other methods of information gathering such as Cookies... and browser
>history.
How does the hardware serial number help? The processor has to run
software to read out the serial number and transmit it, and how do you know
that the software is transmitting the actual hardware serial number rather
than making something up?
Sun workstations have an ID PROM containing a unique ID that the "hostid"
command will display; this ID is often used by software that's licensed to
a particular machine. Anyone remember that there's a publicly-available
program that you can run to set your machine's hostid (hmm, I wonder if
distribution of that program is a violation of the Digital Millenium
Copyright Act)?
--
Barry Margolin, [EMAIL PROTECTED]
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Thu, 07 Sep 2000 20:07:31 +0200
wtshaw wrote:
>
> I am more concerned that a better government alternative was withheld
> because while the cattle call would tend to reveal the state of the art in
> private sectors, any government plums likely would be reserved to
> non-public knowledge.
I have ssentially the same viewpoint: One of the advantages
that accrue is to learn how strong the capabilites of the
outside cryptologists currently are. Another is to eventually
get some new ideas, if indeed there are some in the
submissions.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Thu, 07 Sep 2000 20:07:37 +0200
John Myre wrote:
>
> Mok-Kong Shen wrote:
> <snip>
> > I suppose one could learn something from each of a number
> > of AES candidates, not only the finalists.
> <snip>
> I suppose one might, if one knew what one were doing and one
> were willing to actually work at it.
The AES candidates have been submitted at the same
time. Apparently they are independently developed.
Once submitted, there is barely chance, as a matter of
fact, for the author of one cipher to modify drastically
his design after seeing what the others have done.
If one now makes some use of the materials of the
diverse AES candidates (including the reasons why
some of these failed to become finalists) as idea and
inspiration to develop a new cipher (that is not
destined for the AES competition), he is not subject
to that constraint, which can be an essential advantage.
Note also that he may optimize his design with respect
to the criteria appropriate for his own specific
environment, which may not be identical to those posed
by NIST.
M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Thu, 07 Sep 2000 20:07:24 +0200
James Felling wrote:
>
> In addition, if one runs an AES cypher in a wraped CBC mode( It would not
> be difficult to write this) one gains most if not all of the practical
> advantages of the ScottXu cyphers.
I am not familiar with the term 'wraped CBC'. Could you
please explain that?
The idea of whole file processing is by itself a good
one, I believe. In terms of block encryption, it simply
means attempting to reap the advantage of a large block,
in this case the maximum possible. Block chaining is
one way of effecting interactions between the diverse
small blocks (given an algorithm that is designed for
a small block size), thus resulting in some large block
benefit. Evidently other approaches of handling the
whole message are conceivable and utilizable, provided
that they are done right, of course.
I remarked sometime ago that there have apparently been
no postings to the group giving a good concise and
complete (English) description of the Scottxu ciphers.
Maybe their author is not very keen to acquire interest
on them.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Ludovic Rousseau)
Subject: Extended deadline for Cryptographers' Track RSA Conference 2001
Date: 6 Sep 2000 15:21:08 GMT
I post this on the behalf of David Naccache, Program Chair.
<< THE SUBMISSION DEADLINE OF CT-RSA HAS BEEN EXTENDED TO OCTOBER 1-ST,
2000 >>
CALL FOR PAPERS
CRYPTOGRAPHERS' TRACK RSA CONFERENCE 2001
APRIL 8-12, 2001; SAN FRANCISCO
In 2001, the Cryptographers' Track of the RSA Conference will be run as
an anonymously refereed conference with proceedings edited in
Springer-Verlag's Lecture Notes in Computer Science series.
Original research papers pertaining to all aspects of cryptography as
well as tutorials or results presented in other conferences are
solicited. Submissions may present theory, techniques, applications and
practical experience on topics including, but not limited to: fast
implementations, secure electronic commerce, network security and
intrusion detection, formal security models, comparison and assessment,
tamper-resistance, certification and time-stamping, cryptographic data
formats and standards, encryption and signature schemes, public key
infrastructure, protocols, elliptic curve cryptography, block cipher
design (in particular AES-related contributions), discrete logarithms
and factorization techniques, stream ciphers and Boolean functions,
lattice reduction and provable security
Important dates:
Submission deadline: September 1, 2000 -> extended to October 1, 2000
Acceptance notification November 1, 2000
Proceedings version: November 17, 2000
Proceedings:
Following the established practice in most cryptography research
conferences the proceedings of the Cryptographers' Track at the RSA
Conference will be edited in Springer Verlag's Lecture Notes in Computer
Science. Although papers that appeared in other conferences can still be
presented at the RSA Conference only original research contributions or
previously unedited tutorials are eligible to appear in the proceedings
(http://www.springer.de/comp/lncs/).
For an accepted paper to be included in the proceedings, the authors of
the paper must guarantee that at least one of the co-authors will attend
the workshop and deliver the talk (registration fees will be waived for
authors, see infra).
To facilitate the production of the proceedings, the final version of an
accepted paper must be prepared according to Authors Instructions
(http://www.springer.de/comp/lncs/authors.html).
Instructions for authors: The program committee invites tutorials and
research contributions in the broad area of applications and theory of
cryptography. Correspondence, including submissions, will take place
entirely through e-mail. All submissions will be blind refereed. To make
a submission, please send two separate e-mail messages to
[EMAIL PROTECTED]
The first message must be in ASCII format. It should include information
on:
1. The title of the submission,
2. The names and affiliations of authors,
3. The e-mail, telephone and facsimile numbers of the contact author, 4.
A statement indicating if the paper is to be considered as an original
tutorial, an original research contribution or a previously published
paper.
The second message should contain the submission itself:
1. The submission must be prepared in a way suitable for blind refereeing;
the first page should contain the title of the submission, but must not
contain the names or affiliations of the authors.
2. The submission should be prepared using 11-point font or larger, with
at most 15 A4/US-letter pages including bibliographies and appendices.
(Authors are strongly encouraged to use LaTeX2e in preparing submissions,
which would facilitate the production of the final proceedings, especially
the electronic version of the proceedings.),
3. Page format for submissions is PostScript (e.g. obtained using
dvips).
4. The file may be compressed using "gzip" or "zip", and then encoded
using "uuencode".
Price and sponsoring:
A special reduced registration price has been negotiated for members of
academia and University students wanting to attend the RSA Conference
and the Cryptographers' Track (circa US$595). This special rate provides
access to the full Conference. Several corporations have kindly proposed
to sponsor student registration fees; full-time students wishing to
apply for a scholarship should contact RSA Security at
[EMAIL PROTECTED]
Presenters of selected talks will receive a complimentary conference
pass.
Program Committee:
David Naccache, Program Chair (Gemplus, France)
Ross Anderson (Cambridge University, UK)
Daniel Beichenbacher (Bell Labs, USA)
Josh Benaloh (Microsoft Research, USA)
Dan Boneh (Stanford University, USA)
Mike Burmester (Royal Holloway, UK)
Don Coppersmith (IBM Research, USA)
Rosario Gennaro (IBM Research, USA)
Ari Juels (RSA Laboratories, USA)
Burt Kaliski (RSA Laboratories, USA)
Kwangjo Kim (ICU, Korea)
Arjen Lenstra (Citibank, USA)
Ueli Maurer (ETH, Switzerland)
Bart Preneel (KUL, Belgium)
Jean-Jacques Quisquater (UCL, Belgium)
Michael Reiter (Lucent, USA)
Victor Shoup (IBM Research, Switzerland)
Jacques Stern (ENS, France)
Scott Vanstone, (Certicom, Canada)
Michael Wiener (Entrust, Canada)
Moti Yung (Certco, USA)
Yuliang Zheng (Monash University, Australia)
Phil Zimmerman (PGP, USA)
--
Ludovic Rousseau
[EMAIL PROTECTED]
-- Normaliser Unix c'est comme pasteuriser le Camembert, L.R. --
------------------------------
From: Barry Margolin <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto
Subject: Re: Carnivore article in October CACM _Inside_Risks
Date: Thu, 07 Sep 2000 18:02:56 GMT
In article <[EMAIL PROTECTED]>,
-m- <[EMAIL PROTECTED]> wrote:
>A professional does not discover he is under surveillance... he assumes
>it
>from the start.
I think I'm confused about just what kind of spoofing you're talking about.
Carnivore is a sniffer that tries to reconstruct the TCP sessions
(currently just SMTP, I believe, but presumably they could extend it to
other protocols), right?
If someone is trying to hide what they're doing, how can spoofed packets
achieve that? If they confuse Carnivore, won't they also confuse the
actual destination machine, resulting in connection resets, etc. And if
you're sending this spoofed traffic all the time, just in case you're being
monitored, how would you get any real work done?
The other thing you might be talking about is some third party trying to
make it appear that someone is doing something wrong, so they create fake
email that appears to be from him. Of course, this won't just show up in
the Carnivore monitoring, it will also show up in the mailbox of the
recipient. So not only will the FBI think that this person is sending mail
to a mobster, the mobster himself will! Well, I suppose the perpetrator
could let the mobster know via some other means that any messages from this
person should be ignored since they're being faked.
Is either of these what you're talking about?
--
Barry Margolin, [EMAIL PROTECTED]
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
------------------------------
From: Barry Margolin <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto
Subject: Re: Carnivore article in October CACM _Inside_Risks
Date: Thu, 07 Sep 2000 18:06:29 GMT
In article <newscache$lqfi0g$h1k$[EMAIL PROTECTED]>,
Ken Hagan <[EMAIL PROTECTED]> wrote:
>We'd end up with juries populated exclusively by the kind of
>folks who believe TV adverts offer convincing proof of product
>effectiveness.
It's often said that a jury consists of 12 people who weren't smart enough
to get out of jury duty....
--
Barry Margolin, [EMAIL PROTECTED]
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
------------------------------
From: "Cristiano" <[EMAIL PROTECTED]>
Subject: R: Multiplicative inverse problem...
Date: Thu, 7 Sep 2000 20:04:29 +0200
I have this doc.
Please indicate specifically where is what you say or tell me the values of
s and q.
Cristiano
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: 7 Sep 2000 18:14:35 GMT
[EMAIL PROTECTED] (James Felling) wrote in
<[EMAIL PROTECTED]>:
>In addition, if one runs an AES cypher in a wraped CBC mode( It would not
>be difficult to write this) one gains most if not all of the practical
>advantages of the ScottXu cyphers.
>
Yes but what is your defination of "wraped CBC" is it simialer
to my "wrapped PCBC" which repuires the decyption passes to occur
in the opposite direction as the wrapping?
And do you really think they would allow for a secure form
of chaining that would effectively require a whole pass through
the code. It would make the NSA work to hard to break it so
I doubt you will ever see somthing like it approved.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page
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: James Felling <[EMAIL PROTECTED]>
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Thu, 07 Sep 2000 13:28:04 -0500
All that the AES does is give us an algo. How that Algo is chained is up to
us. All I am saying is that with an apropriate chaining mode. AES can have the
all or nothing property that your algo has, and the benefit of a well analyzed
algo as well. (Not that I am claiming that scottxu is bad, merely that it has
not had the level of scrutiny that the AES will have had.).
"SCOTT19U.ZIP_GUY" wrote:
> [EMAIL PROTECTED] (James Felling) wrote in
> <[EMAIL PROTECTED]>:
>
> >In addition, if one runs an AES cypher in a wraped CBC mode( It would not
> >be difficult to write this) one gains most if not all of the practical
> >advantages of the ScottXu cyphers.
> >
>
> Yes but what is your defination of "wraped CBC" is it simialer
> to my "wrapped PCBC" which repuires the decyption passes to occur
> in the opposite direction as the wrapping?
>
> And do you really think they would allow for a secure form
> of chaining that would effectively require a whole pass through
> the code. It would make the NSA work to hard to break it so
> I doubt you will ever see somthing like it approved.
>
> David A. Scott
> --
> SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> http://www.jim.com/jamesd/Kong/scott19u.zip
> Scott famous encryption website **now all allowed**
> http://members.xoom.com/ecil/index.htm
> Scott rejected paper for the ACM
> http://members.xoom.com/ecil/dspaper.htm
> Scott famous Compression Page
> 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: James Felling <[EMAIL PROTECTED]>
Subject: Re: Losing AES Candidates Could Be a Good Bet?
Date: Thu, 07 Sep 2000 13:31:20 -0500
It may be accomplished in a number of ways. The simplest way of viewing it is
put the file in a ring buffer, and using your favorite chaining mode run
through it 2X or more times. This will result in an efffective all or nothing
encypherment of the plaintext.( other potential modifications include altering
the direction that you pass through the file, or more than 2 passes through.
Mok-Kong Shen wrote:
> James Felling wrote:
> >
> > In addition, if one runs an AES cypher in a wraped CBC mode( It would not
> > be difficult to write this) one gains most if not all of the practical
> > advantages of the ScottXu cyphers.
>
> I am not familiar with the term 'wraped CBC'. Could you
> please explain that?
>
> The idea of whole file processing is by itself a good
> one, I believe. In terms of block encryption, it simply
> means attempting to reap the advantage of a large block,
> in this case the maximum possible. Block chaining is
> one way of effecting interactions between the diverse
> small blocks (given an algorithm that is designed for
> a small block size), thus resulting in some large block
> benefit. Evidently other approaches of handling the
> whole message are conceivable and utilizable, provided
> that they are done right, of course.
>
> I remarked sometime ago that there have apparently been
> no postings to the group giving a good concise and
> complete (English) description of the Scottxu ciphers.
> Maybe their author is not very keen to acquire interest
> on them.
>
> M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Lesher)
Crossposted-To: comp.security.misc,alt.security,talk.politics.crypto
Subject: Re: Carnivore article in October CACM _Inside_Risks
Date: 7 Sep 2000 15:07:48 -0400
Reply-To: [EMAIL PROTECTED] (David Lesher)
Barry Margolin <[EMAIL PROTECTED]> writes:
>The other thing you might be talking about is some third party trying to
>make it appear that someone is doing something wrong, so they create fake
>email that appears to be from him. Of course, this won't just show up in
>the Carnivore monitoring, it will also show up in the mailbox of the
>recipient. So not only will the FBI think that this person is sending mail
>to a mobster, the mobster himself will!
And if you send HTML-mail to Jill Winecooler that says:
ASCII:
The tridium will be available on Tuesday
and
HTML:
Make Fast Money -- My name is Dave Hughes and....
Which one will Jill see if she is already a victim of Outlook?
And then when she /dev/nulls the spam, it's clearly to hide the evidence. Right?
--
A host is a host from coast to [EMAIL PROTECTED]
& no one will talk to a host that's close........[v].(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
------------------------------
** 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
******************************
