
GnuPG 1.4.15 released - austengary
http://lists.gnupg.org/pipermail/gnupg-announce/2013q4/000334.html
======
lelf
And GnuPG 2.0.22 — [http://lists.gnupg.org/pipermail/gnupg-
announce/2013q4/00033...](http://lists.gnupg.org/pipermail/gnupg-
announce/2013q4/000333.html)

~~~
InTheSwiss
I know GnuPG-2 is preferred over GnuPG-1 now but I only see 1.x binaries
available for Windows. Do they provide official 2.x binaries as well?

~~~
lstamour
Under binaries, they link to GPG4Win. Other Windows front-ends:
[http://www.gnupg.org/related_software/frontends.html#win](http://www.gnupg.org/related_software/frontends.html#win)

I suspect GnuPG only officially distributes source code now, which is slightly
safer to use for obvious reasons. :)

~~~
InTheSwiss
Yeah I saw it was provided in GPG4Win but I was hoping they provided a
barebones installer for 2.x like they do for 1.x guess they don't. I might
drop Werner a note and ask.

------
deckar01
The recursive decompression reminds me of the zip quine.

www.steike.com/code/useless/zip-file-quine/

------
bcl
Fedora 1.4.15 updates built. They could use some testing and karma:

* [https://admin.fedoraproject.org/updates/gnupg-1.4.15-1.fc18](https://admin.fedoraproject.org/updates/gnupg-1.4.15-1.fc18) * [https://admin.fedoraproject.org/updates/gnupg-1.4.15-1.fc19](https://admin.fedoraproject.org/updates/gnupg-1.4.15-1.fc19) * [https://admin.fedoraproject.org/updates/gnupg-1.4.15-1.fc20](https://admin.fedoraproject.org/updates/gnupg-1.4.15-1.fc20)

------
chimeracoder
Anybody have any idea on when we'll be able to use elliptic curve encryption
with GPG?

According to tptacek, that's in the works, but seems like that didn't make it
into this release.

~~~
antocv
I wonder when we will be able to use some GOST ciphers with it, just for fun
and diversification from NIST ciphers.

Does anyone know what the Chinese equivalent of NIST is? What does China use?

~~~
JoachimS
In terms om symmetric ciphers we know of two chinese ones: sms4 and zuc. The
latter has also been accepted as standard by 3GPP (SAGE).

[https://en.wikipedia.org/wiki/SMS4](https://en.wikipedia.org/wiki/SMS4)

[https://en.wikipedia.org/wiki/Zuc_stream_cipher](https://en.wikipedia.org/wiki/Zuc_stream_cipher)

Not sure why anybody would want to use them or the GOST standards unless
required/forced to do so.

~~~
Steuard
I think the idea is to encrypt with multiple cyphers, each endorsed by a
different government (preferably mutually mistrustful governments). That way,
in principle, the Chinese may have a backdoor to one layer and the US to
another, but they'd need to work together to break your whole message.

I have no idea how useful this would be in practice.

~~~
betterunix
I suspect that the NSA would be aware of weaknesses in Chinese ciphers as much
as in American ciphers, so I doubt that this would help much...

~~~
tedks
It avoids backdoors. Assume that the Chinese government has backdoored its
ciphers, and the American government has backdoored its ciphers, and the two
governments don't want to cooperate.

If you cascade the two ciphers, the American government needs to find a real
weakness in the Chinese cipher, and the Chinese government needs to find a
real weakness in the American cipher. Which they might have, but they at least
can't use backdoors at this point.

~~~
chimeracoder
> If you cascade the two ciphers,

That assumes that f(g(x)) is harder to invert than either f(x) or g(x)
individually, which is _not_ true in the general case for encryption schemes.

It is quite possible that (f∘g) can be cracked in a way that neither f or g
can individually.

~~~
tedks
I've heard this before, and have no background in crypto so I can't dispute
it, but I'm unsure as to how this makes sense. Certainly if I encrypt
something with AES, and then encrypt it with Twofish, using different keys
each time, how is this different from encrypting any other arbitrary data with
either of those ciphers?

~~~
betterunix
It is worth pointing out that composing two block ciphers like this only adds
_one_ bit of security, due to the meet-in-the-middle attack (assuming that the
composition is otherwise secure, etc.).

~~~
Tomte
_If_ one of those ciphers is completely broken, so that can be decrypted as
easily as ROT13, correct?

~~~
betterunix
No, not correct. Suppose I know the message that was encrypted (i.e. a known
plaintext attack). Then what I can do is to build a table of the decryption of
the ciphertext under all possible keys (i.e. a brute-force attack on _one_
cipher), then encrypt the known plaintext under all possible keys with the
other cipher (a second brute-force attack) and see where I get "hits" in the
table. Those hits are candidate keys for the composed cipher; if the ciphers
are secure then there will be a small number of hits. The total running time
is simply the sum of the time required to attack the component ciphers, which
only adds one bit of security.

~~~
tedks
So, it seems like you're saying that if you can brute-force two ciphers, you
can brute-force the composition of ciphers.

It's still twice as hard, correct? And if you have two ciphers, one of which
is compromised in some way, wouldn't this composition mean that you're at
least as secure as the most secure of the two ciphers?

Also, how does 3DES get away with this? I read on wikipedia (after I looked up
the meet in the middle attack) that 3DES encrypts, then decrypts with a second
key, then encrypts, and presumably decrypts-encrypts-decrypts on 3DES-
decryption -- how is this different?

(Thanks for answering these questions; it's contributed to my knowledge of
crypto and I really appreciate it.)

~~~
betterunix
"So, it seems like you're saying that if you can brute-force two ciphers, you
can brute-force the composition of ciphers. It's still twice as hard,
correct?"

Exactly, and "twice as hard" is another way to say "one extra bit of
security."

"It's still twice as hard, correct? And if you have two ciphers, one of which
is compromised in some way, wouldn't this composition mean that you're at
least as secure as the most secure of the two ciphers?"

It took me some time to locate this, but it is relevant:

[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36....](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.36.5309&rep=rep1&type=pdf)

You can think of it this way: the meet-in-the-middle attack is _generic_ and
does not exploit the structure of the ciphers at all, whereas attacks that do
exploit the structure of the ciphers might exist and might do better when the
ciphers are composed. In general you should avoid carelessly composing
cryptosystems (for that matter, you should avoid carelessly composing
cryptosystems with other systems; e.g. the Skype attack).

"Also, how does 3DES get away with this?"

The security of 3DES is _twice_ the security of single DES; the attack still
works, but it can only remove one of the DES applications. Note also that 3DES
is DES composed with itself, and so attacks on the structure of the components
would imply weaknesses in DES itself.

