rconover,
I've actually sat in a room where it's hotter than 100
degrees Celsius. Several times. Am not dead yet. And it's
a fun experience, as long as you don't spend too much time
there.

Things I hate: ANSI C. Why is it that even Europeans must
grovel on the feet of an American standardization
organization? We have an international
organization, ISO, you know. And ISO C (1990) is for all
practical
purposes equivalent to ANSI C (1989).

Thinks I like: ISO standard date format. Now is
2000-07-30T19:15Z. You all got that?

I've been employed as a research assistant by the
Department of Mathematical Information Technology, in the
Jyväskylä Hyperstructure Group led by Tuomas Lukka.
I'm
supposed to work on GZigZag,
the Writer's Text Editor (as a GZigZag applitude) and
PolyGlot (a modular parser framework), although mostly it's
been about the first.

I'll be teaching a 30-hour course on 2000-08-01/10 about
functional and logic programming for upper secondary school
students as part of the Summer Secondardy School here at
Jyväskylä. I'm preparing frantically.

What have I been doing the last several weeks, hiding behind
an ignored journal? Mostly studying and teaching; they have
taken
most of my time. And I've been reading... It has not been a
fertile
ground for any hacking activities. Let's hope it'll change
for the better.

I discovered the GPF and Waiting for Bob
comic strips. And I purchased both User Friendly
books. I have little
difficulty
to identify with UF's AJ (who - interestingly - shares a
nickname with me) and GPF's Nick. Unfortunately they both
have
an advantage over me: they do not weigh as much :-(

Got a visit from an angry amanuensis (is that the correct
English term?)
that we should leave the office we had been given ASAP (it
was on loan from another department, and they needed the
room for a foreign visitor). With some interdepartmentary
diplomacy I was able to get us a new office, which is bigger
and spacier than the previous one and is directly attached
to the computer lab where we teach. I think it went quite
well in the final analysis. The problem is, our new office
space was reserved by a professor who has not used it in the
last year, and we were given that space without asking the
professor. Oh well, we need that office only for a month or
so anyway. And I got my own work computer, on which I
immediately
installed Debian potato (as of first test cycle). The
install system has
really improved.

No time to code today, I am sorry to report. But yesterday
I finally settled on two random number sources for Winters:
/dev/random for the
top-security stuff (keys etc)
and a /dev/random-seeded MD5-based PRNG for the workhorse
random numbers. And it works too, although I may have to
rewrite the MD5 implementation (stolen from dpkg) for
increased portability.

Today started both summer courses: the programming course
(where I work as a teaching assistant) and the topology
course (where i sit and study). The next one and half
months is going to be busy time for me.

Made an offline copy of the potato i386 archive for my
father, and installed a basic potato system for him. This
took all my free time today,
so I did not have any time to code or spec.

I've been specing and implementing Winters network
protocol. It's going slowly. I managed to write my own
Blowfish implementation which seems to be correct (passes a
simple encryption/decryption test where I know the correct
ciphertext). I noted, however, that the online
description of Blowfish is ambiguous in many occasions,
most notably it omits information on endianness issues on
many occasions. Apparently my guess "big-endian über alles"
was correct. My Blowfish implementation is not one of the
fastest, but it is the only one that I know that does not
require
separate source configuration (either manually or with
Autoconf) and is written in C.

Did you know that GCC means "Graphic Character
Combination"? I didn't, until I ran across the ECMA-48
standard.

I should've known. I presented the session management part
of the Winters protocol to a security newsgroup. It was
pretty much shot down.
They even asked why I was designing my own protocol instead
of using SSL or SSH or some other well-established
protocol. The answer is that
they don't take advantage of one unique aspect of the
application I'm designing the protocol for: all legitimate
sessions are necessarily derived from a root session. My
protocol thus can do without all long-term keys, symmetric
or asymmetric. Oh well, back to the drawing board (and I'm
getting a copy of Schneier).

I decided to rebuild my home system, which naturally runs
Debian, from scratch to do away with all its cruft. Of
course I forgot that I need the drivers diskette even in the
NFS install, and of course I noticed that after wiping out
my previous install. I had no access to the network
anymore. I had several past versions of Debian on CD's but
alas, my CD drive is broken. I even had some old boot disks
for Debian 1.3, Debian 0.93r6, and
Slackware 3.0. Unfortunately, none of them would build my
system into a shape where it could reach out to the net to
grab the stuff I needed. Ended up calling a nearby friend
and using his machine for creating that much needed drivers
diskette.

I've been drafting the Winters network protocol. I found
uses
to such
32-bit quantities as 4037931181 ("emergency hangup")
and 4026658817 ("permission denied") [thanks dhd!]. The
protocol is
simple
and expresses what it needs to express. I realized I can set
up a separate auth server to provide new sessions for
arbitrary clients if necessary, which simplifies the
problem. You see, the protocol creates new sessions by
negotiating their
cipher and encryption key on an existing session; this
avoids me having to deal with public-key cryptography in the
protocol itself.

Anybody see any obvious security problems with assuming that
if
the client can send a known plaintext (published as part of
the protocol specification) encrypted with the
correct key (which is prenegotiated using channels we assume
to be
secure) then the client can be considered authenticated?

The next step is to implement the protocol. This should not
take more than two days (famous last words!).