On 2014-04-07 00:05, Daniel Kahn Gillmor wrote:
> It sounds to me like you might be setting up some sort of automated
> encrypted JSON message-passing scheme. If so, you should be aware
> that if any of the encrypted JSON could be controlled by an
> attacker, that attacker could possibly learn inf
On 04/02/2014 01:07 PM, Tim Chase wrote:
> 1) I'd missed that GPG conveniently compresses the data before
> encrypting which would explain some of the differences I saw.
[...]
> in more than half of my use cases (small plain-text/JSON messages)
It sounds to me like you might be setting up some
On 2014-04-02 00:37, David Shaw wrote:
> This can change pretty significantly given different key lengths,
> different algorithms, and perhaps most significantly, how
> compressible the original document is (by default GPG compresses
> data before encryption). An input file of text will compress v
On Apr 1, 2014, at 9:01 PM, Tim Chase wrote:
> I've been trying to find a good explanation on how something like
>
> gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt
>
> works. The best I've been able to find is this:
>
> http://lists.gnupg.org/pipermail/gnupg-users/2007-Oc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On April 1, 2014 9:01:28 PM EDT, Tim Chase wrote:
>I've been trying to find a good explanation on how something like
>
> gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt
>
>works. The best I've been able to find is this:
>
>htt
I've been trying to find a good explanation on how something like
gpg -r DEADBEEF -r CAFEBABE -r 8BADFOOD -o output.gpg -e input.txt
works. The best I've been able to find is this:
http://lists.gnupg.org/pipermail/gnupg-users/2007-October/031938.html
I'm mostly interested in the overhead, so
