Cryptography-Digest Digest #692, Volume #10 Mon, 6 Dec 99 15:13:01 EST
Contents:
Re: Will ScramDisk recover ? >> After another round of tests ... YES, it (Paul
Koning)
Re: Johnson Device ("Martin Peach")
Re: Johnson Device ("Martin Peach")
Re: Data Encryption in Applet? ("Tim Wood")
Re: Noise Encryption ("Trevor Jackson, III")
Re: Quantum Computers and Weather Forecasting (Richard Herring)
Re: DES ECB vs CBC (Paul Koning)
Re: Wanted: One-way hash sourcecode or algorithm (Paul Koning)
Re: Random Noise Encryption Buffs (Look Here) ("r.e.s.")
Re: Johnson Device (Jim Dunnett)
Re: how to combine hashes to build a 128-bit key? (Stefek Zaba)
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Encrypting numbers? (Michael Groh)
Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
USENIX Security Symposium 2000 - A Call for Papers (Moun Chau)
----------------------------------------------------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,alt.security.scramdisk,comp.security.pgp.tech
Subject: Re: Will ScramDisk recover ? >> After another round of tests ... YES, it
Date: Mon, 06 Dec 1999 12:02:10 -0500
Lincoln Yeoh wrote:
>
> On Fri, 3 Dec 1999 08:04:09 -0500, "Microsoft Mail Server"
> <[EMAIL PROTECTED]> wrote:
>
> >the fact that scramdisk retains the essence of boot,fat, data sector
> >structure is a prime reason it is so durable.
> >
> >try making two identical container files of moderate size. load some text
> >files into the svl's for reference points, then swap the boot sector on
> >each. try swapping the fat structures. very interesting indeed!
>
> What happens?
>
> I'm too lazy to swap boot sectors - I don't have a utility which can copy
> sectors to another file easily.
Boot up linux and use dd. (That's how I repair broken DOS
filesystems...)
paul
------------------------------
From: "Martin Peach" <[EMAIL PROTECTED]>
Subject: Re: Johnson Device
Date: Mon, 6 Dec 1999 11:18:33 -0500
Kurt Fleißig wrote in message <82eau6$do$[EMAIL PROTECTED]>...
>does anybody use an hadrware device to obtain from the thermodynamic
>Johnsons's effect of the Pc's sound blaster a big bit's chaotic stream for
>one-time-pad encryption?
The soundblaster itself is a hardware device...perhaps if you set the input
gain to maximum on the microphone channel, you will have a few bits of
noise, otherwise you could make a plug with a one-megohm resistor between
signal in and ground and try to read the noise directly from the resistor.
You might need a preamplifier though, in which case you will start
amplifying electrical hum and so forth as well, so you need to start being
concerned about shielding the circuit.
\/\/\/*= Martin
------------------------------
From: "Martin Peach" <[EMAIL PROTECTED]>
Subject: Re: Johnson Device
Date: Mon, 6 Dec 1999 11:18:33 -0500
Kurt Fleißig wrote in message <82eau6$do$[EMAIL PROTECTED]>...
>does anybody use an hadrware device to obtain from the thermodynamic
>Johnsons's effect of the Pc's sound blaster a big bit's chaotic stream for
>one-time-pad encryption?
The soundblaster itself is a hardware device...perhaps if you set the input
gain to maximum on the microphone channel, you will have a few bits of
noise, otherwise you could make a plug with a one-megohm resistor between
signal in and ground and try to read the noise directly from the resistor.
You might need a preamplifier though, in which case you will start
amplifying electrical hum and so forth as well, so you need to start being
concerned about shielding the circuit.
\/\/\/*= Martin
------------------------------
From: "Tim Wood" <[EMAIL PROTECTED]>
Crossposted-To:
comp.lang.java.security,microsoft.public.java.security,comp.lang.java.programmer
Subject: Re: Data Encryption in Applet?
Date: Mon, 6 Dec 1999 17:28:49 -0000
wrote in message <[EMAIL PROTECTED]>...
>Hi
>
>I am looking for a way to encrypt data through an applet using symmetric
>(or asymmetric) encryption. I thought of sending an applet containing a
>symmetric key to a client.
How? If the symmetric key is not encrypted when you send it, it could be
intercepted and used to read the, client side encrypted, data.
> This is key is to perform encryption on some
>data on the client side. Anybody has any idea how to do this in Java or
>has any source codes in Java?
>
>Thanks in advance
>
>Greg
>
>
>
tim
--
**<Stolen line alert>**
>From my one-bit brain with a parity error.
**</Stolen line alert>**
------------------------------
Date: Mon, 06 Dec 1999 12:58:26 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Noise Encryption
Guy Macon wrote:
> In article <82g2km$dck$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Wood)
>wrote:
>
> >>The real problem with
> >>OTP is to transport the key by a secure media.
> >
> >This is not always a problem. For instance it is easy for two ships in the
> >same dock to transfer key material bettween the but not two ships that have
> >sailed to opposite sides of the world!
> >
> >If they had exchanged key material they would be able to exchange perfectly
> >secure material.
>
> Question: Is there a method of sending encrypted messages that does
> not at some point require passing secret data (usually a key) between
> the sender and the reciever?
Yes there is. Most PK systems have this property. However there may be a lack of
trust
between entities whose only contact is via cipher.
> If something has to be passed from one to the other, why not a CD-R
> full of random data? (I can think of one answer to this: a key that
> can be memorized has many advantages over a CD-R).
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: 6 Dec 1999 17:57:11 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Joseph Bartlo ([EMAIL PROTECTED]) wrote:
> Trevor Jackson, III wrote:
> > Apostrophe is spelled that way.
> I made no mention of my quality as a speller.
There appeared to be some implicit bragging about your punctuation :-)
But I think you meant at, not @.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: DES ECB vs CBC
Date: Mon, 06 Dec 1999 12:13:59 -0500
Terry Powell wrote:
>
> I was wondering if anyone could help me with this problem.
>
> I've working on adding DES encryption to a wireless system. Messages
> transmitted on this system are generally short, 1 to 256 blocks. A lot
> of the messages are state-of-heath messages from the system thus there
> will be a lot of repitition in the plaintext data. My approach has been
> to use DES in CBC mode and transmit a 64 bit IV ahead of the encrypted
> message. There has been some debate over using CBC mode in this system.
> The main objection is the addition of the IV.
Why? The bandwidth taken? Seems like a trivial issue.
> The alternative design presented to me is DES using EBC mode an placing
> a varying sequence number in the plaintext. The proponents of this mode
> state that it is just as secure as CBC with a plaintext IV (some claim
> it to be "equivelent").
That's not true at all, and whoever told you that is clearly
ignorant of basic crypto.
> I'm having trouble buying their argument. I can understand that adding
> the sequence to the plaintext in EBC mode enhances that mode's security,
> but it seems to me that every block in a message would need to treated
> in this manner to keep it secure. I just don't see how this can be a
> "better" approach.
You're exactly right.
By the way, if this "varying sequence number" is in the first 8 bytes,
you could use CBC with a fixed IV. In effect the sequence number then
performs the role of the IV, and all the rest of the encrypted packet
will end up different even if the plaintext is otherwise identical.
There are some concerns about using IVs that are nearly the same
from packet to packet, but those sound like rather esoteric issues
compared to the very obvious fault that ECB has. (See the IPSEC
RFCs, specifically the one about DES-CBC, for a brief discussion
of the IV issue.)
I'd use regular CBC with a real IV (first one random, subsequent ones
chained from the previous packet, each packet starting with the IV used)
and ignore the extra overhead as an irrelevant concern.
paul
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Wanted: One-way hash sourcecode or algorithm
Date: Mon, 06 Dec 1999 12:08:37 -0500
Mattias Wecksten wrote:
>
> I am searching for a one way hash source or algorithm.
>
> Any information appreciated.
Start with MD5 or SHA-1. MD5 is in RFC1321. SHA-1 is
in FIPS 140-1. Don't know where to find the FIPS, but
RFCs you can download from hundreds of places.
paul
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Date: Mon, 6 Dec 1999 10:13:13 -0800
"Guy Macon" <[EMAIL PROTECTED]> wrote ...
: [EMAIL PROTECTED] (r.e.s.) wrote:
:
: >: Maybe you made a mistake in your calculations?
:
: >Yup -- my apologies to Guy Macon for wrongly impuning his MOM ;-) ;-)
:
: I was actually a bit disapointed reading your apology. My goal is to
: gain a practical undersatanding of this subject, and there is nothing
: like concocting a hairbrained scheme that looks perfect and having it
: shot down in flames by an old salt when it comes to understanding
: something.
:
: I sure did do a great setup for that "impuning his MOM" joke! LOL!
(I meant "impugning", but at least the joke was understood ;-)
As far as shooting down your scheme ...
the lesson from my first (wrong) objection is that the scheme wouldn't
fail because of dependencies among the yi, *as long as* the xi are
independent of the yi (as well as among themselves). You've required
that the yi not be "derived" from xi, but that isn't the same as
requiring them to be strictly independent in the probabilistic sense.
So it seems that as we XOR more and more data in hopes of "accumulating"
"true randomness", we'll also increase the likelihood of encountering
yi that violate the requirement of strict independence from the xi.
(PS: if I'm an "old salt", it obviously isn't in the field of crypto!)
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim Dunnett)
Subject: Re: Johnson Device
Date: Mon, 06 Dec 1999 19:05:06 GMT
Reply-To: Jim Dunnett
On Mon, 6 Dec 1999 11:18:33 -0500, "Martin Peach" <[EMAIL PROTECTED]> wrote:
>Kurt Fleißig wrote in message <82eau6$do$[EMAIL PROTECTED]>...
>>does anybody use an hadrware device to obtain from the thermodynamic
>>Johnsons's effect of the Pc's sound blaster a big bit's chaotic stream for
>>one-time-pad encryption?
>
>
>The soundblaster itself is a hardware device...perhaps if you set the input
>gain to maximum on the microphone channel, you will have a few bits of
>noise, otherwise you could make a plug with a one-megohm resistor between
>signal in and ground and try to read the noise directly from the resistor.
>You might need a preamplifier though, in which case you will start
>amplifying electrical hum and so forth as well, so you need to start being
>concerned about shielding the circuit.
Or connect an FM radio with a dummy antenna and open squelch to the
line input of the soundcard.
------------------------------
From: [EMAIL PROTECTED] (Stefek Zaba)
Subject: Re: how to combine hashes to build a 128-bit key?
Date: Mon, 6 Dec 1999 19:07:29 GMT
In sci.crypt, Juergen Thumm ([EMAIL PROTECTED]) wrote:
> i hash a passphrase using both md5 and sha,
> resulting in a 16-byte md5 and 20-byte sha digest.
> (i do not want to rely only on md5 or only on sha)
> now i want to build 16 bytes (128 bit) key material
> from this, to feed a symmetric cipher.
> the question is: how to reduce the 36 bytes digest
> material to 16 bytes?
> options are:
> 1. truncate sha digest to 16 bytes,
> then XOR md5 and sha digest.
> pro: mixes nearly all bytes together.
With you thus far...
> (the entropy is still reduced, of course)
?How do you reach this conclusion? The variability comes entirely from the
original passphrase. If it is evenly distributed among more than 2^128 possible
values, then so will the md5 digest and the (first 16 bytes of) SHA-1 digest.
If it's not, using the hash functions "smears out" whatever variability is
in the original passphrase over the 128 bits you want for your symmetric key,
but still restricts the range of possible values to below 2^128. (Almost
limiting case: the user passphrase is chosen (fairly and unpredictably) from
the two possibilities "Alpha" and "Bravo". How many trial decryptions need
an attacker perform? That's right, just two. Hence the customary practice
of salting potentially-weak passphrases, to reduce the feasibility of
dictionary attacks.)
Now, let's say that one of your hash functions produces a less-than-ideal
distribution of bits; again, consider a limiting case where it's all 0's,
all 1's, or alternating 0's and 1's. In the first case, you're left with
the output of the other, presumed-strong, hash; in the second, its bitwise
inverse; in the third, every other bit is inverted. Still just as
variable as the unmunged output of the stronger of the two hash functions.
> con: whenever two bytes in both digests
> are the same, they zero-out each other.
Well, yes - and so what? The chances of this happening are one in 2^8 (no,
not one in 2^16 - birthday paradox reasoning applies), precisely the same
as the chance that a randomly-generated byte of session key will be all zeros.
Having an all-zero byte in a symmetric cipher key is of no import; indeed
screening out such all-zero bytes marginally reduces the brute-force
keyspace...
> 2. sequential bytemix:
> target[0] = md5[0]
> target[1] = sha[0]
> target[2] = md5[1]
> target[3] = sha[1]
> ...
> target[14] = md5[7]
> target[15] = sha[7]
> and drop the remaining 8 bytes of md5
> and 12 bytes of sha digest.
> pro: completely keeps the bit distribution
> as supplied by md5/sha.
But since you're presumably worried that one of the hashfunctions might be
weak, this method guarantees that fully half of your resulting symmcipher
keybits are similarly weak. Bad voodoo. Look at that trio of "limiting
cases" above - using this second construction you'd get symmcipher keys
where every second byte was a predictable value (0, 0xFF, 0x55 respectively),
cutting down the keyspace from 2^128 to 3*(2^64). That's *not* what you wanted.
For an accepted, standard way of combining the two hash functions you have
in mind, taking a secret, an (optionally null) text string, and some salt
as inputs, and delivering enough bytes for a symmetric key of "arbitrary"
length, see the pseudorandom function used in TLS (IETF-standards-track
tweak of SSL), as described on pages 11-13 of RFC2246. The hashfunctions
are further wrapped in the "HMAC" construction, giving you greater
confidence that the "secret" input is not derivable from the resulting hash,
and that related quantities (e.g. hash of secret + longer salt) cannot be
simply computed. Unsurprisingly, the TLS construction uses the XOR method
to combine the SHA-1 and MD5 outputs. Better use that standard construction
than a roll-your-own which may be badly flawed...
Cheers, Stefek
> con: more than half of the material
> is simply discarded.
> both options seem to result in an entropy
> reduction of 55.5%. but, for the purpose
> of feeding a 128-bit symmetric cipher key,
> are they really equally good?
(no, as argued above)
------------------------------
Date: Mon, 06 Dec 1999 14:20:47 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
r.e.s. wrote:
> "Guy Macon" <[EMAIL PROTECTED]> wrote ...
> : [EMAIL PROTECTED] (r.e.s.) wrote:
> :
> : >: Maybe you made a mistake in your calculations?
> :
> : >Yup -- my apologies to Guy Macon for wrongly impuning his MOM ;-) ;-)
> :
> : I was actually a bit disapointed reading your apology. My goal is to
> : gain a practical undersatanding of this subject, and there is nothing
> : like concocting a hairbrained scheme that looks perfect and having it
> : shot down in flames by an old salt when it comes to understanding
> : something.
> :
> : I sure did do a great setup for that "impuning his MOM" joke! LOL!
>
> (I meant "impugning", but at least the joke was understood ;-)
>
> As far as shooting down your scheme ...
>
> the lesson from my first (wrong) objection is that the scheme wouldn't
> fail because of dependencies among the yi, *as long as* the xi are
> independent of the yi (as well as among themselves). You've required
> that the yi not be "derived" from xi, but that isn't the same as
> requiring them to be strictly independent in the probabilistic sense.
>
> So it seems that as we XOR more and more data in hopes of "accumulating"
> "true randomness", we'll also increase the likelihood of encountering
> yi that violate the requirement of strict independence from the xi.
But this is precisely why one might sample noise from varied sources. The
correlations do not accumulate. The independence does. In fact the
independence "erodes" the correlations that may be present in any single
source or group of potentially related sources.
The target of this process is entropy. One wants to collect it and then
distill it. Collecting it by overlaying the sample streams is no worse than
collecting and distilling the streams individually and then combining them.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Mon, 6 Dec 1999 19:01:13 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote:
: Rick Braddam wrote:
:> I don't mean to belittle applications where the complete message is not
:> available before transmission starts. I'm just pointing out that they
:> may not be applicable to the majority of users of the Internet.
:> So I'm asking: what type of data are the largest number of users
:> concerned with?
: - http requests. they might be encrypted on one block, but is it worth
: the bother?
Credit-card information in POSTed form data over secure sockets means that
such requests are a rather critical component of security.
: - html pages. If a server has to keep the whole page in memory twice I
: think that would create problems because for servers under heavy load
: this leads to higher memory usage. As to "next year", yes, memory
: might be cheaper then, but the number of internet users will have
: increased too.
: - Sound and video. This is NOT only commercial. There are many
: non-commercial videos and sounds out there.
...and not forgetting another application where people actually use
encryption today: email - the modern letter.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Under construction - but it's getting beta, beta and beta.
------------------------------
From: [EMAIL PROTECTED] (Michael Groh)
Subject: Encrypting numbers?
Date: Mon, 6 Dec 1999 14:40:26 -0500
I have a question that may seem rather obvious to some people, but I
haven't found a simple answer yet. While reading Singh's book ("The Code
Book") I noticed that none of the simpler encryption techniques
specifically address encrypting numeric values. Consider something as
simple as "$14.37". How can that value be encrypted using a Vigenere or
substitution cipher? Even the Enigma machine doesn't include a numeric
row on its keyboard. How did the German military transmit numeric values
(persumably including + and - signs, decimal points, etc.) using the
Enigma machine?
TIA for an enlightenment!
- Mike
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Mon, 6 Dec 1999 19:18:01 GMT
Kenneth Almquist <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote:
:> Kenneth Almquist <[EMAIL PROTECTED]> wrote:
:>: My guess is that the information from the NSA which influences the
:>: AES selection will be made public, because as you point out, keeping
:>: the information secret would be difficult.
:>
:> Keeping information secret is part of the NSA's job.
: Exactly. That's why I expect them to summarize their evaluation of the
: AES candidates in a way which protects any NSA secrets. [...]
Any information that they can break an AES candidate in a way that the
open community has failed to spot would be unreasonable to expect them to
release.
Should they wish to point out a flaw in an algorithm, the information
may be released in such a manner that it does not appear to originate from
them.
If a public evaluation is made by them, don't expect it to say anything
that the public community doesn't already know.
: I would not expect the NSA to rely on NIST to protect the NSA's secrets
Um, no, neither would anyone else...?
:>: [...] if the NSA breaks one of the finalists, the fact that
:>: the encryption algorithm had been broken would rule it out of
:>: consideration.
:>
:> It is not clear whether this is true. What does the number 56 mean
:> to you?
: It's the key length of DES. It's also a good measure of the strength
: of DES, because the NSA worked with IBM to make DES resistant to
: differential attacks. When DES was standardized, some people suggested
: that the NSA might have hidden a trap door in the algorithm. It is
: now clear that the NSA did not do this.
You don't think 56-bits is a slightly small figure? Even for its day?
I'm not sure if such an obvious restriction qualifies as a "trapdoor",
since it's out in the open, but it is certainly a weakness.
: As a result, we have some reason to have confidence in subsequent
: NSA work on encryption standards.
I'm sure what work they do is of excellent quality. My only concern is
that it does not have the same goals as those of others in the area ;-)
If you think that they have a history of playing the good guy in the
public cryptography scene, there are a number of alternatives you should
consider. One is that their image in this area is largely a fabrication.
It is true that DES resists certain types of attack which it might
otherwise have been vulnerable to, as a consequence of their involvement.
To generalise from this to a general benvolence on their part towards
public cryptography would be unwise, IMO.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
44 Magnum: the ultimate point-and-click user interface.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Mon, 6 Dec 1999 19:34:06 GMT
Guy Macon <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim Tyler) wrote:
:>Without a source of genuinely random numbers a one-time pad falls short of
:>theoretical perfection - and unfortunately, no source of demonstrably
:>genuinely random numbers is - or IMO is ever likely to be - known to
:>mankind.
: There are many things that are non-provable (including the theory that
: you are reading this on a computer screen instead of halucinating).
: theoretical perfection of an OTP and genuinely random numbers fall
: into this catagory, so you are 100% correct.
: Consider. if you will, MOM (Macon's Overkill Method or Massive Overkill
: Method) of generating "random" numbers:
[snip hamster wheels, AM radio, coin flipping, keystroke timing, PRNGs,
FM noise, Diode noise, Radium emissions, etc ]
This is the approach to generating RNGs followed by George Marsaglia
when he made his "randomness" CD.
It is the approach I would recommend. In particular, I think the use of
PRNGs is very important, although they add little real entropy to the
signal.
If use of PRNGs is, or is ever likely to be irrelevant to generating
numbers for use with OTPs, I would be interested to learn more about it.
However, this hoes not appear likely. Use of PRNGs to mask source
statistics looks like it will remain on the cards to me.
: There is one other consideration. Does "Biased" imply
: "Insecure" in an OTP? If I made an OTP with a coin flip
: that was 0.1% more likely to turn up heads but was
: otherwise random, could an attacker use this method to
: decode my OTP encrypted messages? If so, how many bits
: of cyphertext would he have to analyse to exploit this
: bias?
They would have a 0.1%-better than chance try at guessing each letter
of the plaintext. This would probably not be of much use in practice.
It may allow them to reject particular plaintexts, based on a bunch of
cumulatively unlikely choices if the message is long enough - but that's
about the size of it.
: In my opinion, simple precautions such as padding the
: plaintext to a standard length, varying how much of the
: padding goes before or after the plaintext, compressing
: the plaintext, using a CRC checksum to attempt to
: detect errors in the decoded message, or never sending
: the exact same plaintext to two different recipients
: do not qualify as modifications to the "purity" of
: an OTP scheme.
Hmm. I'd have to say that I firmly agree with Douglas's comment along the
lines that you *really* should not employ schemes where knowledge of the
plaintext leads directly to the key.
A system where a known-plaintext attack leads directly to the ability to
send a faked message is really not good.
Even if you are only ever sending a message to a single recipient,
this property should immediately set loud alarm bells ringing in the
heads of security-conscious people.
Signing the message helps, of course.
However with such a huge key available, you ought to be able to do
something that is pretty secure and not vulnerable to
known-partial-plaintext attacks in the first place.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Three dreaded words: hard disk failure.
------------------------------
Crossposted-To:
muc.lists.www-security,ocunix.mail.freebsd.security,alt.fan.sysadmin,comp.infosystems.www,comp.infosystems.www.servers.unix,comp.unix.osf.osf1,hannet.ml.linux.rutgers.linux-admin,comp.unix.solaris
From: [EMAIL PROTECTED] (Moun Chau)
Subject: USENIX Security Symposium 2000 - A Call for Papers
Date: Mon, 6 Dec 1999 19:34:23 GMT
9th USENIX Security Symposium 2000 Conference
August 14 - 17, 2000
Denver, Colorado, USA
Conference URL: http://www.usenix.org/events/sec2000
The USENIX Security Symposium brings together researchers,
practitioners, system administrators, systems programmers, and others
interested in the latest advances in security and applications of
cryptography. The keynote speaker is Dr. Blaine Burnham, Director of the
Georgia Tech Information Security Center (GTISC) and formerly Program
Manager for the National Security Agency (NSA) at Ft. Meade, Maryland.
We are currently seeking submissions for Refereed Papers,
Works-In-Progress Reports, Talks/Panel Session proposals, and Tutorial
presentation proposals for this event. If you are working in any
practical aspect of security or applications of cryptography, the
program committee urges you to submit a paper.
Please see the detailed author guidelines, which include a sample
abstract, for more information.
http://www.usenix.org/events/sec2000/cfp/guidelines.html
=============================================
IMPORTANT REFEREED PAPER SUBMISSION DATES
*Paper submissions due: February 10, 2000
*Notification to authors: March 23, 2000
*Camera-Ready Final papers due: June 15, 2000
=============================================
USENIX Security Symposium 2000 is sponsored by USENIX, the Advanced
Computing Systems Association, in cooperation with the CERT Coordination
Center. USENIX is an international membership society.
------------------------------
** 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
******************************
