Re: The symmetric ciphers
On Wed, Oct 30, 2013 at 06:19:27PM +0100, Philipp Klaus Krause wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.09.2013 15:30, schrieb Robert J. Hansen: On 9/10/2013 6:35 AM, Philipp Klaus Krause wrote: I wonder if it would be a good idea to have an option to combine symmetric ciphers, e.g. users could state a preference list like this: No. This idea gets floated every few years and the answers never change. It's not a good idea. If you look in the list archives you can find some pretty long, detailed writeups on why. I just tried googling a bit, but the only posts I found are those that assume that the effort to break A+B would be a+b. I did not find the detailed writeups you mentoned, or even anything else about the assumption that breaking A+B takes at least effort max(a,b). I often worry about the assumption that there are no unfortunate interactions between the structures of A and B such that the effort to break A+B min(a,b). Consider a composition of *three* ciphers: A := ROT13 B := ROT10 C := ROT3 Each different from the others, though similar in operation. But (when the symbol set is the Roman alphabet) A(B(C(x))) = x. Composing these three ciphers produces a cipher worse than any of its components. Any order of composition will do the same. Compose any two of them and the result is no stronger than any single one. Obviously this should not be assumed to hold true for all possible functions, but it provides a counterexample: composing ciphers does not necessarily produce a stronger cipher. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
Having not read far enough down the thread, Mark H. Wood wishes to recall a completely redundant message: Consider a composition of *three* ciphers: A := ROT13 B := ROT10 C := ROT3 -- Mark H. Wood, hasty poster mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On Wed, Oct 30, 2013 at 11:33:18PM +0100, Philipp Klaus Krause wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there a known good way to combine multiple symmetric ciphers into something that is at least as strong as the weakest of them? I sincerely doubt that there is, in the general case. That's the point: you have to analyze each combination as if it were a new, untried cipher. It seems useless to ask whether one can benefit from composing multiple unspecified symmetric ciphers; much more useful to ask whether e.g. AES+BLOWFISH is at least as strong as, or stronger than, either AES or BLOWFISH alone. Then ask the same question for each composition you think promising. You will wind up doing quite a LOT of math. You could probably get a book out of it, if you do a thorough job. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 31-10-2013 4:52, Robert J. Hansen wrote:
That's because ROT(N) is a group.
Yes, but good luck answering the inevitable next two questions: what's
a group?
Playing Captain Obvious:
G is a group for the operation X if:
- \forall {A,B \in G} -- A X B \in G: G is closed.
- \forall {A,B,C\in G} -- (A X B) X C = A X (B X C): G obeys the
associative law.
- \exists {E\in G} so that \forall {A\in G} A X E = E X A = A: G has a
unit element.
- \forall {A\in G} \exists {A^{-1}\in G} so that A X A^{-1} = E: Each
element in G has an inverse.
If also holds:
\forall {A,B\in G} -- A X B = B X A the group is called Abelian or
commutative.
and how do we know if something's a group? You very quickly
run into some complicated higher-level maths, and that's something best
avoided.
I don't doubt that. I assumed (yes I know, assumption is the mother of
all fuckups) that these things were analyzed during the long
cryptanalysis the algorithms in gpg have had. From DES I know it is not
a group (otherwise 3DES would indeed not be more secure than single
DES), I admid that a quick Google about AES didn't turn up any
information one way or the other. Is that not determined yet? Did noone
researched something like 3AES yet?
There is no single answer to this. The other symmetric ciphers need
to be evaluated combinatorically: for instance, are AES128, 3DES and
Camellia a group? That answer may be different from AES192, 3DES and
Camellia.
However, encrypting a message with AES with key1 and then encrypting it
again with key2 (key1 unrelated to key2) can't make it less secure since
any attacker can encrypt the intercepted encrypted message again with
little effort. That would be like saying that base-64 encoding the
message would reduce security.
Of course there is one well-known encryption product that offers this
option: TrueCrypt allows one to stack encryption algorithms. But then,
the design decisions of TrueCrypt are not really known.
--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On Thursday, October 31, 2013 at 10:06 AM, Johan Wevers
joh...@vulcan.xs4all.nl wrote:
However, encrypting a message with AES with key1 and then
encrypting it again with key2 (key1 unrelated to key2) can't make it less
secure
since any attacker can encrypt the intercepted encrypted message again
with little effort. That would be like saying that base-64 encoding the
message would reduce security.
=
If the keys are different, and the algorithms different, then it would seem
that there is a major advantage to re-encrypting the ciphertext,
('cascading' is the term Truecrypt uses for this.)
The advantage is,
that if it should ever be possible to brute force the keyspace of one key, then
NONE of the possible elements of the keyspace (including the *correct* key)
will result in an identifiable *correct* plaintext. It will only result in
random ciphertext.
(This is different than ROT(10) followed by ROT(16), because it can be broken
by brute forcing ROT(x, ; 0x26), which will result in a correct plaintext.)
=
Of course there is one well-known encryption product that offers
this option: TrueCrypt allows one to stack encryption algorithms. But
then, the design decisions of TrueCrypt are not really known.
=
Truecrypt allows only AES, Twofish, and Serpent for encryption and cascading.
(Whether this is because there is a potential flaw in using other algorithms,
or whether it is simply too much work for the developers to provide cascading
for all algortihms, I do not know.)
Here is the description in the Truecrypt documentation:
http://www.truecrypt.org/docs/cascades#Y0
=[begin quote]=
AES-Twofish-Serpent
Three ciphers in a cascade [15, 16] operating in XTS mode (see the section
Modes of Operation). Each 128-bit block is first encrypted with Serpent
(256-bit key) in XTS mode, then with Twofish (256-bit key) in XTS mode, and
finally with AES (256-bit key) in XTS mode. Each of the cascaded ciphers uses
its own key. All encryption keys are mutually independent (note that header
keys are independent too, even though they are derived from a single password –
see the section Header Key Derivation, Salt, and Iteration Count). See above
for information on the individual cascaded ciphers.
Serpent-AES
Two ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes
of Operation). Each 128-bit block is first encrypted with AES (256-bit key) in
XTS mode and then with Serpent (256-bit key) in XTS mode. Each of the cascaded
ciphers uses its own key. All encryption keys are mutually independent (note
that header keys are independent too, even though they are derived from a
single password – see the section Header Key Derivation, Salt, and Iteration
Count). See above for information on the individual cascaded ciphers.
Serpent-Twofish-AES
Three ciphers in a cascade [15, 16] operating in XTS mode (see the section
Modes of Operation). Each 128-bit block is first encrypted with AES (256-bit
key) in XTS mode, then with Twofish (256-bit key) in XTS mode, and finally with
Serpent (256-bit key) in XTS mode. Each of the cascaded ciphers uses its own
key. All encryption keys are mutually independent (note that header keys are
independent too, even though they are derived from a single password – see the
section Header Key Derivation, Salt, and Iteration Count). See above for
information on the individual cascaded ciphers.
Twofish-Serpent
Two ciphers in a cascade [15, 16] operating in XTS mode (see the section Modes
of Operation). Each 128-bit block is first encrypted with Serpent (256-bit key)
in XTS mode and then with Twofish (256-bit key) in XTS mode. Each of the
cascaded ciphers uses its own key. All encryption keys are mutually independent
(note that header keys are independent too, even though they are derived from a
single password – see the section Header Key Derivation, Salt, and Iteration
Count). See above for information on the individual cascaded ciphers.
=[end quote]=
A potentially discomforting point in how Truecrypt does this, is that they
state, that the different cascaded header keys are derived from a single
password.
It may well be that, as Robert intuitively felt, an avenue of attack on the
password and subsequently derived keys, might be far more feasible than trying
to brute force a keyspace, and therefore rendering the resulting ciphertext
more vulnerable than if it were encrypted only once.
vedaal
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 31/10/13 16:37, ved...@nym.hush.com wrote: The advantage is, that if it should ever be possible to brute force the keyspace of one key, then NONE of the possible elements of the keyspace (including the *correct* key) will result in an identifiable *correct* plaintext. It will only result in random ciphertext. Then again: If brute forcing a key costs you all the energy in this solar system, you don't have any light to read the decrypted message by. And that's what we're talking about here. So: forget about brute-forcing. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
Playing Captain Obvious:
Excellent! Let's play more.
- \forall {A,B \in G} -- A X B \in G: G is closed.
What's this \forall and \in? I don't understand. Are those HTML
entity codes that my email client isn't presenting properly?
... Or, in other words, your very first line assumes a level of
mathematical knowledge that the overwhelming majority of people lack:
namely, the abilities of understanding mathematical notion and TeX.
Likewise with your answer about how it must uphold the associative
property: a lot of people are going to conflate associativity with
commutativity.
Abstract mathematics is the sort of thing that needs to be avoided at
all costs when giving explanations to non-specialists. It just
doesn't work.
I don't doubt that. I assumed (yes I know, assumption is the mother of
all fuckups) that these things were analyzed during the long
cryptanalysis the algorithms in gpg have had.
Quite possibly not, as whether AES is a group has absolutely no
bearing on how easy it is to break AES -- only on whether AES can be
used in composition, which is not particularly high priority.
The reason why the cryptanalytic community looked into whether DES
forms a group is because the 56-bit keyspace was too short and we
critically needed a way to compose DES into a stronger algorithm.
That's not the case with AES.
A quick search of Google Scholar does not turn up any articles about
whether AES forms a group. I don't know one way or another. My
suspicion is that it does not, but I'm not willing to trust that
suspicion.
Did noone researched something like 3AES yet?
Not to my knowledge.
However, encrypting a message with AES with key1 and then encrypting it
again with key2 (key1 unrelated to key2) can't make it less secure since
any attacker can encrypt the intercepted encrypted message again with
little effort.
Beware of saying can't unless you've got a formal mathematical proof
in your hands. Even then, salt your pronouncements with at our
present level of ignorance.
It is true that one of AES's design goals was exactly as you say
above. However, there is no proof that they succeeded. A lot of
eminent mathematicians think it's overwhelmingly probable they
succeeded, but I'm unaware of anyone who believes this has been proven.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
The advantage is, that if it should ever be possible to brute force the keyspace of one key No one will ever be able to brute-force a 128-bit key until such time as we have quantum computers with 256-bit ensembles running at 3.2 kelvins and powered by stars. Consequentially, I don't think this is any advantage at all. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 31-10-2013 22:36, Robert J. Hansen wrote: ... Or, in other words, your very first line assumes a level of mathematical knowledge that the overwhelming majority of people lack: namely, the abilities of understanding mathematical notion and TeX. I am quite confident the majority of the people don't understand this, but they don't need to. Someone can prove wether AES / Twofish / ... / combinations of them is a group or not, and can then explain that combinations are safer / at least as safe / less safe. Since I majored in physics and didn't get that much discrete math, I may could not even understand such a proof myself completely. But assuming the conclusion is accepted by knowledgable people I would trust the reasoning. I also didn't check the proof that DES is not a group, but I trust that if it was incorrect I would heve heard about that. The same mechanism as why I trust gpg does not contain any deliberate backdoor, even when I didn't check the entire soucre myself. Abstract mathematics is the sort of thing that needs to be avoided at all costs when giving explanations to non-specialists. It just doesn't work. For non-speciallists you can stick with the conclusion: it has been proven that X is true of not true without giving details about the proof. A quick search of Google Scholar does not turn up any articles about whether AES forms a group. I don't know one way or another. My suspicion is that it does not, but I'm not willing to trust that suspicion. OK, I assumed someone would have checkeds that by now. Probably I was wrong about that. However, encrypting a message with AES with key1 and then encrypting it again with key2 (key1 unrelated to key2) can't make it less secure since any attacker can encrypt the intercepted encrypted message again with little effort. Beware of saying can't unless you've got a formal mathematical proof in your hands. Any attacker can encrypt my message again with a nonrelated key (and only with a nonrelated key since they don't know the key I used). If that would make it easier to break AES then re-encrypting the message that would be a better than pure brute force attack on AES. It is true that one of AES's design goals was exactly as you say above. However, there is no proof that they succeeded. A lot of eminent mathematicians think it's overwhelmingly probable they succeeded, but I'm unaware of anyone who believes this has been proven. My argument is that even if it turns out to be not the case, that method would just be an attack on AES. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
I am quite confident the majority of the people don't understand this, but they don't need to. Someone can prove wether AES / Twofish / ... / combinations of them is a group or not, and can then explain that combinations are safer / at least as safe / less safe. Yes. But please remember how this entire subthread started. Someone proposed stacking ciphers. I answered that was not guaranteed to work, and used ROT as an example. You responded that the only reason it fails with ROT is because ROT forms a group. To which I responded with: so what? To my knowledge nobody's proven AES does not form a group, either, and incidentally, let's avoid talk about abstract mathematics because it's unnecessary to the discussion and only serves to make our conversation opaque to people who are not mathematicians. For non-speciallists you can stick with the conclusion: it has been proven that X is true of not true without giving details about the proof. Yes. And I repeat: you cannot blithely stack ciphers together because doing so may be harmful to the overall security of the system. And that's all that most people on the list need to know, really, without a side discussion about group theory. Any attacker can encrypt my message again with a nonrelated key (and only with a nonrelated key since they don't know the key I used). If that would make it easier to break AES then re-encrypting the message that would be a better than pure brute force attack on AES. Yes, I know. Even if I didn't, you explained it quite well in your message and I would've learned. I don't disagree with your conclusion. I disagree with your *certainty*. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
The reason why the cryptanalytic community looked into whether DES forms a
group is because the 56-bit keyspace was too short and we critically needed
a way to compose DES into a stronger algorithm. That's not the case with
AES.
Disclaimer : I am not a mathematician, only a student in mathematics. I did not
learn mathematics in the English language, but have tried to check on wikipedia
the vocabulary I am about to use is the correct in english, but please pardon me
if I make a mistake. Anything I have not checked should be redefined. And this
text is not intended for people with no insight on basic group theory.
Definitions :
* [1;n] will be the set of all integers from 1 to n, ends included.
* M is the set of possible messages.
* C is the set of possible ciphertexts.
* F(M, C) is the set of encryption functions (key included), that take a
message in M as input, and yields a ciphertext in C as output. IOW, it is the
set of bijections from M to C.
Assumption : F(M, C) is a group for \circ, the composition, as any encrypted
message ought to be decipherable. (Well, not really a group, as the inverse
bijection would be in F(C, M), but I will write it is a group for ease of
expression. Correcting this would only be adding useless text, so feel free to
do it in you mind if you prefer.)
First, I'll assume that, when you say ROT is a group, you mean that
(n - ROTn) is a group morphism between (F(M, C), \circ) and (Z/26Z, +).
Let n be a positive integer.
So, now, let's assume K = [1; 2^n] is a group for some law *. Let's assume that
AES-n is a group morphism between (F(M, C), \circ) and (K, *).
In my opinion (and a bit more than that), it changes nothing to the question.
Indeed, composing two (or more) AES-n with independantly random-chosen keys is
at least as strong as one AES-n with a random-chosen key, which, IIRC, was the
heart of thhe matter.
As a proof, let's take k1 and k2 two independantly random-chosen keys in K.
Then, AES-n(k1) \circ AES-n(k2) = AES-n(k1 * k2).
Now, let's prove k1 * k2 is a randomly-chosen key in K. First, (x - k1 * x)
is a bijection. So, if x is chosen randomly, then so is k1 * x. And k2 is chosen
randomly (independantly from k1, which is quite important here), so k1 * k2 is a
randomly-chosen key in K.
Proof of the first statement :
Let a, b two keys in K. Then k1 * a = k1 * b implies a = b by mere
multiplication by k1^{-1}.
So (x - k1 * x) is an injection from K to K, and K is a finite set, so
(x - k1 * x) is a bijection on K.
Another way of seeing this would be by exposing the inverse : (x - k1^{-1} * x)
I know this is a well-known result, but preferred to redemonstrate it, just in
case.
So, whether AES-n is a group morphism or not does not matter for the question,
which was trying to find a resulting algorithm at least as strong as the
strongest of all.
And DES was checked for a group-like behavior because the objective was not to
create an algorithm at least as strong as the strongest component, but to create
an algorithm as strong as the sum of all components, which is substantially
harder.
BTW, the example about ROT still fits the proof : remember ROT0 could be
selected by a random key with probability 1/26. You can check ROTn \circ ROTm
(ie. ROT(n + m)) yields ROT0 with probability 1/26, when n and m are both chosen
uniformly. (Well, it's just 26 ways of making 26 from the sum of two numbers
from 0 to 25, this divided by the total possibilities of 26^2.)
As a conclusion, IMHO (and without proof here, just gut feeling, even though a
start of proof was given by Philipp earlier), stacking two algorithms with
unrelated randomly-chosen keys makes an algorithm at least as strong as the
strongest of the two algorithms, to the cost of transimitting a longer key and
spending more time on enc/decryption, which, admittedly, might be quite an
issue.
Hoping I did not make too much mistakes, both in mathematics and in the English
language,
Leo
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.09.2013 15:30, schrieb Robert J. Hansen: On 9/10/2013 6:35 AM, Philipp Klaus Krause wrote: I wonder if it would be a good idea to have an option to combine symmetric ciphers, e.g. users could state a preference list like this: No. This idea gets floated every few years and the answers never change. It's not a good idea. If you look in the list archives you can find some pretty long, detailed writeups on why. I just tried googling a bit, but the only posts I found are those that assume that the effort to break A+B would be a+b. I did not find the detailed writeups you mentoned, or even anything else about the assumption that breaking A+B takes at least effort max(a,b). Assuming it takes effort a to break cipher A and effort b to break cipher b, this should result in effort at least max(a, b) needed to break A+B. Basically, though, it's this is a naive and unfounded assumption. Well, here's a (rough, and maybe naive) explanation of why I assumed that the effort is at least max(a, b): First, I assume assume that the effort for breaking anything so is much more than the effort for encryption given the key, that the latter is negligible. So assume there is an attack on A+B. that allows to break A+B with effort e less than max(a,b). That means that at least one of e a or e b is true. Case 1: e a: Well, whenever someone is using A, we can just encrypt the ciphertext using B with a key of our choice. Any attack on A+B thus immediately translates into an attack on A, contradicting the assmption e a. The attack on A would be of the same type as the one on A+B. Case 2: e b: Hmm, this one seems harder. If I have an attack on A+B that yields information about the key, I can get a chosen-ciphertext attack on B from it. An attack on A+B that yields information about the plaintext could be combined with an attack on A that yields information on the key to get an attack on B that yields information on the plaintext. If A happens to have a weak key, I would get an attack on B that yields information on the plaintext as well. Any way I should get an interesting result of the type b a + e. I think there is a stronger result possible here, but I admit don't know how I could get there. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxP5wACgkQbtUV+xsoLpoIaACg8KWSjlIToJb40MzI4r+b1nT9 ySAAn0zbo5hbMReGpCycThO6Cy4BAg1H =gNuW -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
Well, here's a (rough, and maybe naive) explanation of why I assumed that the effort is at least max(a, b): If you first encrypt with ROT10 and then with ROT16, the final strength is not the maximum of (ROT10, ROT16). You may think that's a silly example, and I grant that it is, but it illuminates the point pretty well and avoids a lot of difficult math. Cryptographic algorithms are extremely subtle and interact with each other in subtle ways. As a general rule they should not be stacked unless there is (a) a clear necessity and (b) the particular stacking has been formally proven to not diminish the overall security of the system. Otherwise, much as how ROT10+ROT16 has really awful security characteristics, your stacking may be similarly awful. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.09.2013 13:45, schrieb Werner Koch: You would also need a second public keypair to protect the second symmetric key. If you don't, the attacker would target the public key scheme directly - ah well that is in any case the lower hanging fruit. I wouldn't assme that: RSA is something taught in typical maths and computer science curriculums at universities. Factorization is a well-known problem. Symmetric ciphers, on the other hand are for specialists. So I would assume that RSA got much more attention and eyes looking at it than any symmetric cipher. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxPIAACgkQbtUV+xsoLpqAAACg9OF7Wa+MsoIbyEpcEqruFpgT rkUAniJ6U2sZExDoo/iFa4A1W4XXobaw =wl/M -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.10.2013 18:39, schrieb Robert J. Hansen: Well, here's a (rough, and maybe naive) explanation of why I assumed that the effort is at least max(a, b): If you first encrypt with ROT10 and then with ROT16, the final strength is not the maximum of (ROT10, ROT16). You may think that's a silly example, and I grant that it is, but it illuminates the point pretty well and avoids a lot of difficult math. But ROT10 and ROT16 fail the condition that breaking them should be substancially harder than applying them. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxUOwACgkQbtUV+xsoLpp/SQCgxg0xSXLXEzpazQ3TwhXv82JC HNcAnAsmU5WL/naU9LbBAY4GdrtRyoo/ =euUP -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
Quoting Philipp Klaus Krause p...@spth.de: But ROT10 and ROT16 fail the condition that breaking them should be substancially harder than applying them. Arguing that but that's not a real example! is a nonstarter. It wasn't presented as a real example. It was presented as a way to illuminate the principle involved -- that algorithms can interact with each other in ways that diminish the security of both -- without needing to break out graduate-level mathematics. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.09.2013 12:35, schrieb Philipp Klaus Krause: I wonder if it would be a good idea to have an option to combine symmetric ciphers, e.g. users could state a preference list like this: TWOFISH+AES256 3DES+BLOWFISH+AES AES 3DES The meaning of A+B would be to encrypt using A first, and then encrypt the result using B with a different key. Assuming it takes effort a to break cipher A and effort b to break cipher b, this should result in effort at least max(a, b) needed to break A+B. And with uncertainity about possible weaknesses in individual ciphers, this seems like a reasonable measure to me. Philipp If we have plenty of randomness available, we could do this a different way: XOR the message M with a random one-time pad P to obtain N. Encrypt P with A, and N with B. The drawback is that this doubles the lenth of the message. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxXTEACgkQbtUV+xsoLpqEhwCgnb7/AFx3b8q6a/sFPfPSt4NG 8SYAn3DgDL2BXYAwdfdcTSl+tBDJ/Jwt =Hsq+ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 30/10/13 20:25, Philipp Klaus Krause wrote: If we have plenty of randomness available, we could do this a different way: XOR the message M with a random one-time pad P to obtain N. Encrypt P with A, and N with B. Why are you inventing new crypto primitives? Symmetric crypto is already good enough. But to immediately debunk this system: there is a strong correlation between P and N (i.e., the plaintext). This means you are encrypting strongly correlated material with two different ciphers. If you can somehow make them meet in the middle, you no longer have to completely break one of the ciphers completely but instead break both partially, which might be orders easier to do. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
If we have plenty of randomness available, we could do this a different way: Dangerously naive. Meet-in-the-middle and/or miss-in-the-middle attacks could be devastating. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On Wed, 30 Oct 2013 20:25, p...@spth.de said: If we have plenty of randomness available, we could do this a Entropy (which should be at the core of every CRNG) is a scarce resource. Thus a one time pad is not going to work because you need true random at the same size of the message. XOR the message M with a random one-time pad P to obtain N. Encrypt P with A, and N with B. The drawback is that this doubles the lenth of the message. And that you need a way to securely convey the OTP to the recipient. The soviets had severe problems to do that during WWII and later and resorted to double use the one time pads. That was one of the origins of the UKUSA alliance aiming and succeeding at breaking there messages (project VENONA). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On Wed, 30 Oct 2013 18:06, p...@spth.de said: I wouldn't assme that: RSA is something taught in typical maths and computer science curriculums at universities. Factorization is a well-known problem. Using RSA in a safe way is a not easy - it took more than 20 years until most cryptographers are convinced that there are safe way of using RSA. Check out the notes section in the HAC on attacks on RSA. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there a known good way to combine multiple symmetric ciphers into something that is at least as strong as the weakest of them? Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxiSkACgkQbtUV+xsoLprSJQCfSXdZW2CmWFz6+CCpRNT3nBLK El4An1psE3eEeYZU36f9Z+YXuYQBSwvD =fsr4 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: The symmetric ciphers
I guess I lost track of the initial purpose of this thread. Why do you want this if you can only achieve the same cryptographic strength as one of the ciphers? What problem are you solving? Thanks, Bob Cavanaugh Broadcom Corporation 16340 West Bernardo Drive San Diego CA 92127 Work:858-521-5562 Fax: 858-385-8810 Cell:858-361-2068 -Original Message- From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Philipp Klaus Krause Sent: Wednesday, October 30, 2013 3:33 PM To: gnupg-users@gnupg.org Subject: Re: The symmetric ciphers * PGP Signed by an unknown key Is there a known good way to combine multiple symmetric ciphers into something that is at least as strong as the weakest of them? Philipp * Unknown Key * 0x1B282E9A(L) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.10.2013 23:33, schrieb Philipp Klaus Krause: Is there a known good way to combine multiple symmetric ciphers into something that is at least as strong as the weakest of them? Philipp This should have been ... as the strongest of them?. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxjlkACgkQbtUV+xsoLpoWVwCeN21t5LI39J9Fz4JcJfJp85fh CXQAoITjUB4H/LTVPN5yS7UlVfrgUjP7 =7eRd -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.10.2013 23:51, schrieb Bob (Robert) Cavanaugh: I guess I lost track of the initial purpose of this thread. Why do you want this if you can only achieve the same cryptographic strength as one of the ciphers? What problem are you solving? There are multiple symmetric ciphers. Any one of them might already have been broken by an adversary, but I assume that there are many among them that are not broken. I do not know which ones are which. So, if I have ciphers A, B and C, and a way to combine them into one symmetric cpher that is at least as strong as the strongest among them, I could use this combined cipher for somewhat secure communication as long as at least one of A, B, C is not broken, even if I do not know which ones are broken. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJxjsMACgkQbtUV+xsoLpoM7ACfUWEYet6vVgtQH4PDJQmYIbBP i78AoIyoDEdCSzbzHTXUicuaxlwsWaD3 =5hUv -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
Is there a known good way to combine multiple symmetric ciphers into something that is at least as strong as the weakest of them? Not one that generalizes to all ciphers. signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
So, if I have ciphers A, B and C, and a way to combine them into one symmetric cpher that is at least as strong as the strongest among them, I could use this combined cipher for somewhat secure communication as long as at least one of A, B, C is not broken, even if I do not know which ones are broken. Or you could just use 3DES. Reposted from the last time was wondering if anything had been broken in the OpenPGP suite: = I have said this many times in the past; apparently I need to say it again. 3DES has been turning brilliant cryptanalysts into burned-out alcoholic wrecks for over thirty years. Nothing in the OpenPGP suite comes anywhere near to the safety provided by 3DES. Nothing even comes *close*. Assuming your adversary has access to more computing power than exists in the entire world, 3DES offers only 112 bits of security; for realistic assumptions about computing power, 3DES offers the full 168 bits. 3DES is ugly, awkward, ungainly, slow, and it has all the aesthetic appeal of the Socialist Realism school of art. It is *awful*. And yet, it keeps on going, completely impervious to the last three decades of cryptanalysis. It reminds me quite a lot of the coelacanth -- a fish that was found in the fossil record 400 million years ago, and still can be found swimming in the oceans today. If you look at a coelacanth it just looks primitive, unevolved, and strangely frightening. It has survived the last 400 million years of Nature's attempts at killing it. It commands respect and admiration, even while at the same time giving vague feelings of revulsion. 3DES is our coelacanth. http://outlookcolumbus.com/wp-content/uploads/2013/02/coelacanth1.jpg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 30-10-2013 18:39, Robert J. Hansen wrote: If you first encrypt with ROT10 and then with ROT16, the final strength is not the maximum of (ROT10, ROT16). You may think that's a silly example, and I grant that it is, but it illuminates the point pretty well and avoids a lot of difficult math. That's because ROT(N) is a group. In a way, we already use a combination cipher in the form of 3DES, which uses 3 times the same cipher (OK, 2 times and one time in the reverse) but that works because DES is not a group. I don't know wether the other symmetric ciphers are a group though, but I'm sure someone has investigated that. Cryptographic algorithms are extremely subtle and interact with each other in subtle ways. As a general rule they should not be stacked unless there is (a) a clear necessity and (b) the particular stacking has been formally proven to not diminish the overall security of the system. Otherwise, much as how ROT10+ROT16 has really awful security characteristics, your stacking may be similarly awful. Assuming that the same key is used for all that is. Otherwise, if an attacker knew how to make use of this, encrypting the encrypted message would help decrypting it, and since any attacker could do that it should not matterfor a decent encryption algorithm (which ROT(N) clearly is not). -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 10/30/2013 7:20 PM, Johan Wevers wrote: That's because ROT(N) is a group. Yes, but good luck answering the inevitable next two questions: what's a group? and how do we know if something's a group? You very quickly run into some complicated higher-level maths, and that's something best avoided. I don't know wether the other symmetric ciphers are a group though, but I'm sure someone has investigated that. There is no single answer to this. The other symmetric ciphers need to be evaluated combinatorically: for instance, are AES128, 3DES and Camellia a group? That answer may be different from AES192, 3DES and Camellia. Given there are 11 different symmetric algorithms as of 2.0.22, figuring out all known-safe 3-cipher selections would require us to investigate 165 different combinations. Frankly, I don't feel like doing that much work. Assuming that the same key is used for all that is. No. I'm quite happy with my blanket statement: cryptographic algorithms are subtle and should be left alone. If you're Don Coppersmith then I think you should feel free to get down with your bad self, but otherwise this entire line of inquiry is one that I think goes nowhere good. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
The symmetric ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wonder if it would be a good idea to have an option to combine symmetric ciphers, e.g. users could state a preference list like this: TWOFISH+AES256 3DES+BLOWFISH+AES AES 3DES The meaning of A+B would be to encrypt using A first, and then encrypt the result using B with a different key. Assuming it takes effort a to break cipher A and effort b to break cipher b, this should result in effort at least max(a, b) needed to break A+B. And with uncertainity about possible weaknesses in individual ciphers, this seems like a reasonable measure to me. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlIu9f8ACgkQbtUV+xsoLpr7hgCglipmlV07D+wh0ylVgs+7MX1E d+wAnREuQlhGEEg6IbcHXRb+L/d/hIBS =T5GL -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
Philipp Klaus Krause p...@spth.de wrote: I wonder if it would be a good idea to have an option to combine symmetric ciphers, e.g. users could state a preference list like this: TWOFISH+AES256 3DES+BLOWFISH+AES AES 3DES The meaning of A+B would be to encrypt using A first, and then encrypt the result using B with a different key. Assuming it takes effort a to break cipher A and effort b to break cipher b, this should result in effort at least max(a, b) needed to break A+B. And with uncertainity about possible weaknesses in individual ciphers, this seems like a reasonable measure to me. You may just prefer to use a key with a larger size and a better password. But if you do want to do this, I am sure that you could write a script or program that could take advantage of GnuPG for this purpose. Cheers, --Paul -- PGP: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 9/10/2013 6:35 AM, Philipp Klaus Krause wrote: I wonder if it would be a good idea to have an option to combine symmetric ciphers, e.g. users could state a preference list like this: No. This idea gets floated every few years and the answers never change. It's not a good idea. If you look in the list archives you can find some pretty long, detailed writeups on why. Assuming it takes effort a to break cipher A and effort b to break cipher b, this should result in effort at least max(a, b) needed to break A+B. Basically, though, it's this is a naive and unfounded assumption. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On Tue, Sep 10, 2013 at 3:30 PM, Robert J. Hansen r...@sixdemonbag.orgwrote: Assuming it takes effort a to break cipher A and effort b to break cipher b, this should result in effort at least max(a, b) needed to break A+B. Basically, though, it's this is a naive and unfounded assumption. Why? Assuming the Keys are not related (e.g. by creating random keys and then encrypting them both with RSA) this is safer, assuming the attacker can crack one of the two symmetric ciphers but not RSA. If you use the same/related Keys for both encryptions and/or the ciphers don't interact somehow (like when using ROT-13 two times) it is indeed less secure! ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: The symmetric ciphers
On 09/10/2013 11:10 AM, Josef Schneider wrote: Why? Assuming the Keys are not related (e.g. by creating random keys and then encrypting them both with RSA) this is safer, assuming the attacker can crack one of the two symmetric ciphers but not RSA. I repeat my earlier message: If you look in the list archives you can find some pretty long, detailed writeups on why. It takes you about thirty seconds to type a message. To fully answer your question would require me to spend about an hour crafting an answer. Since your question has been answered *at length* in the archives, I'm not going to answer your question. I'm going to refer you to the archives and save myself an hour. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: throughput of GnuPG symmetric ciphers
I suggest looking at openssl. I'd hazard a guess that most nix OS's end up with it installed. The speed command does benchmarking :) Barton 2Ghz: $ openssl speed aes-256-cbc bf-cbc Doing aes-256 cbc for 3s on 16 size blocks: 6396149 aes-256 cbc's in 2.98s Doing aes-256 cbc for 3s on 64 size blocks: 1620087 aes-256 cbc's in 2.99s Doing aes-256 cbc for 3s on 256 size blocks: 408486 aes-256 cbc's in 2.99s Doing aes-256 cbc for 3s on 1024 size blocks: 102550 aes-256 cbc's in 2.98s Doing aes-256 cbc for 3s on 8192 size blocks: 12828 aes-256 cbc's in 2.99s Doing blowfish cbc for 3s on 16 size blocks: 13773579 blowfish cbc's in 2.99s Doing blowfish cbc for 3s on 64 size blocks: 3789308 blowfish cbc's in 2.98s Doing blowfish cbc for 3s on 256 size blocks: 966098 blowfish cbc's in 2.99s Doing blowfish cbc for 3s on 1024 size blocks: 243690 blowfish cbc's in 2.99s Doing blowfish cbc for 3s on 8192 size blocks: 30494 blowfish cbc's in 2.98s OpenSSL 0.9.7e 25 Oct 2004 built on: Fri Dec 17 08:45:11 UTC 2004 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -DL_ENDIAN -DTERMIO -O3 -march=i686 -mcpu=i686 -fomit-frame-pointer -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes blowfish cbc 73704.77k81381.11k82716.08k83457.71k83827.80k aes-256 cbc 34341.74k34677.45k34974.05k35238.66k35146.15k On 8/4/05, Ryan Malayter [EMAIL PROTECTED] wrote: On 8/3/05, Henry Hertz Hobbit [EMAIL PROTECTED] wrote: Given the size of the files that you are encrypting, I would strongly advise going with the Eden chip rather than a software based solution... I actually found an open-source tool, 7-zip, that includes AES-256 encryption functionality. For whatever reason, it runs several times faster than GnuPG in software. Fast enough, in fact, that the removable hard disk devices have become the limiting factor in the system (the 7-zip process only uses 70% CPU on a 2.4 GHz P4). The code is open-source, and it uses a salted + iterated SHA256 hash to produce the AES key from a pass phrase. The AES implementation is Gladman's well-known and fast C++ code. Looking at the source, I haven't figured out whether it uses ECB or CFB mode yet; the 7-zip code is rather light on comments. I am assuming ECB, which should be fine for my application. See http://www.7-zip.org for more details. Thanks for all the help. -- Ryan = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: throughput of GnuPG symmetric ciphers
On 8/4/05, Werner Koch [EMAIL PROTECTED] wrote: So roughly libgcrypt gets 55% of the performance of OpenSSL with AES and 61% for 3DES. This all with a higher level interface, a non ia32 optimized AES. I am pretty sure we can improve here but it will require to duplicate code for the modes (CBS,CFB) into the actual cipher implementation. My test show 7-zip yields ~228 Mbps on a 2.4 GHz P4. The only cipher available with this program is AES256 in (I believe) ECB mode. I presume this performance is the result of the efficient Gladman code and a P4-specific compiler optimizations used when building 7-zip. Still, it seems a bit odd that this program generates AES-256 throughput 2.78 times faster than the AES-256 implementation in GnuPG/libgcrypt on the same machine. I suppose those large lookup tables in the Gladman code really speed things up. (I would not think the extra XOR operation used in GnuPG's CFB implementation would account for so large a difference). Gladman's very fast GPL-compatible code (as used in 7-zip) is available at http://fp.gladman.plus.com/cryptography_technology/index.htm. He has C, C++, and x86 assembly implementations. You might want to take a look. Gladman's code uses large tables, which presumably makes it vulnerable to the recently publicized timing attacks. That should not be an issue for GnuPG, but might be for other programs that use libgcrypt. -- RPM = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: throughput of GnuPG symmetric ciphers
On 8/4/05, Ryan Malayter [EMAIL PROTECTED] wrote: My test show 7-zip yields ~228 Mbps on a 2.4 GHz P4. The only cipher available with this program is AES256 in (I believe) ECB mode. You seem pretty knowledgeable, but I'll say it anyway: ECB in general shouldn't be used. Especially in the case of large amounts of data being encrypted. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: throughput of GnuPG symmetric ciphers
On Thu, 4 Aug 2005 08:10:00 -0500, Ryan Malayter said: My test show 7-zip yields ~228 Mbps on a 2.4 GHz P4. The only cipher available with this program is AES256 in (I believe) ECB mode. Why encrypt at all when using ECB? ECB has no use except in very very special cases. Still, it seems a bit odd that this program generates AES-256 throughput 2.78 times faster than the AES-256 implementation in GnuPG/libgcrypt on the same machine. I suppose those large lookup Brian Gladmans code is pretty good but we can't include it into GnupG for legal reasons (it is in the cintrib directory of 1.2, though) and becuase it has been optimized for specific CPUs. Yes. I'd like to see better optimized implementations but these days it is hard to do unless you know exactly what CPU will run the code; its not only about ia32, sparc, ppc. Each ia32 compatible CPU needs its own optimized implementation - a lot of work in particular if not being paid for. tables in the Gladman code really speed things up. (I would not think the extra XOR operation used in GnuPG's CFB implementation would Its not the xoring but more likely caching and alignment issues. Gladman's code uses large tables, which presumably makes it vulnerable to the recently publicized timing attacks. That should not be an issue for GnuPG, but might be for other programs that use libgcrypt. When implementing crypto systems one should never ever allow using the system as an oracle. Salam-Shalom, Werner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: throughput of GnuPG symmetric ciphers
On 8/3/05, Henry Hertz Hobbit [EMAIL PROTECTED] wrote: Given the size of the files that you are encrypting, I would strongly advise going with the Eden chip rather than a software based solution... I actually found an open-source tool, 7-zip, that includes AES-256 encryption functionality. For whatever reason, it runs several times faster than GnuPG in software. Fast enough, in fact, that the removable hard disk devices have become the limiting factor in the system (the 7-zip process only uses 70% CPU on a 2.4 GHz P4). The code is open-source, and it uses a salted + iterated SHA256 hash to produce the AES key from a pass phrase. The AES implementation is Gladman's well-known and fast C++ code. Looking at the source, I haven't figured out whether it uses ECB or CFB mode yet; the 7-zip code is rather light on comments. I am assuming ECB, which should be fine for my application. See http://www.7-zip.org for more details. Thanks for all the help. -- Ryan = All problems can be solved by diplomacy, but violence and treachery are equally effective, and more fun. -Anonymous ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
is your message about service throughput? (was: Re: throughput of GnuPG symmetric ciphers)
Hi Ryan, * Ryan Malayter [EMAIL PROTECTED] [01. Aug. 2005]: I'm reposting this because it never appeared on the list for some reason, even after 12 hours. is your message about service throughput? Gregor ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
throughput of GnuPG symmetric ciphers
I was going to use GnuPG for encrypting some very large backup files on disk (~200 GB). However, the symmetric ciphers in GnuPG seem to be fairly slow. Using the Windows build of 1.4.2, I only modest throughputs piping GPG output from a fast 7200 RPM disk to NUL (the Windows equivalent of /dev/nul). (See table at end of email). The process is not disk bound, since it uses 100% CPU and the different algorithms take different times. Compression was turned off. I have seen references on the net to fast software implementations of AES that are an order of magnitude faster than GnuPG on a P4 (~1.5 Gbps). See http://www.via.com.tw/en/resources/pressroom/2003_archive/pr031014edenn.jsp. Has anyone made a GnuPG patch that includes faster implementations of the core symmetric algorithms? What other tools are people using for encrypting backups in datacenter operations (as GnuPG seems to be too slow for this task)? Thanks for any help, Ryan Tests encrypting a 1 GB file on a 2.4 GHz Pentium 4. Cipher Algorithm Speed (Mbps) --- CAST5 153.39 BLOWFISH 59.24 AES102.26 3DES 64.59 AES-25681.81 TWOFISH124.49 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
