Cryptography-Digest Digest #354, Volume #14 Mon, 14 May 01 17:13:01 EDT
Contents:
Revised copy of Noekeon analysis paper ("Tom St Denis")
Re: DES Crypto Myth?? (DJohn37050)
Re: DES Crypto Myth?? (Mok-Kong Shen)
Re: best algo ("Nils Johansson")
Re: best algo ("Tom St Denis")
Re: Revised copy of Noekeon analysis paper ("Tom St Denis")
Re: best algo ("Henrick Hellstr�m")
Re: best algo ("Tom St Denis")
Re: best algo ("Henrick Hellstr�m")
Re: best algo ("Nils Johansson")
Re: extracting random bits from low-entropy data (Gregory G Rose)
Re: good x86 coders (help please) (Paul Rubin)
Re: Revised copy of Noekeon analysis paper ("Sam Simpson")
Re: Revised copy of Noekeon analysis paper ("Tom St Denis")
Re: good x86 coders (help please) ("Tom St Denis")
Re: best algo ("Tom St Denis")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Revised copy of Noekeon analysis paper
Date: Mon, 14 May 2001 19:16:58 GMT
I've updated the draft to correct a few technical typos and correct the
spelling of the authors... (oops sorry).
BTW I would like comments (either to the group or via email). feel free to
critique the paper, etc.
http://tomstdenis.home.dhs.org/na.ps.gz
http://tomstdenis.home.dhs.org/na.pdf
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 14 May 2001 19:20:22 GMT
Subject: Re: DES Crypto Myth??
Yes, it might have been tickle. The idea is that it was a small change.
Don Johnson
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: DES Crypto Myth??
Date: Mon, 14 May 2001 21:45:41 +0200
Jim Gillogly wrote:
>
> Mok-Kong Shen wrote:
> >
> > Tim Smith wrote:
> > >
> > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > >On the other hand, the public crypto community does have
> > > >the advantage of having a pool of academic researchers
> > > >which is presumably significantly larger in size than
> > > >that of the experts employed in any single secret agency.
> > >
> > > Why do you presume that?
> >
> > I assume on plausibility grounds that they are more
> > people who prefer to serve the well-being of the general
> > public than otherwise (i.e. at least partly or sometimes
> > against that), just like in the modern era there are in
> > the whole world more people for the democracy than those
> > who are happy to work for certain totalitarian powers.
>
> I don't find these "plausibility grounds" compelling. I suspect
> you will find that government researchers in black chambers around
> the world feel they too are serving the well-being of the general
> public... or at least the well-being of the public of their country.
> I don't find your last half compelling, either: people generally find
> that by some startling coincidence their loyalty lies with the country
> where they were raised. Most Chinese cryppies will feel that their
> work will best be used in the service of China's interest; similarly
> for Russians, Israelis, French and Germans, irrespective of the
> nature of their government.
>
> I would be more persuaded by comparisons of the number of people
> trying to publish in refereed crypto conferences and journals with
> (say) Bamford's estimates of the number of crypto researchers at NSA.
>
> No, I'm not motivated to look up these numbers myself.
Since the internals of secret agencies are by definition
unknown to the public (one couldn't even know their
exact numbers in the world, I suppose), all we can do
are speculations. What I am considering is an apparently
natural tendency of a transition analogous to the
transition from the ancient period (say the time of
Galilei), where the knowledge was in the hands of
a minority of the priviledged (often under severe
influence of religions), to the modern era, where the
scientific knowledge is almost exclusively in the hands
of the public. (Some religious institutions continue
to have very good scientists working for them even today,
but their number is negligible.) The world is becoming
increasingly 'open'. I doubt that patriotism in the
narrow sense is today comparable to that of fifty years
ago, though it is certainly in the interest of certain
politicians to try to keep that intact (if necessary
through 'provoking' wars). It could be yet true that
the pool of scientists of the biggest secret agency is
larger than that (of comparable scientists) of the
'whole' of the public world. But in my personal
conviction the 'summit' of their superiority has already
passed and the balance will inevitably kip towards the
other side in the near future. (It may in fact be
interesting for anyone doing a library search to see
what crypto literatures were available three decades
ago.) Of course, they will continue to have the advantage
that all public literatures are available to them but
their results are unknown to the public. But the
significance of that leverage declines, when greatly more
research results are achieved by scientists in the public.
M. K. Shen
------------------------------
From: "Nils Johansson" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 21:59:51 +0200
Reply-To: "Nils Johansson" <[EMAIL PROTECTED]>
cant deffie-hellman be used to distribute the key
I need something more secure, because anyone might be listening, and catch
the key. I dont want to involve a third part either...
-tore
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 19:58:43 GMT
"Nils Johansson" <[EMAIL PROTECTED]> wrote in message
news:9dpdb8$j0gbf$[EMAIL PROTECTED]...
> cant deffie-hellman be used to distribute the key
>
> I need something more secure, because anyone might be listening, and catch
> the key. I dont want to involve a third part either...
Well typically (i.e. in theory) DH is very secure. It's completely
vulnerable to mitm attacks though...
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Revised copy of Noekeon analysis paper
Date: Mon, 14 May 2001 19:59:42 GMT
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:KaWL6.93043$[EMAIL PROTECTED]...
> I've updated the draft to correct a few technical typos and correct the
> spelling of the authors... (oops sorry).
>
> BTW I would like comments (either to the group or via email). feel free
to
> critique the paper, etc.
Please comment on the attack/paper. It's the only way to learn for me (via
feedback). Not to be mean but I know you guys are reading it... ahem....
cough cough...
cr30235-a.flfrd1.on.wave.home.com - - [13/May/2001:20:23:35 -0400] "GET
/na.ps.gz HTTP/1.1" 200 32785
mozart.CS.Berkeley.EDU - - [13/May/2001:21:05:21 -0400] "GET /na.ps.gz
HTTP/1.0" 200 32785
gatekeeper19.Sony.CO.JP - - [13/May/2001:21:30:07 -0400] "GET /na.pdf
HTTP/1.0" 200 85294
216.104.228.157 - - [13/May/2001:21:31:34 -0400] "GET /na.pdf HTTP/1.0" 200
85294
216.104.228.157 - - [13/May/2001:21:31:37 -0400] "GET /na.pdf HTTP/1.0"
304 -
216.104.228.157 - - [13/May/2001:21:31:38 -0400] "GET /na.pdf HTTP/1.0"
304 -
roam121-31.student.harvard.edu - - [13/May/2001:21:55:54 -0400] "GET /na.pdf
HTTP/1.1" 200 85294
roam121-31.student.harvard.edu - - [13/May/2001:21:56:40 -0400] "GET /na.pdf
HTTP/1.1" 304 -
roam121-31.student.harvard.edu - - [13/May/2001:21:57:20 -0400] "GET /na.pdf
HTTP/1.1" 304 -
roam121-31.student.harvard.edu - - [13/May/2001:21:58:20 -0400] "GET
/na.ps.gz HTTP/1.1" 200 32786
cpu2495.adsl.bellglobal.com - - [13/May/2001:22:09:50 -0400] "GET /na.pdf
HTTP/1.1" 200 85294
adsl-64-171-3-61.dsl.sntc01.pacbell.net - - [13/May/2001:22:46:57 -0400]
"GET /na.pdf HTTP/1.0" 200 85294
dhcp081231.res-hall.nwu.edu - - [13/May/2001:22:51:34 -0400] "GET /na.ps.gz
HTTP/1.1" 200 32786
dhcp081231.res-hall.nwu.edu - - [13/May/2001:22:51:40 -0400] "GET /na.pdf
HTTP/1.1" 200 85294
d151.as2.oshk0.wi.voyager.net - - [13/May/2001:22:55:08 -0400] "GET /na.pdf
HTTP/1.1" 200 85294
C8BC0D22.dial.mg.psinet.com.br - - [13/May/2001:23:01:58 -0400] "GET /na.pdf
HTTP/1.1" 200 85294
C8BC0D22.dial.mg.psinet.com.br - - [13/May/2001:23:06:11 -0400] "GET /na.pdf
HTTP/1.1" 304 -
silver.rdh.ecl.ntt.co.jp - - [14/May/2001:00:31:36 -0400] "GET /na.ps
HTTP/1.0" 404 -
k5.fujitsu.co.jp - - [14/May/2001:00:31:52 -0400] "GET /na.pdf HTTP/1.0" 200
85294
ps.melco.co.jp - - [14/May/2001:00:32:01 -0400] "GET /na.{ps.gz,pdf
HTTP/1.0" 404 -
silver.rdh.ecl.ntt.co.jp - - [14/May/2001:00:32:25 -0400] "GET
/na.{ps.gz,pdf} HTTP/1.0" 404 -
cache-tok-aa01.proxy.aol.com - - [14/May/2001:00:32:33 -0400] "GET /na.pdf
HTTP/1.0" 200 85294
silver.rdh.ecl.ntt.co.jp - - [14/May/2001:00:33:47 -0400] "GET /na.pdf
HTTP/1.0" 200 85294
207.55.193.194 - - [14/May/2001:00:37:49 -0400] "GET /na.ps.gz HTTP/1.1" 200
32786
207.55.193.194 - - [14/May/2001:00:38:19 -0400] "GET /na.pdf HTTP/1.1" 200
85294
207.55.193.194 - - [14/May/2001:00:39:02 -0400] "GET /na.pdf HTTP/1.1" 304 -
dhcp081231.res-hall.nwu.edu - - [14/May/2001:01:34:13 -0400] "GET /na.pdf
HTTP/1.1" 304 -
inet-proxy14.toshiba.co.jp - - [14/May/2001:01:40:25 -0400] "GET /na.pdf
HTTP/1.0" 200 85294
203.202.88.90 - - [14/May/2001:01:47:19 -0400] "GET /na.pdf HTTP/1.1" 200
85294
inet-proxy14.toshiba.co.jp - - [14/May/2001:01:50:53 -0400] "GET /na.pdf
HTTP/1.0" 304 -
lasecpc10.epfl.ch - - [14/May/2001:02:24:11 -0400] "HEAD /na.ps.gz HTTP/1.1"
200 32786
lasecpc10.epfl.ch - - [14/May/2001:02:24:15 -0400] "GET /na.ps.gz HTTP/1.1"
200 32786
WWWCache.Space.Net - - [14/May/2001:02:38:15 -0400] "GET /na.ps.gz HTTP/1.0"
200 32786
WWWCache.Space.Net - - [14/May/2001:02:43:06 -0400] "GET /na.pdf HTTP/1.0"
200 85294
miraculix.pixel.de - - [14/May/2001:02:43:12 -0400] "GET /na.pdf HTTP/1.0"
200 85294
async50-mel-isp-15.nas.one.net.au - - [14/May/2001:02:54:50 -0400] "GET
/na.pdf HTTP/1.1" 200 85294
yellow.DresdnerBank.de - - [14/May/2001:03:02:13 -0400] "GET /na.pdf
HTTP/1.0" 200 85294
px1.hitachi.co.jp - - [14/May/2001:04:08:58 -0400] "GET /na.{ps.gz,pdf
HTTP/1.0" 404 -
px1.hitachi.co.jp - - [14/May/2001:04:09:42 -0400] "GET /na.ps.gz HTTP/1.0"
200 32786
pc-62-31-73-177-ed.blueyonder.co.uk - - [14/May/2001:04:15:20 -0400] "GET
/na.ps.gz HTTP/1.0" 200 32786
karon.dynas.se - - [14/May/2001:04:32:22 -0400] "GET /na.pdf HTTP/1.0" 200
85294
pc1-stev2-0-cust77.lut.cable.ntl.com - - [14/May/2001:04:36:35 -0400] "GET
/na.pdf HTTP/1.1" 200 85294
munin.diku.dk - - [14/May/2001:04:41:56 -0400] "GET /na.ps.gz HTTP/1.0" 200
32786
wit389103.student.utwente.nl - - [14/May/2001:05:21:37 -0400] "GET /na.pdf
HTTP/1.1" 200 85294
wit389103.student.utwente.nl - - [14/May/2001:05:21:40 -0400] "GET /na.pdf
HTTP/1.1" 200 85294
plato.sse.ie - - [14/May/2001:06:23:04 -0400] "GET /na.pdf HTTP/1.0" 200
85294
h00104b632f97.ne.mediaone.net - - [14/May/2001:08:02:48 -0400] "GET /na.pdf
HTTP/1.0" 200 85294
205.211.55.93 - - [14/May/2001:08:22:44 -0400] "GET /na.pdf HTTP/1.1" 200
85294
pD9570A9E.dip.t-dialin.net - - [14/May/2001:08:58:11 -0400] "GET /na.ps.gz
HTTP/1.1" 200 32786
socks1.watson.ibm.com - - [14/May/2001:10:12:35 -0400] "GET /na.ps.gz
HTTP/1.0" 200 32786
old-dialup3-114.dartmouth.edu - - [14/May/2001:10:38:13 -0400] "GET /na.pdf
HTTP/1.0" 200 85294
tunnel-44-55.vpn.uib.no - - [14/May/2001:10:47:23 -0400] "GET /na.ps.gz
HTTP/1.0" 200 32786
adsl-216-103-104-53.dsl.snfc21.pacbell.net - - [14/May/2001:12:09:39 -0400]
"GET /na.pdf HTTP/1.0" 200 85294
216.103.104.53 - - [14/May/2001:12:09:45 -0400] "GET /na.pdf HTTP/1.0" 200
85294
h33-242.state.id.us - - [14/May/2001:12:37:51 -0400] "GET /na.ps.gz
HTTP/1.1" 200 32786
dhcp200.nttmcl.com - - [14/May/2001:13:21:46 -0400] "GET /na.pdf HTTP/1.0"
200 85294
host213-122-157-207.btinternet.com - - [14/May/2001:15:17:48 -0400] "GET
/na.pdf HTTP/1.1" 200 85709
host213-122-157-207.btinternet.com - - [14/May/2001:15:19:46 -0400] "GET
/na.pdf HTTP/1.1" 200 85741
host213-122-157-207.btinternet.com - - [14/May/2001:15:22:21 -0400] "GET
/na.pdf HTTP/1.1" 200 85736
dyn-207-111-241-12.sjc.got.net - - [14/May/2001:15:34:01 -0400] "GET /na.pdf
HTTP/1.1" 200 85736
dyn-207-111-241-12.sjc.got.net - - [14/May/2001:15:34:51 -0400] "GET /na.pdf
HTTP/1.1" 304 -
wit389103.student.utwente.nl - - [14/May/2001:15:37:19 -0400] "GET /na.pdf
HTTP/1.1" 200 85736
wit389103.student.utwente.nl - - [14/May/2001:15:37:23 -0400] "GET /na.pdf
HTTP/1.1" 200 85736
24-216-71-240.hsacorp.net - - [14/May/2001:15:54:51 -0400] "GET /na.pdf
HTTP/1.0" 200 85736
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 22:10:38 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:TNWL6.93560$[EMAIL PROTECTED]...
>
> "Nils Johansson" <[EMAIL PROTECTED]> wrote in message
> news:9dpdb8$j0gbf$[EMAIL PROTECTED]...
> > cant deffie-hellman be used to distribute the key
> >
> > I need something more secure, because anyone might be listening, and
catch
> > the key. I dont want to involve a third part either...
>
> Well typically (i.e. in theory) DH is very secure.
Is it? I would prefer your first proposal anytime over any asymmetric key
exchange. The only practical problem is how to distribute and store the
first key.
> It's completely
> vulnerable to mitm attacks though...
Yes, and that alone makes it insecure.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 20:14:28 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9dpe5d$lei$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:TNWL6.93560$[EMAIL PROTECTED]...
> >
> > "Nils Johansson" <[EMAIL PROTECTED]> wrote in message
> > news:9dpdb8$j0gbf$[EMAIL PROTECTED]...
> > > cant deffie-hellman be used to distribute the key
> > >
> > > I need something more secure, because anyone might be listening, and
> catch
> > > the key. I dont want to involve a third part either...
> >
> > Well typically (i.e. in theory) DH is very secure.
>
> Is it? I would prefer your first proposal anytime over any asymmetric key
> exchange. The only practical problem is how to distribute and store the
> first key.
There is no solution to that problem.
> > It's completely
> > vulnerable to mitm attacks though...
>
> Yes, and that alone makes it insecure.
Not always. You can try to work around mitm via some forms of EKE (or
physical exchange)... but I find EKE defeats the purpose of PK algorithms...
Tom
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 22:26:19 +0200
"Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
news:E0XL6.93646$[EMAIL PROTECTED]...
>
> "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> news:9dpe5d$lei$[EMAIL PROTECTED]...
> > "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> > news:TNWL6.93560$[EMAIL PROTECTED]...
> > >
> > > "Nils Johansson" <[EMAIL PROTECTED]> wrote in message
> > > news:9dpdb8$j0gbf$[EMAIL PROTECTED]...
> > > > cant deffie-hellman be used to distribute the key
> > > >
> > > > I need something more secure, because anyone might be listening, and
> > catch
> > > > the key. I dont want to involve a third part either...
> > >
> > > Well typically (i.e. in theory) DH is very secure.
> >
> > Is it? I would prefer your first proposal anytime over any asymmetric
key
> > exchange. The only practical problem is how to distribute and store the
> > first key.
>
> There is no solution to that problem.
There is a trivial solution. Take the train, meet Steve and give him your
key.
> > > It's completely
> > > vulnerable to mitm attacks though...
> >
> > Yes, and that alone makes it insecure.
>
> Not always. You can try to work around mitm via some forms of EKE (or
> physical exchange)... but I find EKE defeats the purpose of PK
algorithms...
You would still need a secure initial transfer of long term keys, or your
system would be vulnerable to MITM attacks.
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com>
------------------------------
From: "Nils Johansson" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 22:28:19 +0200
Reply-To: "Nils Johansson" <[EMAIL PROTECTED]>
I will use this system, which by the way is my homework in datacomms,
during the TCPIP 3-step handshake, the public keys are exchanged
HOST B sends his pub key to HOST A, who responds with a key that is
encrypted with this key.
Now HOST B can decrypt the key and they can communicate using this key.
Problem is ofcourse authorization, anyone could hijack the connection, and
iniate a transfer... but im afraid there is no solution to this.
- tore
------------------------------
From: [EMAIL PROTECTED] (Gregory G Rose)
Subject: Re: extracting random bits from low-entropy data
Date: 14 May 2001 13:29:20 -0700
In article <[EMAIL PROTECTED]>,
Mark <[EMAIL PROTECTED]> wrote:
>How do I extract the entropy from low-entropy data to produce high-quality
>random bits, assuming that I know a lower bound for the amount of entropy
>in the input?
>
>For example, suppose I want 100 uniform random bits, and my source of
>randomness is the conversation in a chat room. Making the assumption that
Other postings in this thread have given the
correct answer, which is "use a standard hash
function". However...
What do you want to use this entropy for? ("What's
the threat model?") You're attempting to derive
entropy from essentially public information.
Suppose, for example, that you want to use that to
seed a pseudo-random number generator for a game, and
it's important that the players not be able to
know the output of the PRNG. Further suppose that
the chat room is about the game, and that the
players can be expected to see the conversation.
Then the entropy to the other players is in fact
much less than the expected hundred bits... they
just have to take 50-line chunks from the log of
the chat room, hash them, and see if the PRNG
produces output consistent with that hash as the
input. The measure of entropy, in this case, applies
to one of a couple of hundred starting points for the
50-line hash, that is, less than 8 bits.
It's impossible to tell from your question whether
this distinction matters to you or not, but in
practice it certainly can matter... during the
Prohibition Era in the US, a number of book
ciphers were broken by (I think) Elizabeth
Friedman based purely on knowing what books were
likely to be used. The entropy of the text was
high in total, but the entropy of the *selection*
of the text was low.
Greg.
--
Greg Rose INTERNET: [EMAIL PROTECTED]
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: good x86 coders (help please)
Date: 14 May 2001 13:32:52 -0700
"Tom St Denis" <[EMAIL PROTECTED]> writes:
> The problem is that if I optimize the code specially for the Athlon (which
> is what I am running) I lose out on all other platforms etc..
Yes, if you're really going all out, your code has to figure out which
specific processor it's running on (that in itself is not always simple)
and choose a code sequence tweaked for that processor.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: Revised copy of Noekeon analysis paper
Date: Mon, 14 May 2001 21:32:01 +0100
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:OOWL6.93567$[EMAIL PROTECTED]...
>
> pc1-stev2-0-cust77.lut.cable.ntl.com - - [14/May/2001:04:36:35 -0400] "GET
> /na.pdf HTTP/1.1" 200 85294
I guess you were after comments from the gods (Wagner, Wooding, Fluhrer,
Crowley et al), but I'll put my hand up anyway and say that I was very
impressed by the paper. This paper along with "SAC'01 wannabe paper" are
very good - they are written to a high standard and comprehensive in
coverage.
I don't have the ability to technically appraise your work (I can just about
keep up 85% of the time :( ), but if you want encouragement then I can only
say that I'm sure your papers are read and enjoyed by many.
It will be interesting to watch your experience submitting a first paper to
peer review journal - following Paul Crowley's Mercy getting to FSE2000 was
fascinating (http://www.cluefactory.org.uk/paul/mercy/)
--
Regards,
Sam
http://www.scramdisk.clara.net/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Revised copy of Noekeon analysis paper
Date: Mon, 14 May 2001 20:48:46 GMT
"Sam Simpson" <[EMAIL PROTECTED]> wrote in message
news:giXL6.6029$[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:OOWL6.93567$[EMAIL PROTECTED]...
> >
> > pc1-stev2-0-cust77.lut.cable.ntl.com - - [14/May/2001:04:36:35 -0400]
"GET
> > /na.pdf HTTP/1.1" 200 85294
>
> I guess you were after comments from the gods (Wagner, Wooding, Fluhrer,
> Crowley et al), but I'll put my hand up anyway and say that I was very
> impressed by the paper. This paper along with "SAC'01 wannabe paper" are
> very good - they are written to a high standard and comprehensive in
> coverage.
Thanks for the kind words. They are fun to write and of course learn from.
The attack in my wannabe paper is due to an idea by Fluhrer (who is the
keenest (yes keen is an adjective in my vocab) cryptographer I know) and I
learned how to mount truncated differentials.
Even aesthetic or English related comments are welcomed. I tend to make
alot of spelling errors which is annoying...
> I don't have the ability to technically appraise your work (I can just
about
> keep up 85% of the time :( ), but if you want encouragement then I can
only
> say that I'm sure your papers are read and enjoyed by many.
I hope so too.
> It will be interesting to watch your experience submitting a first paper
to
> peer review journal - following Paul Crowley's Mercy getting to FSE2000
was
> fascinating (http://www.cluefactory.org.uk/paul/mercy/)
Hmm well I doubt the quality of my papers is sufficient for a conference....
but I hope to get some experience by writting these papers...
btw on my website I have dedicated a page to my papers as I write them
http://tomstdenis.home.dhs.org
Thanks again,
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: good x86 coders (help please)
Date: Mon, 14 May 2001 20:49:21 GMT
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> writes:
> > The problem is that if I optimize the code specially for the Athlon
(which
> > is what I am running) I lose out on all other platforms etc..
>
> Yes, if you're really going all out, your code has to figure out which
> specific processor it's running on (that in itself is not always simple)
> and choose a code sequence tweaked for that processor.
Yup my current x86 assembler code runs at 300 cycles per block. I shaved 65
cycles off of what GCC makes
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: best algo
Date: Mon, 14 May 2001 20:49:58 GMT
"Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
news:9dpf0b$mi3$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> news:E0XL6.93646$[EMAIL PROTECTED]...
> >
> > "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> > news:9dpe5d$lei$[EMAIL PROTECTED]...
> > > "Tom St Denis" <[EMAIL PROTECTED]> skrev i meddelandet
> > > news:TNWL6.93560$[EMAIL PROTECTED]...
> > > >
> > > > "Nils Johansson" <[EMAIL PROTECTED]> wrote in message
> > > > news:9dpdb8$j0gbf$[EMAIL PROTECTED]...
> > > > > cant deffie-hellman be used to distribute the key
> > > > >
> > > > > I need something more secure, because anyone might be listening,
and
> > > catch
> > > > > the key. I dont want to involve a third part either...
> > > >
> > > > Well typically (i.e. in theory) DH is very secure.
> > >
> > > Is it? I would prefer your first proposal anytime over any asymmetric
> key
> > > exchange. The only practical problem is how to distribute and store
the
> > > first key.
> >
> > There is no solution to that problem.
>
> There is a trivial solution. Take the train, meet Steve and give him your
> key.
How do you know you met Steve and not an impostor.
Believe me, there is NO solution to the "name = person" problem.
> > > > It's completely
> > > > vulnerable to mitm attacks though...
> > >
> > > Yes, and that alone makes it insecure.
> >
> > Not always. You can try to work around mitm via some forms of EKE (or
> > physical exchange)... but I find EKE defeats the purpose of PK
> algorithms...
>
> You would still need a secure initial transfer of long term keys, or your
> system would be vulnerable to MITM attacks.
True.
Tom
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
