Cryptography-Digest Digest #739, Volume #11 Tue, 9 May 00 10:13:01 EDT
Contents:
Re: An argument for multiple AES winners (Mok-Kong Shen)
Re: high speed public key crypto (Runu Knips)
Turing's Treatise on Enigma (Frode Weierud)
Re: RSA-primes, smoothness (Runu Knips)
Re: high speed public key crypto (Volker Hetzer)
Re: An argument for multiple AES winners (Runu Knips)
PlatyMAC a new Message Authentication Code. (David Formosa (aka ? the Platypus))
Re: AEES Advanced ([EMAIL PROTECTED])
Re: Unbreakable Superencipherment Rounds (Runu Knips)
Re: Factoring vs. Discrete Log Problem (DLP) (Roger Schlafly)
Re: RSA-primes, smoothness (DJohn37050)
Re: The Illusion of Security (Tim Tyler)
User Authentication ("C. Prichard")
CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01) ("David M. Balenson")
Re: An argument for multiple AES winners ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: An argument for multiple AES winners
Date: Tue, 09 May 2000 13:23:08 +0200
Anton Stiglic wrote:
> > > You are calculating the probability in the wrong way.
> > > It's not an *and*, but an *or*. If you have 3 algos,
> > > with probability of p1 that the first will have a component
> > > that is patented, p2 for the second and p3 for the last,
> > > the probability that the whole has a component that is
> > > patented is p1 + p2 + p3, which is >= to any single pi.
> > >
> > > This comes from the fact that you are reliable for what
> > > you have done in the past (if you used a patented
> > > algorithm in the past, they can sue you).
> > >
> > > The more algos you use, the greater the risk of having
> > > a patent attack.
> >
> > I am not sure that, if I use an algorithm that incorporates a hidden
> > patent, I would have to pay anything to the patent holder for
> > usage of the algorithm BEFORE his notice, as long as the general public
> > also doesn't have any knowledge of the involvement of the hidden
> > patent. (I am absolutely unconscious of my guilt.) On the other hand,
> > if my application has been tightly geered to that algorithm and (for
> > whatever reasons -- there could be many) I have no appropriate
> > algorithm to substitute the algorithm now known to have patent claims,
> > then I am really caught.
>
> The thing is that you will be sued for what you used in the past. If
> your system ever used the algorithm in the past, then you can get sued.
> That's the bottom line.
Well, anybody can sue me for anything at anytime. The point is whether
the court will give him right. Note that AES is a process that has a wide
publicity. If the document of AES says that to the best of knowledge
of NIST no patent issue is involved and I use AES, a patent holder
can tell me either to stop using it or pay license fees but can't demand
any money for past usage. A (rather remote) analogy is the following:
If you have a big piece of land in the country that is neither marked as
private nor fenced and I step into it, you can tell me to get away but
you can't sue me for anything. On the contrary, if people regularly
go through your land and with time there develops sort of a path and
you seem to have tolerated that for a sufficiently long time, then as far
as I am informed, you will lose your right to stop people from taking
that path. Of course, I can't exclude that in the US things could be
different, but I rather doubt that.
> If you are talking about hiding the truth, or the fact that you used such
> or such algorithm, that is something else.
If there is anyone hiding the truth in the present context, then that can
obviously not be the users of AES. A potential candidate could be NIST,
perhaps :-)
M. K. Shen
------------------------------
Date: Tue, 09 May 2000 13:37:54 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: high speed public key crypto
Eric Hambuch wrote:
> Mehdi Sotoodeh wrote:
> >
> > I have found a new public key crypto system that is fast, easy to implement
> > and requires low level of system resources.
>
> Are you sure ? Did you find the holy gral?
>
> > I am looking for someone who is interested to work on this as a joint
> > project. I specifically need help on evaluation and publication of the
> > project.
> > Please let me know if you are interested.
>
> I think we are all interested ?!
Couldn't agree more... sounds like "I've found the world formula" in
a *.physics.* group ;-)
------------------------------
From: [EMAIL PROTECTED] (Frode Weierud)
Subject: Turing's Treatise on Enigma
Date: 9 May 2000 11:39:24 GMT
Reply-To: [EMAIL PROTECTED]
A new chapter, Chapter 4, of the electronic version of "Turing's
Treatise on Enigma" also called "Prof's Book" has now been
published on my Turing Web page at:
http://home.cern.ch/frode/crypto/Turing/index.html
Frode
--
Frode Weierud Phone : +41 22 7674794
CERN, SL, CH-1211 Geneva 23, Fax : +41 22 7679185
Switzerland E-mail : [EMAIL PROTECTED]
WWW : home.cern.ch/frode/
------------------------------
Date: Tue, 09 May 2000 13:42:28 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: RSA-primes, smoothness
Roger wrote:
> The bankers prefer snake oil, I guess.
After all its not THEIR money, so why don't make life
easier ? Yep, this was ironical.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: high speed public key crypto
Date: Tue, 09 May 2000 11:50:19 +0000
Mehdi Sotoodeh wrote:
>
> I have found a new public key crypto system that is fast, easy to implement
> and requires low level of system resources.
> I am looking for someone who is interested to work on this as a joint
> project. I specifically need help on evaluation and publication of the
> project.
> Please let me know if you are interested.
To answer the question about help:
Step one (optional):
If you don't want to place it in the public domain,
get to talk to a lawyer (they don't bite and the money
is well spent) in order to secure any rights. This should
take a few days or perhaps weeks.
Step two:
Now you are safe to publish it right here and invite comments.
Of course, the image gain is much bigger if you place your
invention into the public domain.
In any case you have to move fast, because if your idea IS even remotely
realistic you can rely on the fact that by now a laser microphone is
pointing at your window and your computer has been bugged thoroughly.
That means, whoever gets to the patent office first gets the rights.
And neither the public nor you get anything out of it.
Greetings!
Volker
--
"Isn't it just my luck. Some stranger says to me, "I LOVE YOU"
and next thing I know, I've got this virus..."
------------------------------
Date: Tue, 09 May 2000 13:58:17 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: An argument for multiple AES winners
Mok-Kong Shen wrote:
> I remember to have learned some time ago from
> discussions in this group that having multiple AES
> winners has the advantage of better coping with
> the case that one winner is eventually found to
> have certain weakness that is hiterto not
> discovered.
>
> It just occurs to me that the same applies in
> respect of hidden patent claims. If there are e.g.
> three AES winners, the chance of all of them have
> hidden patent claims is likely to be fairly small.
> So if NIST is not able to insure (free of charge)
> the absence of hidden patent claims to prevent
> the potential catastrophe of users worldwide
> having to pay someday patent loyalities, letting
> there to be multiple AES winners is definitely
> a good idea.
Yep. The Twofish paper states that this algorithm
is free of patents, but who can say that for sure ?
Patents are a big problem. I hope that all the
three major algorithms left (Rijandel, Serpent,
Twofish) are free of such problems.
Btw, if at all, "all over the world" means US. I
don't think we'll have much problems with this
in europe.
------------------------------
From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: PlatyMAC a new Message Authentication Code.
Date: 9 May 2000 12:05:20 GMT
Reply-To: dformosa@[202.7.69.25]
I've come up with an interesting way to construct a MAC. I'm
interested in finding if there are any attacks or this construct is
already well know.
The two options I have for getting this analyzed seem to be make
such a pain of myself claiming that I have an unbreakable system until
people try to brake it just to shut me up, or offer some money to
whoever brakes it.
As I'm purely an amateur and don't wish to profit from this endeavor
(hence PlatyMAC is unpatented) I can't offer much, however $200
Australian dollars will go to the first person who discovers a better
then birthday attack on the system.
######################################################################
Description of the system
First an IV is created (this IV MUST be used only once).
This is XORed with the key and used to initialize a secure pydorandom
number generator.
The plaintext concatenated with its length and then padded out to a
multiple of 256bits.
The plantext is then sent threw the compression function such that
H_i = f ( P_i, H_(i-1) )
The compression function is as follows
f (data)
hash = 0
for i = 1 to 128
mask = rand256
flip = rand256
fixed = rand256
mflip = (flap ^ data) & mask
mfixed = fixed & !mask
sout = mflip | mfixed
hashbit = parity (sout)
hash = hash * 2
hash = hash | hashbit
endfor
return hash
endf
Where rand256 returns a 256 bit pydorandom number and parity returns 0
if there are an even number of ones in sout and 1 otherwise.
######################################################################
Theory
The f function acts like a big key dependent S box that is constantly
being changed. This is intended to frustrate analysis that depend on
the sbox being fixed. In addition the multiplexer system (using mask)
means that each bit on average is a function of half of the bits.
######################################################################
Problems
The prime problem I see is that it may be to slow for practical use,
also it would guzzle pydorandom bits like they where going out of
fashion.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Interested in drawing platypie for money? Email me.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: AEES Advanced
Date: Tue, 09 May 2000 12:01:38 GMT
In article <u7Fw7N#t$GA.260@cpmsnbbsa04>,
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
> > There is no existing software for this architecture.
> If there's no software for it, then how do you offer source
> code for it?
> Joe
>
>
Joseph,
Logically you are right.
Kurt wrote:
#IMHO it is a bad thing to develop a software that runs slowly
#in comparison to existing software,
I should answer that there is no 'existing software' for this
architecture concerning statement above. So Kurt's statement is too
abstract and my answer was not clear enough. A propos performance of
AEES-advanced excluding I/O operations is not too bad (1600 Kb/sec).
Regards.
Alex.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 09 May 2000 14:18:36 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Unbreakable Superencipherment Rounds
UBCHI2 wrote:
> There is a way to encrypt communications that make them impregnable to
> cryptanalysts theoretically. Can the following sequence be implemented?
>
> 1) 1 round RC6
> 2) 1 round TwoFish
> 3) 1 round Serpent
> 4) 1 round Mars
> 5) 1 round Rijndael
>
> Then top off the rounds with a final pass with 3DES. Then I do it again by
> randomizing the number of rounds of each and the order of the
> superencipherments using SIGABA irregular movement of the algorithms.
Wrong. You create a new cipher which is
(a) very complex and therefore hard to analyse
(b) very slow
The only good property of it is, that some steps of it are 3DES. If
you use a different key for 3DES and the other rounds, the resulting
cipher shouldn't be less secure than 3DES.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Factoring vs. Discrete Log Problem (DLP)
Date: Tue, 09 May 2000 05:52:40 -0700
David Blackman wrote:
> I'm not sure i'm understanding this discussion right. Are people
> proposing to use an encryption method that can be broken by solving the
> discrete log problem?
Yes. Millions of people use it every day. Diffie-Hellman's
original public key cryptosystem used it, and it is still
considered rock solid.
> Discrete log modulo a prime has surely been published somewhere, though
> i don't remember seeing it. Just take one of the published square root
> algorithms and do the obvious stuff.
No efficient methods if the prime has more than 500 bits.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: RSA-primes, smoothness
Date: 09 May 2000 13:16:15 GMT
No, they decided that the cost was nominal, and worth the disambiguation. What
do you do if someone presents a RSA key where p-1 HAS all small factors? Go
before a judge and let HIM/HER decide? Or perhaps worse, a jury?
Given these possibilities, the answer for banks was to disallow this
possibility. If anyone comes and presents such an RSA key, it does not meet
the standard.
Don Johnson
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Reply-To: [EMAIL PROTECTED]
Date: Tue, 9 May 2000 12:51:50 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> In short the security "proof" for quantum cryptography appears to depend
:> on the security of a random number generator - and it is this which I am
:> calling into question in the first place.
: No, the quantum system itself provides the randomness directly in
: the (tamperproof) key stream.
This does not appear to be the case in descriptions of quantum
cryptography protocols with which I am familiar.
As an example, it does not appear to be the case with the protocol as
described by Schneier in "Applied Cryptography, p. 554-557.
There the source of the randomness appears to be the way in which Alice
sets up her polarised photon production devices - and /not/ any quantum
events.
Quantum events affect some of Bob's measurements - but these are the ones
which are eventually discarded.
If perhaps you are discussing another protocol from the ones I have
encountered to date, then a description of such a protocol, or a pointer
to such a description might help me to review the situation.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: User Authentication
Date: Tue, 09 May 2000 13:29:27 GMT
You can wrap the site in Perl and use sophisticated server key for tag =
encryption. The encrypted tag are a low cost line of security for server =
content.
In the scheme, each successful login generates a new page tag encryption =
key. Each user having his own key that is also optionally refreshed with =
new page content. (With frames the key is changed for each frame as it =
is refreshed.) This makes user impersonation very unlikely and forces =
all users to use the links presented and the passwords to get =
information.
The method does not require a client side cookie.
If a user shares his password, it is possible that another person can =
use the account,, but not jointly as both users will race for the same =
encryption key only one time with the loser being ejected from the =
system.
I have a working example that shows that I have worked out much the code =
and encryption for this solution at: =
http://www.greentv.com/cgi-bin/cgiwrap/greentv/CRI/_nttc.cgi?page=3Dopene=
r&user_id=3D
When you roll over the links you can see they are encrypted. Its just a =
simple demonstration of what can be done with my CipherText algorithm =
which has a patent pending on an innovation. The algorithm allows =
encrypted content to be %100 HTTP text/html protocol compatible reducing =
the overhead needed for conversion when using other algorithms. =
CipherText uses a double symmetric cipher where the key length can be =
masked using a set of tiered keys so that the set of applied cipher =
combinations can easily exceed message length. The make it highly immune =
to key pair attacks and frequency analysis.
You can contract me to work on the scheme with you, meeting your =
client's demands and actually licensing the CipherText algorithm.
Regards,
Charles Prichard
www.greentv.com
<[EMAIL PROTECTED]> wrote in message =
news:8ditc3$scl$[EMAIL PROTECTED]...
> I'm going to be working on developing a client/server application pair
> this summer in which the client will communicate with the server using
> a closed, proprietary protocol. I need some mechanism to insure that
> only _my_ client talks to the server. In other words, although the
> protocol will not be documented, I want to guard against the
> possibility that someone will reverse engineer the protocol using a
> packet sniffer and write an alternative client that emulates my real
> client and talks to the server. This application will be used inside =
a
> large corporate intranet system, and, based on certain 'organizational
> politics' type issues, it is extremely likely that someone will try to
> create a rogue/imposter client. My job is to make sure that the =
person
> who tries this does not succeed. :-)
>=20
> This seems like the kind of problem that others may have faced before,
> and I would like to know how this is generally dealt with. Obviously,
> there is going to have to be some kind of authentification handshake =
in
> the protocol in which my client identifies itself as being the real
> McCoy before the server starts talking. I assume the best way to do
> this is to use RSA encryption, i.e., the client transmits some data
> that is encrypted with a private key and the server decrypts it with a
> public key. However, I'm concerned about two things. First, if I
> distribute an application with a key, won't it be rather easy for a
> person with malicious intentions to get ahold of the key and then =
spoof
> being the real client? Should I encrypt the key? Also, secondly, =
what
> data should I encrypt and send? If I just send an encrypted version =
of
> the same message each time (e.g, the word "HELLO"), it'll be pretty
> easy to fake out the server because the crypt text will always be the
> same. I thought about encrypting the current time (the requirements
> for the project assume that the client machines are all set to the
> correct time +/- 10 minutes) and sending that, but if anyone ever
> figured out that that was what the crypt text was, it might be =
possible
> to crack the key pair. (i.e., knowing that the crypt text was always
> an encrypted version of the current time would give a cracker a very
> large set of plain text/crypt text pairs, and this might make it easy
> to determine the value of the key).
>=20
> Does anyone have any suggestions? I feel like I must be missing an
> obvious solution here...
>=20
>=20
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "David M. Balenson" <[EMAIL PROTECTED]>
Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01)
Date: Tue, 9 May 2000 09:28:52 -0400
C A L L F O R P A P E R S
The Internet Society
2001 Network and Distributed System Security Symposium
(NDSS'01)
February 7-9, 2001
Catamaran Resort, San Diego, California
IMPORTANT DATES
Paper Submission due: August 2, 2000
Author Notification: September 27, 2000
Camera-ready final papers due: October 31, 2000
GOAL:
This symposium will foster information exchange among researchers
and practioners of network and distributed system security
services. The intended audience includes those who are interested
in the practical aspects of network and distributed system security,
focusing on actual system design and implementation, rather than
theory. A major goal of the symposium is to encourage and enable
the Internet community to apply, deploy, and advance the state of
available security technology. The proceedings of the symposium
will be published by the Internet Society.
Submissions are solicited for, but are not limited to, the following
topics:
* Secure Electronic Commerce: e.g., payment, barter, EDI,
notarization/timestamping, endorsement and licensing.
* Intellectual Property Protection: protocols, schemas,
implementations, metering, watermarking, other forms of rights
management.
* Implementation, deployment and management of network security
policies.
* Integrating Security in Internet protocols: routing, naming,
TCP/IP, multicast, network management, and the Web.
* Attack-resistant protocols and services.
* Special problems and case studies: e.g., interplay and tradeoffs
between security and efficiency, usability, reliability and cost.
* Security for collaborative applications and services: tele- and
video-conferencing, groupwork, etc.
* Fundamental services: authentication, data integrity,
confidentiality, authorization, non-repudiation, and availability.
* Supporting mechanisms and APIs: key management and certification,
revocation, audit trails and accountability.
* Public Key Infrastructure.
* Integrating security services with system and application security
facilities and protocols: e.g., message handling, file
transport/access, directories, time synchronization, database
management, boot services, mobile computing.
* Security for emerging technologies: sensor networks, specialized
testbeds, wireless/mobile (and ad hoc) networks, personal
communication systems, and large heterogeneous distributed systems.
* Intrusion Avoidance, Detection, and Response: systems, experiences
and architectures.
* Network Perimeter Controls: firewalls, packet filters, application
gateways.
* Virtual Private Networks.
BEST PAPER AWARD:
There will be a best paper award again this year. The award will
be presented at the symposium to the authors of the best overall
paper as selected by the Program Committee.
SUBMISSIONS:
The Program Committee invites both technical papers and panel
proposals. Technical papers should be at most 20 pages long. Panel
proposals should be at most two pages and should describe the
topic, identify the panel chair, explain the format of the panel,
and list three to four potential panelists. Technical papers will
appear in the proceedings. A description of each panel will appear
in the proceedings, and may - at the discretion of the panel chair
- include written position statements from the panelists.
Each submission must contain a separate title page with the type
of submission (paper or panel), the title or topic, the names of
the author(s), organizational affiliation(s), telephone and FAX
numbers, postal addresses, e-mail addresses, and must specify the
contact author in case of multi-author submissions. The names of
authors, affiliations, and other identifying information should
appear only on the separate title page. Submissions must be
received by August 2, 2000, and must be made via electronically
in either PostScript or ASCII format. If the Committee is unable
to print a PostScript submission, a hardcopy will be requested.
Therefore, PostScript submissions must arrive well before the
deadline.
Submission information can be found at
http://www.isoc.org/ndss01/cfp. Dates, final call for papers,
advance program, and registration information will be available
soon at http://www.isoc.org/ndss01.
Each submission will be acknowledged by e-mail. If acknowledgment
is not received within seven days, please contact the program
Co-chairs as indicated below. Authors and panelists will be
notified of acceptance by September 27, 2000. Instructions for
preparing camera-ready copy for the proceedings will be sent at
that time. The camera-ready copy must be received by October 31,
2000.
GENERAL CHAIR:
Stephen Welke, Trusted Computer Solutions
PROGRAM CO-CHAIRS:
Avi Rubin, AT&T Labs - Research
Paul Van Oorschot, Entrust Technologies
TUTORIAL CHAIR:
Eric Harder, National Security Agency
LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center
PUBLICATIONS CHAIR:
Mahesh Tripunitara, Purdue University
PUBLICITY CHAIR:
David Balenson, NAI Labs, Network Associates
LOGISTICS CHAIR:
Carla Rosenfeld, Internet Society
PROGRAM COMMITTEE:
Bennet Yee, University of California San Diego
Bill Cheswick, Bell Labs
Dave Kormann, AT&T Labs - Research
David Aucksmith, Intel Corportation
David P. Maher, Intertrust
David Wagner, UC Berkeley
Edward W. Felten, Princeton University
Fabian Monrose, Bell Labs
Gary McGraw, Reliable Software Technologies
James Ellis, Sun Microsystems
Kevin McCurley, IBM Almaden Research Center
Matt Bishop, UC Davis
Mudge, L0pht Heavy Industries, Inc.
Peter Gutmann, University of Auckland, New Zealand
Radia Perlman, Sun Microsystems
Sandra Murphy, Network Associates
Tom Berson, Anagram Laboratories
Virgil D. Gligor, University of Maryland
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: An argument for multiple AES winners
Date: Tue, 09 May 2000 13:23:30 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
>
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> > > letting
> > > there to be multiple AES winners is definitely
> > > a good idea.
> >
> > Or pick a candidate that is most unlikely to have patent claims
(it's
> > unlikely that Serpent for example would have any relevant patent
> > claims - it's just too similar to DES).
> >
> > Of course, this would also mean totally avoiding algorithms that
have
> > obvious potential patent issues (e.g. MARS & RC6).
>
> The criteria for the winner are about strength and speed.
And versatility....
> One cannot
> speculate on the likelihood of having hidden patent claims. One has
> to attempt to find these out.
RSA have asserted they have Patents that cover MARS (and RC6)....
Also, Hitachi has written to NIST claiming that they have patent
coverage on ideas implemented in all 5 AES candidates apart from
Rijndael....
> Actually, I suppose it shouldn't be too
> difficult for NIST to do the patent search.Further, it is common for
> government agencies to help one another. NIST could ask the US
> patent office to cooperate in that task.
They would need to check foreign patents as well. Not such a simple
task?
> > > BTW, I like to ask at this opportunity a probably
> > > dumb question. Is it certain that AES will be
> > > freely available to all people of the world?
> >
> > That's certainly the intention (as mentioned in the summary of the
> > original request).
>
> There are too often cases in politics where heavily
stressed 'intentions'
> are not realized and even turned into the opposites.
>
> > > Would its use be restricted to applications such
> > > as banking and also confined to the 'friendly'
> > > nations? How about the Wassenaar Arrangements?
> >
> > How do you restrict the application of cipher(s) that has been so
> > widely deployed? ;)
> >
> > AES will be used anywhere, regardless of export agreements and
suchlike.
> >
>
> It suffices to recall the impact of export regulations on crypto
> hithertofore.
Yes, DES was export controlled for many years, but has still been
implemented in off the shelf packages / shareware / freeware etc.
> Even drugs could be smuggled. But if a crypto cannot be officially
> available somewhere, then its use by commercial firms there would be
> illegal and that could create problems, e.g. in case where these
> firms have branch offices in the US, I suppose.
Eh? You asked if AES was going to "restricted" and "confined".
Clearly the USG don't have the power to restrict or confine the details
of the cipher (or prevent the cipher from being employed in open
standards such as IPSec, OpenPGP etc). The only power they do have is
to prevent US products from shipping with _implementations_ of this
algorithm, but this is another kettle of fish entirely.
Rgds,
--
Sam Simpson
http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
