Protecting encryption server

[Robert J. Hansen]

> So, as described in Rob's paper, the sending server has to
> continuously send the data over and over again, with no idea whether
> the receiving server has received any of it, parts of it, or the
> whole of it.

Correct.

Our research was done as part of an electronic voting security group at
the University of Iowa.  The particular use case we had was, "how do you
communicate realtime election results to a public webserver in a way
that even if attackers compromise the webserver they cannot access the
tallying system?"

And for that, the tickertape model works pretty well.  We had a proof of
concept running in Python at a very low baud rate: it was transmitting
at a speed slightly slower than an old Telex teleprinter.  This had the
additional side effect of making it easier to audit (you could
physically see the LED flip on and off), easier to sync, and more
resistant to transmission errors.

For election results, Telex speeds are just fine.  If you need more
bandwidth than that, the next best bet is to just burn a DVD and
hand-deliver that.

> I am not saying that any of those problems is unsolvable, but it
> seems to me that devising robust solutions to all of them (and to all
> of the others that will come up along the way) will make the system
> much, much, *much* more complicated than "just a single one-way comm
> device".

... which, not to put too fine a point on it, is where the potential to
exploit the system comes from.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 821 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200729/c70f3380/attachment.sig>