Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] One time pad Management system?

Karl Fogel kfogel at red-bean.com
Thu Jul 11 22:00:15 PDT 2013


Paul Elliott <pelliott at blackpatchpanel.com> writes:
>Are there any practical one time pad management systems out there,
>GPLed for GNU/Linux?
>
>Is anyone working on one?
>
>If not, does anyone want to start?
>
>Thank You for considering this question.

  http://red-bean.com/onetime

I'm actively working on v2 and hope to have it released pretty soon (the
changes are not difficult, it's just writing the regression tests,
maintaining format compatibility, and stuff like that that takes time).

You can see the v2 changes on this branch:

  http://viewvc.red-bean.com/onetime/branches/2.x/

(Am moving it to GitHub or Gitorious soon, but it started out in
Subversion and that's where the source can be browsed right now.)

The main changes coming out in v2 are:

  - A fix for an embarrassing bug (one with no security implications as
    far as I'm aware, but that causes the output to be larger than
    necessary.  Yes, I somehow wrote the encryption and compression
    calls in the wrong order years ago, don't ask me how :-) ).

  - A change to stop a tiny theoretical information leak (OneTime uses
    Pad IDs to keep track of which stretches of which pads have been
    used before; the Pad IDs in theory leaked a tiny bit of information
    about the pad.  Which is silly -- there's no need to have even a
    theoretical leak, since one can just ensure that the stretch of pad
    used for ID purposes is never used for encoding, and that's what I
    should have done in the first place).

  - A few improvements in option handling and other UI stuff.

Now, one might reasonably ask: why would anyone want to use a one-time
pad system in practice?

I use it for a few different kinds of rare situations.  One, if I'm not
reasonably confident about the provenance of GnuPG on a system, but I am
confident about the provenance of its Python interpreter.  Two, to
bootstrap trust: e.g., if my GnuPG public key has changed, those who
share a pad with me can get the new one via a method that is not
dependent on any old public keys.  Three, to throw a little diversity
into the surveillance stream: watchers no doubt have bots looking for &
saving messages in PGP and various other popular encryption formats.
OneTime makes 'em work a little harder! :-)

-K


More information about the liberationtech mailing list