Cryptography-Digest Digest #158, Volume #11 Sat, 19 Feb 00 14:13:01 EST
Contents:
Re: NIST publishes AES source code on web (Tim Tyler)
Re: NSA Linux and the GPL (Casper H.S. Dik - Network Security Engineer)
Re: shorter key public algo? (David Hopwood)
Re: EOF in cipher??? (JPeschel)
Re: NIST publishes AES source code on web (Mok-Kong Shen)
Re: Keys & Passwords. (fvw)
Re: NIST, AES at RSA conference (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: Q: Division in GF(2^n) (Jerry Coffin)
Re: EOF in cipher??? (Albert P. Belle Isle)
Re: PhD in Cryptography? ([EMAIL PROTECTED])
Re: NSA Linux and the GPL (Lincoln Yeoh)
Re: Guaranteed Public Key Exchanges (No Brainer)
Re: Question about OTPs (Tim Tyler)
Re: EOF in cipher??? (Jerry Coffin)
Re: Question about OTPs (Tim Tyler)
Re: Keys & Passwords. (wtshaw)
Re: Keys & Passwords. (wtshaw)
Re: PhD in Cryptography? (David A Molnar)
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Feb 2000 15:16:44 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: I am ignorant of the text of the said EAR, not to mention its
: 'correct' interpretations [...impressions snipped...]
: Since my above said impression is obviously or highly probably wrong,
: I must logically conclude that AES is in fact NOT a strong crypto.
It is non-commercial, with public source code. This bit seems to apply:
``encryption source code that would be publicly available (and posting to
the Internet itself would make it publicly available), and which is not
subject to an express agreement for the payment of a licensing fee or
royalty for the commercial production or sale of any product developed
using the source code, would be eligible under License Exception TSU for
"unrestricted" source code. Under this policy, the software may be
exported without prior submission to the government for technical review
(although concurrent notification of the export is required). In
addition, software exported under this exception may be posted to the
Internet without restriction and would not be subject to any requirement
to screen for access. Also, such posting would not constitute knowledge
of an export to a prohibited destination under the EAR, including one of
the seven terrorist states. ''
...from: http://www.bxa.doc.gov/encryption/qanda.htm
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Legalise IT.
------------------------------
From: [EMAIL PROTECTED] (Casper H.S. Dik - Network Security Engineer)
Subject: Re: NSA Linux and the GPL
Date: 19 Feb 2000 15:15:29 GMT
[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
"Douglas A. Gwyn" <[EMAIL PROTECTED]> writes:
>As another poster hinted, no matter how much the security of Linux
>is beefed up, it will not become Multi-Level Secure, and hence its
>security will never be relied upon to act as a barrier between the
>public and classified information. Classified information is
>protected by not being kept in the same places that the public has
>access to.
Currently NSA doesn't trust any software barriers between classified
information. Physical separation is what they use (some have three
differently classified desktops because of this)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
------------------------------
Date: Sat, 19 Feb 2000 16:25:13 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: shorter key public algo?
=====BEGIN PGP SIGNED MESSAGE=====
Mike Rosing wrote:
> [EMAIL PROTECTED] wrote:
> > elliptic curves maybe..
> > there is programs already using ec (Pegwit for example:
> > http://ds.dial.pipex.com/george.barwood/v8/pegwit.htm)
> > still there is a question how secure this realy is..
>
> ECC with correct parameters is plenty secure.
Yes.
> You can use 100 bit keys with ECC and get the same as 768 RSA
> security.
That sounds a bit optimistic. 100 bit ECC is very close to being broken
in a public attack; 768 bit RSA isn't.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOK7DzzkCAxeYt5gVAQE+Awf+Nm4gJkGIJiyn66MGaKbh37M84eod3HZc
pMOvADCs1LlIc6ExPvnNINt1N2czD+C7hUuwpvgCjkBF/J/LJiD9wXbhsNahmNoE
y51TIolagdmdyVK7nfUyIgflfyqXutANPzWmJj3ag8yQH2EADJVxX7DN1h6IO/Z6
tBNUiWUmMTrNlc4/kNCCUPCEZcojhVWAgdNWIvcSp3d3XrwQZNLIdWovvlvZFLic
ncMrcfA99g/1JMyCAFeEY5fqQzXbZ+l3GKHtxVcgfnQjmSCFirKbikZnTUmSv4Tr
Za63IDzNtj5t6ZIBHNwAYB1lBxDPdqEYBmeDBzMmH6CDm2Civ93+MA==
=+z1s
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: EOF in cipher???
Date: 19 Feb 2000 17:08:04 GMT
>Mok-Kong Shen [EMAIL PROTECTED] writes:
>In a situation where everyone says his opinions are right and
>those of the others are not, it is pretty hard for a non-expert
>to sort out the correct code postings, I am afraid.
Mok, if you are trying to learn C, I'd suggest you value
Doug's technical opinions over the opinions and coding
styles of others here, including myself.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NIST publishes AES source code on web
Date: Sat, 19 Feb 2000 18:16:05 +0100
Tim Tyler wrote:
>
> It is non-commercial, with public source code. This bit seems to apply:
>
> ``encryption source code that would be publicly available (and posting to
> the Internet itself would make it publicly available), and which is not
> subject to an express agreement for the payment of a licensing fee or
> royalty for the commercial production or sale of any product developed
> using the source code, would be eligible under License Exception TSU for
> "unrestricted" source code. Under this policy, the software may be
> exported without prior submission to the government for technical review
> (although concurrent notification of the export is required). In
> addition, software exported under this exception may be posted to the
> Internet without restriction and would not be subject to any requirement
> to screen for access. Also, such posting would not constitute knowledge
> of an export to a prohibited destination under the EAR, including one of
> the seven terrorist states. ''
If this is indeed true, any crypto designer who has no monetary
interest can now enitrely freely publishes or exports his algorithms.
(If one publishes on the web, one is in fact exporting to the
ENTIRE world. Does he need to notify the authority before publishing
or can he do that after the fact?) This is however radically opposite
to the previous strong positions and practices (cf. the cases of
Bernstein and Zimmermann) of the authorities. Is the quote above
taken from an official document? If not, I am not yet convinced
that that could be the official position. If yes, I suppose one of
the titles of Shakespeare's work applies superbly to what the
bureaucrats have done in the issue of export regulations of crypto
for decades (and also to the work of those scientists who have
fervently supported key-escrow) and a psycho-analytic study of
their behaviour would be called for!
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (fvw)
Subject: Re: Keys & Passwords.
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Feb 2000 17:36:15 GMT
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>> Try md5sum, from the gnu textutils package. it can read your pw from stdin,
>> and spit out the md5 hash. (You'd probably still want to convert the hash
>> from hex to most of the ascii set...)
>
>If the conversion from a pair of hex leads to an unprintable ASCII
>symbol or to one not convenient for me to type in or to memory, what
>should I do?
Just using the hex to bytes would not work, as you say. You'd have to
find/write a program to convert it to something ascii between 32 and 126.
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 19 Feb 2000 17:28:41 GMT
On Thu, 17 Feb 2000 19:03:18 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>But if NIST is using tests which cannot be replicated by other
>researchers, that is not Science. And if their decisions are being
>made *outside* of Science, our worst fears are enabled for everything
>from incompetence to corruption to conspiracy.
I hope that either that part of the original post was inaccurate, or
if NIST is withholding information on some statistical tests it has
applied, that is because they rely upon advanced techniques provided
by the NSA - and thus, this is being done for a legitimate reason, to
avoid giving a free boost to the cryptanalytic capabilities of hostile
foreign powers.
I think that the final decision on the winner of the AES, absent a
cryptanalytic victory against all but one of the candidates, will
necessarily be made "outside of science", based on gut feelings,
aesthetic preferences, and cryptanalytic intuition. (Or, worse yet,
they might just pick the one that is fastest among those that are not
cracked: that is "objective", but it's like the old saw about the
rocket containing a million parts, each one supplied by the lowest
bidder.) I can wish for the world to be a better place than it is, but
this is an unavoidable consequence of the fact that we can't prove any
work-factor-based cipher to be secure.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Sat, 19 Feb 2000 17:21:56 GMT
On Fri, 18 Feb 2000 13:00:40 GMT, [EMAIL PROTECTED] (Bo
Dömstedt) wrote, in part:
>Suppose two ciphers A and B are compared, and A fails statistical
>test Xn. When subject to a massive cryptanalysis effort, is it
>obvious that A is weaker than B? Or is B weaker than A?
I think that all I can say to this is to repeat what I've already
said.
A cipher can pass all statistical tests, and still be horribly weak.
With certain specific exceptions, however, such as a cipher that
expands the input in length, a cipher that fails any statistical test
is certain to have a weakness, and a serious one.
Therefore, it is entirely legitimate that NIST eliminate from
consideration candidate ciphers that fail statistical tests. They are
not proven to be weaker than other ciphers not eliminated, and thus
those other ciphers still need to be - as they have been - subjected
to intense cryptanalytic study. But they are known to be unacceptably
weak, and so there is no reason not to eliminate them immediately,
even if other candidates will later be found to be even weaker, in
which case they, too, will be eliminated.
Of course, one is assuming without proof that not *all* the AES
candidates other than the one eliminated are even weaker than one of
those that failed statistical testing. But that is an extremely
unlikely occurence, and would justify not establishing an Advanced
Encryption Standard based on any of the candidates as well.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Q: Division in GF(2^n)
Date: Sat, 19 Feb 2000 11:06:56 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> I can't apprehend your fence concept well. As far as I know, even
> the property right concerning, say, a house, is not 'absolute'.
> If there are strong reasons of the community that a highway has to
> be built right through the site where one's house is, that house
> has to go away, if I don't err. Of course, there is redemption in
> this case, but that's not the point here (the point is that one has
> to yield to the interests of the community and can't insist on
> keeping his house such that the highway couldn't be built).
The same can (and does) happen with patents. Just for one example,
when Xerox invented the photo-copier, the US Government granted the
patents, but told them they wouldn't be allowed to enforce them --
they considered the technology too important to business in general to
allow any one company to have a monopoly on it, so they simply refused
to allow those patents to be enforced.
> How do you define your 'really fundamental' in contrast to 'not so
> really fundamental'? If you can't do that well and leave that
> decision to the officers of the patent office, then there is well a
> good chance of obtaining the 'bad thing'. (Of course, I admit it is
> also difficult to precisely define 'your' concept of 'bad thing'.)
Perhaps re-phrasing would help: I think that it's VERY rare at this
point for somebody to come up with something that's new and novel, but
of SUCH huge utility that suddenly nobody else can get along without
it.
> This was a 'hypothetical' case used only for the purpose of arguments.
> But what would do you think in case there had never been round
> buildings? (Incidentally, to 'show' some accomplishments in the
> present case happens to be not very difficult. But this is not
> essential for the present discussion.)
The problem is that it's hard to comment on a hypothetical case.
You'd have to define exactly what the prior art was, and what the
invention improved. For example, do we assume that no previous
complete building was round, but there WERE things like round turrets
on ancient castles? If so, building the round part separate from the
rest probably shouldn't be open to patent protection.
By contrast, if we assume a world where nobody has ever built ANYTHING
what any sort of curvature to it at all -- nothing like roman arches,
Greek columns or medieval turrets ever happened at all -- then yes,
the first round building would probably at least be original enough to
be worth considering for a patent. The first roman arch almost
CERTAINLY ought to be patentable -- I can hardly imagine anybody
denying that it's one of the greatest inventions of all time.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Sat, 19 Feb 2000 13:06:36 -0500
Reply-To: [EMAIL PROTECTED]
On Sat, 19 Feb 2000 07:31:16 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Mok-Kong Shen wrote:
>> ... Could some experts please post a piece of C or C++ code
>> for writing AND reading binary stuffs ...
>
>If you can't sort out the correct responses, how are you going to
>sort out the correct code postings? In fact, I posted correct
>information on this. I'm not going to list all my C credentials
>here, but for example I'm acknowledged in K&R 2nd ed. and am on
>the C standards committee, which should be some indication.
>
>/* copyfile -- make an exact copy of a file */
>#include <stdio.h>
>#include <stdlib.h>
>int main(int argc, char **argv) {
> register int c;
> register FILE *ifp, *ofp;
> if (argc != 3) {
> fprintf(stderr, "Usage: copyfile from to\n");
> return EXIT_FAILURE;
> }
> if ((ifp = fopen(argv[1], "rb")) == NULL) {
> fprintf(stderr, "copyfile: can't open %s\n",
> argv[1]);
> return EXIT_FAILURE;
> }
/*
> if ((ifp = fopen(argv[2], "wb")) == NULL) {
*/
/* I'm pretty sure you intended this */
if ((ofp = fopen(argv[2], "wb")) == NULL) {
> fprintf(stderr, "copyfile: can't create %s\n",
> argv[2]);
fclose(ifp);
> return EXIT_FAILURE;
> }
> while ((c = getc(ifp)) != EOF)
> if (putc(c, ofp) != c) {
> fprintf(stderr,
> "copyfile: error writing %s\n",
> argv[2]);
fclose(ifp);
fclose(ofp);
> return EXIT_FAILURE;
> }
> if (ferror(ifp)) {
> fprintf(stderr, "copyfile: error reading %s\n",
> argv[1]);
fclose(ifp);
fclose(ofp);
> return EXIT_FAILURE;
> }
fclose(ifp);
fclose(ofp);
> return EXIT_SUCCESS;
>}
Mr. Gwyn:
Since everyone and his brother has felt compelled (compiled?<g>) to
add something to your (obviously knowledgable) postings, I'll pick a
nit by mentioning the apparent absence of a few fclose() statements in
order to actually be able to produce a copied file on disk and not
leave the files in a potentially hazardous condition (at least on
Wintel platforms, where you might also reconsider being explicit about
"register" if using any good optimizing compiler - though I guess bad
ones are part of the discussion).
(I'm not trying to be a "smart alec" and do realize that you're
illustrating a specific point about the use of EOF, not necessarily
posting "cut-and-paste" production code, but one never knows who'd try
to so use your otherwise elegant example.)
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PhD in Cryptography?
Date: Sat, 19 Feb 2000 18:07:01 GMT
In article <88h7a8$a04$[EMAIL PROTECTED]>, Bob Silverman <[EMAIL PROTECTED]>
wrote:
>
> It is my personal opinion that a PhD in *any* field should
> be only undertaken because one loves the subject.
Good aesthetic; bad policy.
> ...I were sitting on an acceptance committee, and knew that
> an applicant was motivated by "marketability", I would turn
> that candidate down. No offense intended.
That's dumb. No offense intended.
The process of earning a PhD was designed to filter out folks
with no ability. It doesn't always work, of course, but it's
in place. Your job on such a committee is not to determine
who morally deserves a PhD!
If I want a PhD in Math, ``to make my life into a performance-
art critique of blah blah blah,'' _and_ I write a competent
PhD thesis, then guess what? I deserve a PhD.
Len Budney
PhD Math, Syracuse University, 1996 (I love math)
MS Comp. Sci., Syracuse, 1996 (I need to eat)
--
That's security through obscurity. The more people know about
it, the more useless it is.
-- Dan Bernstein
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Lincoln Yeoh)
Subject: Re: NSA Linux and the GPL
Date: Sat, 19 Feb 2000 18:23:06 GMT
Reply-To: [EMAIL PROTECTED]
On Sat, 19 Feb 2000 06:11:57 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>As another poster hinted, no matter how much the security of Linux
>is beefed up, it will not become Multi-Level Secure, and hence its
>security will never be relied upon to act as a barrier between the
>public and classified information. Classified information is
>protected by not being kept in the same places that the public has
>access to.
Actually PCs are rather cheap nowadays. So if I really want secure barriers
I might as well buy separate PCs. Working out secure ways of transferring
just data between these PCs is a much easier problem to solve.
Taking a look at the cost of typical MLS systems, this approach isn't too
bad ;).
Furthermore, it is easier to check if it even has a remote chance of being
safe...
Cheerio,
Link.
****************************
Reply to: @Spam to
lyeoh at @[EMAIL PROTECTED]
pop.jaring.my @
*******************************
------------------------------
From: No Brainer <[EMAIL PROTECTED]>
Subject: Re: Guaranteed Public Key Exchanges
Date: Sun, 20 Feb 2000 02:24:50 +0800
To all,
<snip>
Ralph, Darren wrote:
> >> In a totally theoretical model I can't fault your reasoning. The
> >> original question appeared to me to be founded on a possible realistic
> >> situation.
> >
> >Yes. The original question was "you have an email address for Joe. How do
> >you exchange keys securely." Scroll back in the thread. :-)
>
> That was my impression too.
And you guys are right.
How about if the security model started before it even got to the MITM?
Where does the MITM actually start over the wire?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Feb 2000 18:31:26 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] wrote:
:> Arthur Dardia <[EMAIL PROTECTED]> wrote:
:> : As we all know, many people are becoming interested in
:> : one time pads due to their "perfect" security system.
:> : Yes, while this system is perfect with totally random
:> : data and a "perfectly" secure way to transfer the
:> : pad-file, this is rare to come by.
:>
:> I don't know about that.
:>
:> A OTP fails against a complete known plaintext attack -
:> which immediately reveals the key.
: That's like saying a cat fails to be a dog.
Which makes reasonable sense in reply to someone calling a cat a dog.
:> It has about the best possible resistance to cyphertext-only attack,
:> that's all.
: Not so. The important property of the OTP is "perfect
: secrecy", and it maintains this property regardless of the
: attacker's a priori knowledge about the plaintext.
You /appear/, perhaps, to have misinterpreted my "that's all" as "that's
the only attack it defends against".
The attacker's knowledge of the plaintext influences his ability to forge
messages, not what information he can glean from their cyphertexts.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Destroy Microsoft.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Sat, 19 Feb 2000 11:45:17 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> fclose(ifp);
> fclose(ofp);
>
> > return EXIT_SUCCESS;
> >}
[ ... ]
> (I'm not trying to be a "smart alec" and do realize that you're
> illustrating a specific point about the use of EOF, not necessarily
> posting "cut-and-paste" production code, but one never knows who'd try
> to so use your otherwise elegant example.)
If you're going to pick nits, you should probably check the return
value from fclose (at least on the output file) and only return
success if you can close it correctly -- in some cases, output buffers
aren't flushed until you close the file, and if you run out of disk
space, all the writes can seem to succeed, but closing the file
fails...
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Reply-To: [EMAIL PROTECTED]
Date: Sat, 19 Feb 2000 18:40:03 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> ... It would have 15 different "homophones" for
:> A (chosen at random), and one for B.
: I thought we were talking about compressors, not expanders.
This would represent the message in 4 bits - as opposed to a whole byte
for the plain ASCII representation ;-)
It's an awkward terminological issue, though.
What /should/ I call the type of non-deterministic map that attempts to
transform the file in such a way that all outputs are equally likely,
while not bulking up the file unnecessarily, or padding using
pseudo-random numbers? ;-)
It's hardly "using homophones".
If there's a better existing technical term, I'm keen to learn of it.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
"Understand" is too strong a word.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Keys & Passwords.
Date: Sat, 19 Feb 2000 12:02:14 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> fvw wrote:
> >
> > [EMAIL PROTECTED] wrote:
> > >Does someone happen to know a simple but not bad hashing program
> > >that converts a normal passphrase to {a-z, 0-9} or another set with
> > >elements that are human-friendly for input (and memory)?
> >
> > Try md5sum, from the gnu textutils package. it can read your pw from stdin,
> > and spit out the md5 hash. (You'd probably still want to convert the hash
> > from hex to most of the ascii set...)
>
> If the conversion from a pair of hex leads to an unprintable ASCII
> symbol or to one not convenient for me to type in or to memory, what
> should I do?
>
> M. K. Shen
Welcome to display in a convenient base, base 16 or 64 being the most common.
--
Let's all sit back an watch the inhabitants of the political zoo
perform in three rings. It's more exciting than soap operas. Then
vote out anyone who has been in long enough to abuse things.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Keys & Passwords.
Date: Sat, 19 Feb 2000 11:59:24 -0600
In article <88l59v$lle$[EMAIL PROTECTED]>, "r.e.s."
<[EMAIL PROTECTED]> wrote:
> The above makes the assumption that an attacker knows the algorithm
> itself, including how the key is generated from the password.
Given a known encryption algorithm, A, a desired sized working key, B, a
means of generating it, C, and the actual keyphrase that might be entered,
D, there are many possible C's, have drastically different strength
efficiencies in producing a key, B.
Making C a constant in debate does little to do with discovering how B
might actually range in strength if directly entered. Even more of a
concern is justifying a good or bad D, since the nature of C can determine
what values of D will be accepted, and how they can be used.
In fact, a generator, C, can be made to work harder at producing a good
key, B from a poor or short D than a long one. This may seem
counterintuitive, but remember that a key, B, most difficultly created in
one C might be trivially created in another C. A specific generator, C,
can be designed to to such weird things, and C might be kept private as
well.
Figure that B has a maximum number of possibilities. Measaure the
efficiency of C in what part of keyspace might be generated, and the hash
character of the generator to keep original D's from being determined.
--
Let's all sit back an watch the inhabitants of the political zoo
perform in three rings. It's more exciting than soap operas. Then
vote out anyone who has been in long enough to abuse things.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: PhD in Cryptography?
Date: 19 Feb 2000 18:46:54 GMT
Nathan <[EMAIL PROTECTED]> wrote:
> are pro-PhD, any suggestions on good places (and people under whom) to
> study number theory as applied to crypto (I would be more specific, but
> I haven't decided myself), especially in Canada, would be most helpful.
> Thanks in advance.
David Wagner has a summary of responses to a similar question in 1994.
http://www.cs.berkeley.edu/~daw/my-posts/phd-summary
Some notes :
* as noted elsewhere in this thread, UWaterloo has an excellent Centre for
Applied Cryptography. You may find that to your liking, especially if
you are concerned about jobs outside of academia. They also seem to
deal with practical implementations of one-way functions, and how
boolean functions really work, and S-boxes, and other things which
could be useful.
* I think Manuel Blum has moved or is moving to CMU from UC-Berkeley.
* Worcester Polytechnic Institute in MA has a program which has published
some interesting work on hardware implementations of cryptography and
neat ways of speeding them up. They also sponsor the CHES workshops
on "cryptographic hardware and embedded systems."
* University of California, San Diego has a lot to recommend it as well.
Mihir Bellare is there -- he is into "practice oriented provable
security." Also Daniele Miccancio, who is an expert on lattices,
lattice basis reduction, and its uses in making and breaking
cryptosystems. Plus others whose names escape me off the top of my head.
* This may be a bit far afield, but NTT and Tokyo University do a lot
of practically-oriented crypto. Check out Tatsuaki Okamoto's list of
papers for examples. Everything from elliptic curves to signcryption
schemes.
* Columbia has Moti Yung, and Stuart Stubblebine -- do you like digital
cash and electronic commerce? do you like logics? Plenty of applications
there.
Thanks,
-David
------------------------------
** 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
******************************
