[Tfug] A sense of time

[jblais]

> -----Original Message-----
> From: tfug-bounces at tfug.org [mailto:tfug-bounces at tfug.org]On Behalf Of
> Jim March
> Sent: Thursday, August 02, 2007 5:22 PM
> To: Tucson Free Unix Group
> Subject: Re: [Tfug] A sense of time
>
>
> We run into this problem in voting systems.
>
> In that application, with any luck you've got a lot of "eyeballs" on
> the process - party observers, precinct workers (ordinary citizens)
> and others so if you make the time/date on the system REALLY visible
> at all times, and at minimum tricky to change, you should be good.
>
> Except when just after the election and nobody but the central
> election officials have access.
>
> SIGH.
>
> This is most definitely something in need of a fix.
>
> Jim
>

Now that you mention it...

I'm doing a thing for a synthesizer, that requires that "messing with the
data" can't happen (FDA and CFR stuff).  The usual way is to put log stuff
into encrypted files and such.  I'm starting to use another way, probably
already in use, but to me it seems new.

Anyway, the log files are completely open and easy to read, no write
protection, nothing encrypted simple ASCII.  Each line, in my case starts
with a floating checksum. I use about 4 bytes worth and display the value in
hex code, followed by the information being logged:

1f33a101 June 1, 2008: Keypress: Login
ef23a722 June ... whatever...

and so on.  I just add each subsequent character to the next byte (don't
allow one byte's overflow to affect the next checksum)  The algorithm must
be public.  The file must be public.  Each subsequent file starts off with
the last file's checksums.

I don't think that there is any way that you can't detect a change, that's
really what I'm after.  Not so much to prevent - I can't - just detect.  If
you delete a line, the checksum for all the following lines will never add
up.  If you swap the order of 2 lines, even though the information contained
doesn't change, the checksums probably will no longer add up.

For a voting machine, the checksum and log line, and file information could
be visible to the voter, every time they hit a key.  They could write down
the pertinent info at the start and end of their voting session for their
own reference.  Voting judges could go to a machine at any time and press a
few screen changes, or some recorded no-op keys, and keep the log
information for themselvers. All vote files would be published immediately
on the WWW wen the doors close.  The algorithm to calc the checksum, and to
interpert the keypresses (tally up the votes) would likewise be published.
Just no names. Anyone could then inspect the log files, see where their vote
is logged, and follow through the tally to see that their vote really was
counted.  The problem is with, if someone knows you voted on machine A at
12:25, they could figure out how you voted (and fire you for being a
center-winged coward, or pay you for a vote well planned). -- perhaps don't
log the time, just log judges tracking entries when doors open and close.
No key on the voting device could function without a log entry.

joe