> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users