Cryptography-Digest Digest #660, Volume #10 Wed, 1 Dec 99 20:13:01 EST
Contents:
Question about CFB mode (Eric Lee Green)
Re: Encrypting short blocks (Eric Lee Green)
Re: VIC cipher strength? ("r.e.s.")
Re: more about the random number generator (Eric Lee Green)
Re: Simpson's Paradox and Quantum Entanglement ("karl malbrain")
Re: Decyption proof cellphones in Europe? [x3] (Ian Goldberg)
Re: High Speed (1GBit/s) 3DES Processor (David Kessner)
Re: more about the random number generator (Scott Nelson)
Re: Elliptic Curve Public-Key Cryptography (Paul Rubin)
Re: Simpson's Paradox and Quantum Entanglement (Jim Carr)
Re: Elliptic Curve Cryptography (Mike Rodriquez)
Re: Encrypting short blocks (SCOTT19U.ZIP_GUY)
Re: more about the random number generator (CLSV)
One Round Block Cipher and 8-bit block Cipoher (Seongtaek Chee)
newbie question (Kyle Hayes)
One round or 8-bit block cipher (Seongtaek Chee)
Re: The $10,000.00 contesta (Bruce Schneier)
Re: NSA should do a cryptoanalysis of AES (Bruce Schneier)
Re: Decyption proof cellphones in Europe? [x3] (Bruce Schneier)
Fast Software Encryption 2000 - Call for Papers/Participation (Bruce Schneier)
----------------------------------------------------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Question about CFB mode
Date: Wed, 01 Dec 1999 13:18:54 -0700
I'm implementing CFB mode using the description in Bruce Schneir's "Applied
Cryptography" (page 200, 2nd edition), and have a question. He mentions a
"left-most byte". Little Endian vs. Big Endian? I am assuming that if I have a
"unsigned char cryptbuf[16]" that holds my encrypted counter value, he is
referring to cryptbuf[0]? Also, he describes shifting the resulting encrypted
byte (from xor'ing the input byte with that 'left-most byte' into a shift
register (16 bytes long, if we're using one of the AES candidates). If my
shift register is declared the same as 'cryptbuf' above, do I "shift left"
(i.e., move sr[1] to sr[0], sr[2] to sr[1], etc., and the new crypto-char goes
into sr[15]) or do I "shift right" (the new crypto-char goes into sr[0])?
I know, I know, it doesn't really matter as long as both ends do it the same
way, but I want to get a WEE bit of interoperability with other
implementations of CFB mode, especially since I might use a "stock"
cryptographic toolkit on platforms other than Linux (even though it's so much
more fun rolling your own!).
(For those browsing the group looking for an education -- CFB mode is a method
of emulating a stream cipher using a block cipher. Start with a block-sized
unique initial value. Encrypt it with the key. Use the 'left most byte' of the
encrypted value to XOR with the byte of data you're wanting to encrypt. Then
shift the resulting encrypted byte into the shift register, as well as return
it as the value of the encryption).
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Encrypting short blocks
Date: Wed, 01 Dec 1999 13:23:58 -0700
Markus Peuhkuri wrote:
>
> Is there an encyprion algorithm that can be used for short
> blocks (variable from ~10 to 24 bits) _and_ the result is same
> length as original data. The key may be much larger (128, 256,
> ...).
Any stream cipher, or a block cipher in CFB or OFB/Counter mode. I.e., almost
all encryption algorithms. Note you'll need to use the left-most BIT in CFB
mode if you're wanting to do bitstream encryption...
Well, they do require you to first "chat" a unique salt value across the 'net
or whatever you're using as your transmission medium, but that doesn't make
the result any larger than the original message.
Pick up any good book on encryption to see what CFB means...
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: VIC cipher strength?
Date: Wed, 1 Dec 1999 12:28:27 -0800
"UBCHI2" <[EMAIL PROTECTED]> wrote ...
: Looking at the VIC Cipher, it appears that many of the steps
: leading up to the straddling checkerboard are quite unecessary.
: Why not just start with a predeterminded straddling checkerboard
: and then perform the rest of the encipherment.
The critical 10 digits serve to generate a "key sequence"
of digits used to key not only the straddling checkerboard,
but also two transpositions. Those three stages (viz.,
substitution via straddling checkerboard, followed by the
two different transpositions), seem to be the essence of
the cipher.
Also, the steps leading up to the critical 10 digits do
serve to incorporate a sender-created message key (unique
to each message) into the cipher, thus helping to ensure
that the "key sequence" is not repeated in other messages.
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Wed, 01 Dec 1999 13:31:38 -0700
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brian Chase) wrote:
> >Naive question here. Let's say you had access to some "optimum
> >compressor" which would take arbitrary data sets distill them into their
> >most compact form. By definition, the resulting data must have no
> >predictable redundancies, yes? Could you use optimally compressed data
> >sets as sources for random numbers?
By definition, the resulting data is predictable -- all compressions of the
same data set result in the same sequence of bytes. In cryptography we're not
concerned so much about randomness as we are about predictability. A random
number generator can generate a perfectly random distribution, as verifiable
by all means of statistical analysis, and still be useless for cryptographic
purposes because its output is predictable.
For example, see David Wagner's site for his paper on how he broke the first
SSL implementation from Netscape. It turns out that they had a poorly designed
pseudo-random number generator. Sure, it passed statistical tests, but it had
a very limited set of initial starting states, and thus he could "guess" what
session keys were going to be generated by it -- and then try only those
session keys, rather than have to search the entire key field.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer Visit our Web page:
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Wed, 1 Dec 1999 12:41:24 -0800
Medical Electronics Lab <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Brian Chase wrote:
>
> > Hey I think you may have accidentally had your KOOKSLOCK key on when you
> > typed this. Why do all the crazy people always hang out in sci.math and
> > sci.physics? It's a strange phenomenon to witness really... Reading
> > USENET's sci.* hierarchy is a lot like riding the city bus.
>
> That's not funny, it's sick. In my town several people were
> burned by a guy with a gas can and a match on a city bus.
> Fortunately they all survived, but it was a damn close call.
> Be careful with the kooks, they may be dangerous.
You don't have to look any farther than how the FBI has organized and
trained the local police to determine the course of ALIENATION in public
behaviour. You've seen this on TV already, in 1666 with the monks in
Vietnam immolating themselves. Or, how about the spread of tuberculosis by
ALIENATED individuals??? It's time to grow up. Karl M
------------------------------
From: [EMAIL PROTECTED] (Ian Goldberg)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: 1 Dec 1999 21:19:21 GMT
In article <[EMAIL PROTECTED]>,
Helmut Wabnig <[EMAIL PROTECTED]> wrote:
>On 1 Dec 1999 17:15:44 GMT, [EMAIL PROTECTED] (Ian Goldberg) wrote:
>
>...........snip
>>You're confusing a couple of things, here. The SDA didn't _make_ the
>>A5/1 and A5/2 and COMP128 algorithms; they just reverse-engineerend and
>>published the source (which the GSM people have been unwilling to do).
>>We at Berkeley (David Wagner and myself) then cryptanalysed the
>>algorithms. They all suck. The one that sucks least is A5/1, which
>>seems to have ~40-bit workfactor. (The A5/1 work wasn't done by us; see
>>the links below.) A5/2 sucks surprisingly hard, with a 16-bit
>>workfactor (i.e. real time break).
>............snip
>
>Even if the Algorithms are known, how much effort would it take
>to decrypt a transmission "on the fly".
>Think this is rather impossible, I cannot imagine a way to do it.
It's just a matter of having a digital scanner, and/or some kick-ass software.
I have a screenshot of a PC program which controls some digital scanner
equipment which lets you listen to GSM conversations in real time. Right
now, it only works for conversations that use "A5/0" (no encryption), but
if the manufacturer of such a system would care to contact me, I'd be
willing to add the ability to decrypt A5/2 in real time, and A5/1 from
a recording...
- Ian
------------------------------
From: David Kessner <[EMAIL PROTECTED]>
Crossposted-To: comp.dcom.vpn,comp.security.firewalls
Subject: Re: High Speed (1GBit/s) 3DES Processor
Date: Wed, 01 Dec 1999 14:32:40 -0700
Reply-To: [EMAIL PROTECTED]
Paul Koning wrote:
> > > 3DES at a 1 Gigabit/sec, like anti-gravity, free desalination,
> > > non-polluting engines, and ADSL, is obviously a billion-dollar
> > > winner. NSA can do 3DES at 1 Gigabit/WEEK with Cray computers.
>
> Where have you been?
>
> Gigabit per second was done as an R&D effort at DEC Palo Alto
> around 1994. Today, commercial off the shelf chips do several
> hundred megabits/second of 3Des for $100 or so.
You can download a DES core for your FPGA from http://www.free-ip.com.
Twelve of these cores can fit into the largest Xilinx Virtex-E FPGA,
achieving
a single-DES performance of 44.4 gigabits/second. Of course, you can
wire
them up serially to get 3DES at 1/3rd the performance-- or a "sluggish"
14.8 gigabits/second. All on a single chip!
David Kessner
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: more about the random number generator
Reply-To: [EMAIL PROTECTED]
Date: Wed, 01 Dec 1999 22:41:34 GMT
On Tue, 30 Nov 1999 17:52:30 GMT, [EMAIL PROTECTED] (Brian Chase)
wrote:
>In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>>Tom St Denis wrote:
>
>>> Optimum compression would reduce the size
>>> of this 417792 bit file by 0 percent.
>
>>This comes directly from the entropy result.
>
>Naive question here. Let's say you had access to some "optimum
>compressor" which would take arbitrary data sets distill them into their
>most compact form. By definition, the resulting data must have no
>predictable redundancies, yes? Could you use optimally compressed data
>sets as sources for random numbers?
>
In theory, yes. It would be roughly the same as a published
list of random numbers. No good for picking keys, but possibly
good for generating Sboxes, or anything else one could use
the Rand tables for.
Unfortunately, practice is a long way from theory. Even
really good compressors rarely produce data that passes
even simple statistical tests. In other words, in practice,
there's no such thing as optimally compressed data.
>It also seems like you could evaluate the effectiveness of current
>compression schemes using this same sort of entropy calculation. Maybe
>it's already common practice, but I can't say that I'm up to date on
>either random number generation, cryptography. or data compression. It
>just seemed like you could run the process sort of backwards.
>
>I think it would be an interesting excercise to figure out how well the
>best lossless compression utilities are at producing pseudo-random
>numbers. :-)
>
You could, but I think the 'size' test (how small the output is)
not only works better, and is easier to do, it's also more
relevant to compression algorithms.
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Elliptic Curve Public-Key Cryptography
Date: 1 Dec 1999 23:01:42 GMT
In article <[EMAIL PROTECTED]>,
DJohn37050 <[EMAIL PROTECTED]> wrote:
>* Comparing vendor's speeds is problematical, as there are many
>factors to consider. However, this is certainly not true for
>Certicom's implementations. I know last year EC SigVer for 163 bit
>key (ANSI X9.62/NIST curve) was in the same ballpark performance-wise
>as RSA SigVer for 1024 bit key and e = F4, which is 17 bits with 2
>bits set to 1. For ramdom 64-bit e (which some people recommend as
>being conservative), it was not even close.
This is kind of interesting about F4. Care to post real benchmarks?
What hardware were you using, and how how fast was your 163 bit EC
verification and what kind of curve was it? If it's a special curve,
how fast can you do a verification for a random curve over GF(p) for
163 bit p? Note that RSA verification with e=F4 will be a lot slower
than Rabin-Williams (e=2) and breaking RW (assuming you get the
protocol right) is provably equivalent to factoring, so EC still has
a ways to go.
------------------------------
From: [EMAIL PROTECTED] (Jim Carr)
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: 1 Dec 1999 22:57:26 GMT
... reduced followups ...
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
}
} [EMAIL PROTECTED] wrote, in part:
} >Given that
} > 1) A and B are complementary
} > 2) A and B are both true XOR A and B are both false
} >then, that 1) contradicts 2) is the essence of Simpson's Paradox.
...
} Quantum-mechanically, a particle can have a state such that "A has
} spin up" is neither true nor false, but subject to a probability
} distribution. But once A is observed, if B is observed later, B may
} have its own probability distribution, or it may correlate with A in
} some fashion. But it can't, after observation, be both spin up and
} spin down, either.
In article <813ums$sug$[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
>
> You're thrashing here abit.
>
> There is no 'probability Distribution' (PD) after the state
> is measured. It's only active while everything is dynamic
> and not measured and in a very large sense it is only an
> abstraction during that interlude between measurements.
There is. It might be a delta function, or (as suggested by
the remarks above) it could be that B is a measurement of
something like the spin along a different axis than A measured.
> A histogram or barchart is a set of possible states with relative
> frequencies attached to each state, but as such it is not
> interpreted probabilistically. It is just a bunch of
> positive amplitudes distributed over the _space_ of states.
Given that the distinction between amplitudes and probabilities
is an important one, using "amplitude" to refer to a probability
is not a good idea.
> If we interpret this histogram or bar chart probabilistically,
> then we get a "probability _distribution_". If we Fourier
> transform this probabilistically interpreted histogram
> or space-like _distribution_ (spectrum) into
> the time-like domain, we get a "probability density _function_" (PDF)
> or "wavefunction". This is just a time-like Function with a
> probabilistic interpretation just as its complementary
> space-like Distribution was given a probabilistic interpretation.
However, it might be real rather than complex. Where the statistical
assumptions of QM differ from those normally used is at this point,
and the exercise you describe cannot recover the complex phase of
the wavefunction that is responsible for what some consider to be
paradoxes.
--
James A. Carr <[EMAIL PROTECTED]> | Commercial e-mail is _NOT_
http://www.scri.fsu.edu/~jac/ | desired to this or any address
Supercomputer Computations Res. Inst. | that resolves to my account
Florida State, Tallahassee FL 32306 | for any reason at any time.
------------------------------
From: [EMAIL PROTECTED] (Mike Rodriquez)
Subject: Re: Elliptic Curve Cryptography
Date: 1 Dec 1999 23:41:59 GMT
hi,
if you go to http://www.hpl.hp.com/techreports/ and search for elliptic, you
will find some papers that may be of interest to you, including one titled:
A Cryptographic Application of Weil Descent
mike
> I'm currently working on a university project
> about Elliptic Curve Cryptography (ECC). I would
> be very grateful, if any of you could direct me to
> some good sources of information on ECC. Both the
> tough math and the implementation details. Online
> web resources would be the best!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Encrypting short blocks
Date: Thu, 02 Dec 1999 00:58:23 GMT
In article <[EMAIL PROTECTED]>, Markus Peuhkuri <[EMAIL PROTECTED]>
wrote:
> Is there an encyprion algorithm that can be used for short
> blocks (variable from ~10 to 24 bits) _and_ the result is same
> length as original data. The key may be much larger (128, 256,
> ...).
>
If it is less than 20 bits a random S-table is all you need.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: more about the random number generator
Date: Thu, 02 Dec 1999 00:28:28 +0000
Scott Nelson wrote:
> On Tue, 30 Nov 1999 17:52:30 GMT, [EMAIL PROTECTED] (Brian Chase) wrote:
> >Naive question here. Let's say you had access to some "optimum
> >compressor" which would take arbitrary data sets distill them into their
> >most compact form. By definition, the resulting data must have no
> >predictable redundancies, yes? Could you use optimally compressed data
> >sets as sources for random numbers?
> In theory, yes. It would be roughly the same as a published
> list of random numbers. No good for picking keys, but possibly
> good for generating Sboxes, or anything else one could use
> the Rand tables for.
> Unfortunately, practice is a long way from theory. Even
In practice the most compressed representation of a
bit string is not computable.
> really good compressors rarely produce data that passes
> even simple statistical tests. In other words, in practice,
> there's no such thing as optimally compressed data.
Hmm, that is interesting. Do you have any references about
the statistical properties of compressed data?
When you consider the Busy Beaver problem it is not really
surprising: using a Turing Machine with only six states you
can put in excess of 95 million bits on a tape and halt. So a string
of 95 million bits can be compressed to a TM-representation with
just 6 states. That is an impressive compression ratio.
Regards,
Coen Visser
------------------------------
From: Seongtaek Chee <[EMAIL PROTECTED]>
Subject: One Round Block Cipher and 8-bit block Cipoher
Date: Thu, 02 Dec 1999 09:37:28 +0900
(a) Suppose I use an 1-round block cipher
with
1) 128-bit key addition
2) a large S-box(128 x 128, e.g., x^{-1} in GF(2^{64}),
which can be calculated directly, even though very slow).
Is it safe?
Which attacks can be considered?
(b) Suppose I use a 64-round block cipher
with
1) 128-bit key
2) 8-bit Input/Output size.
Is it safe?
Which attacks can be considered?
------------------------------
From: Kyle Hayes <[EMAIL PROTECTED]>
Subject: newbie question
Date: Wed, 01 Dec 1999 16:44:56 -0800
Hi folks,
I have the dubious task at work of decrypting data that was encrypted
using the MS Crypto API functions. I am attempting to do this so that
we can move several server side services to other OSes if we need to.
If someone has related experience or can point me toward the right news
group or mailing list I would deeply appreciate it.
I have found implementations of the encryption algorithm that we use,
but I am unable to get/generate the key. We own the code on Windows
that makes the key, but I can't figure out how to use the Crypto API to
get the actual binary string of the key (it is a session key). The
approach I have taken so far is to get or create functions that
duplicate the algorithm. I was going to simply export the encryption
key from the Windows code and use that (symmetric key encryption), but I
can't figure out how to get to the actual
binary value of the key. I am quite new to cryptography, so just the
terminology still confuses me at times :-(
Thanks in advance,
Kyle Hayes
Quicknet Technologies, Inc.
520 Town send St. Suite D
San Francisco, CA 94103
tel +1 415 864 5225
fax +1 415 864 8388
www http://www.quicknet.net
------------------------------
From: Seongtaek Chee <[EMAIL PROTECTED]>
Subject: One round or 8-bit block cipher
Date: Thu, 02 Dec 1999 09:43:41 +0900
(a) Suppose I use an 1-round block cipher
with
1) 128-bit key addition
2) a large S-box(128 x 128, e.g., x^{-1} in GF(2^{128}),
which can be calculated directly, even though very slow).
Is it safe?
Which attacks can be considered?
(b) Suppose I use a 64-round block cipher
with
1) 128-bit key
2) 8-bit Input/Output size.
Is it safe?
Which attacks can be considered?
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: The $10,000.00 contesta
Date: Thu, 02 Dec 1999 00:47:33 GMT
On Wed, 01 Dec 1999 19:49:33 +0000, David Crick <[EMAIL PROTECTED]>
wrote:
>David Crick wrote:
>>
>> Alex MacPherson wrote:
>> >
>> > Bruce Schneier wrote:
>> > "Observation on the Key Schedule of Twofish."
>> >
>> > Could you please send a URL of where I could find this paper.
>> > I would be extremely interested.
>>
>> http://csrc.nist.gov/encryption/aes/round1/conf2/papers/mirza.pdf
>
>Here's the Twofish team's response if you're also interested:
>
> http://www.counterpane.com/twofish-ks2.html
Thanks.
It would be cool if someone could turn this into an attack.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 02 Dec 1999 00:51:47 GMT
On Wed, 01 Dec 1999 19:53:18 +0000, Jim Gillogly <[EMAIL PROTECTED]> wrote:
>Note also that even this information wouldn't tell you whether the
>other four candidates each had an attack that would bring its
>complexity down even lower than the hypothetically broken one.
Which is the problem.
If you don't trust the NSA (or, trust that they will behave
maliciously), then there is nothing they can say that can convince you
that they cannot break something. If you trust them, or trust the
public process enough to ignore them, then you have an easier time.
It's a pity, really. The United States has an enormous amount of
cryptographic expertise in the NSA, and they have played the political
game so badly that we can't use their expertise to its maximum
effectiveness.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Crossposted-To: alt.2600,alt.privacy
Subject: Re: Decyption proof cellphones in Europe? [x3]
Date: Thu, 02 Dec 1999 00:54:33 GMT
On Wed, 01 Dec 1999 13:19:52 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>Bruce Schneier wrote:
>
>> This sounds like an audio summary of Seymour Hersh's excellent New
>> Yorker article on the same topic, which can be found at:
>>
>> http://cryptome.org/nsa-hersh.htm
>>
>> It's really interesting reading.
>
>I'll say! It makes it sound like the NSA is a bunch of incompetent
>morons. How much of that is disinformation?!?!
Don't know, really. Hersch claims to base his writings on interviews
with former high-ranking NSA employees, for what that's worth.
Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Crossposted-To: sci.crypt.reserach
Subject: Fast Software Encryption 2000 - Call for Papers/Participation
Date: Thu, 02 Dec 1999 00:59:20 GMT
FAST SOFTWARE ENCRYPTION WORKSHOP 2000 (FSE 2000)
=================================================
http://www.counterpane.com/fse.html
10-12 April 2000, New York, New York, USA
CALL FOR PAPERS/PARTICIPATION
Fast Software Encryption is an annual workshop on cryptography. The
first Fast Software Encryption workshop was held in Cambridge in 1993,
followed by Leuven in 1994, Cambridge in 1996, Haifa in 1997, Paris in
1998, and Rome in 1999. The workshop concentrates on all aspects of
traditional cryptographic algorithms, including the design and
analysis of block ciphers, stream ciphers, and hash functions. The
seventh Fast Software Encryption workshop, FSE 2000, will be held from
10-12 April 2000, in New York City, New York, USA.
This is the first time FSE will be in the United States, North
America, the New World, and West of GMT. The conference will take
place at the Hilton New York and Towers. It will be in conjunction
with the Third AES Candidate Conference (same location, 13-14 April
2000). We expect that most people will attend both FSE and AES.
CALL FOR PAPERS <http://www.counterpane.com/fse-call.html>
===============
Submissions are due 31 December 1999. Note that the submissions do not
have to be anonymous. Papers on AES candidates submitted to FSE but
considered inappropriate for presentation at FSE will be redirected to
AES unless the authors state in their original submission letter that
they do not wish such a transfer.
WORKSHOP PROGRAM
================
The program will be set on 1 March 2000. There will be one track of
presentations, running all day Monday and Tuesday, and Wednesday
morning.
REGISTRATION <http://www.counterpane.com/fse-registration.html>
============
Because New York is an expensive conference location, a significant
amount of money is reserved for student scholarships. There is no
registration charge for students who have a paper accepted to the
conference. Additional funds are available-for students who have an
accepted paper and those who do not-to help defray travel and hotel
costs. Students are urged to contact the conference chair as soon as
possible and request scholarship assistance.
ACCOMMODATION <http://www.hilton.com/hotels/NYCNHHH/index.html>
=============
FSE 2000 will be held at:
Hilton New York and Towers
1335 Avenue of the Americas
New York, New York 10019
Tel: +1 212 586-7000
Fax: +1 212 315-1374
The room rate for both FSE and AES is $242 per night, single or
double. When you make reservations, be sure to mention that you are
with the FSE conference in order to get the conference rate. (This is
important. In the U.S., hotels give away function space in exchange
for a guarantee of room nights. We have a room block that we have to
make, otherwise we will be charged significantly more for the
conference room. Please stay at the conference hotel if at all
possible. And please make sure to state that you are with the FSE
conference, otherwise we will not receive "credit" for your room
nights.)
In the U.S. and Canada, call toll-free for reservations at
1-800-774-1500. Outside the U.S. and Canada, a list of toll-free
numbers is available online at
<http://www.hilton.com/feedback/hrwfone.html>.
We also have a limited number of rooms at a lower rate at another
hotel less than ten blocks away, which are intended primarily for
student housing. Inquire at [EMAIL PROTECTED] for further
information.
CONTACT INFORMATION
===================
Bruce Schneier
Beth Friedman
phone: +1-612-721-8800
fax: +1-612-721-8800
e-mail: [EMAIL PROTECTED]
http://www.counterpane.com/fse.html
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc. Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
** 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
******************************
