Re: 2048 or 4096 for new keys? aka defaults vs. Debian

2013-10-31 Thread Robert J. Hansen 
On 10/31/2013 4:31 PM, Daniel Kahn Gillmor wrote:
> ENISA (the European Union Agency for Network and Information Security)
> recently issued a report recommending that non-legacy systems using RSA
> start with keys that are >= 3072 bits (see page 30 of the PDF):

Huh -- fascinating!  Thank you for this new data point, dkg!


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: The symmetric ciphers

2013-10-31 Thread Leo Gaspard 
> 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

2013-10-31 Thread Robert J. Hansen 

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

2013-10-31 Thread Johan Wevers 
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: 2048 or 4096 for new keys? aka defaults vs. Debian

2013-10-31 Thread Peter Lebbing 
On 31/10/13 22:02, Hauke Laging wrote:
> But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia
>  article for AES) claims that AES-256 was down to 99.5 bits.

I just glanced over the abstract, but didn't you glance over the term "related
key"? I.e., not generally applicable.

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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Quotes from GPG users

2013-10-31 Thread Paul R. Ramer 
Sam Tuke  wrote:
>Hi all,
>
>I'm working with Werner to promote GnuPG and raise awareness. To that
>end we're
>collecting quotes from users - endorsements from people who know and
>trust GPG,
>people like you.
>
>If you want to help us, send your own statement about why GPG is
>important to
>you. Please keep it less than or equal to 130 characters, so it can be
>used on
>social networks.
>
>I'll collect them and pick the best for use now and in future.

Well, here is my input for your project.

I wouldn't be able to communicate sensitive documents without it.

Cheers,

--Paul
--
PGP: 3DB6D884

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

2013-10-31 Thread Robert J. Hansen 

But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia
article for AES) claims that AES-256 was down to 99.5 bits.


If memory serves that's a related-key attack.

(Hmm.  When you've gotten to the point where you can recognize  
academic papers by their URLs, maybe that's a sign you need to get a  
hobby... sigh.  Time to take up needlepoint, I guess.)


Anyway.  Although there's some really neat theoretical cryptanalysis  
against AES-256, in reality AES-256 is as solid as the Rock of  
Gibraltar.



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: The symmetric ciphers

2013-10-31 Thread Robert J. Hansen 

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

2013-10-31 Thread Robert J. Hansen 

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: 2048 or 4096 for new keys? aka defaults vs. Debian

2013-10-31 Thread Pete Stephenson 
On Thu, Oct 31, 2013 at 10:02 PM, Hauke Laging
 wrote:
> Am Do 31.10.2013, 16:31:02 schrieb Daniel Kahn Gillmor:
>
>> http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable
>> s/algorithms-key-sizes-and-parameters-report
>
> There is one point I don't understand:
>
> [3.6 Recommendations]
>
> "there is general agreement this should be above the 100-bit level"
>
> "for long term use AES-256"
>
> But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia
> article for AES) claims that AES-256 was down to 99.5 bits.

That attack is only valid if different messages have related keys. If
the keys are chosen randomly, the attack does not apply. I'm not aware
of any crypto system that implements AES with related keys (though if
anyone knows of some, I'd like to know so I can avoid it).

See https://en.wikipedia.org/wiki/Related-key_attack and
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security
for details .

According to the Wiki, the best attack on full-round AES-256 not using
related keys requires 254.4 operations (see
https://research.microsoft.com/en-us/projects/cryptanalysis/aesbc.pdf
).

Cheers!
-Pete

-- 
Pete Stephenson

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

2013-10-31 Thread Hauke Laging 
Am Do 31.10.2013, 16:31:02 schrieb Daniel Kahn Gillmor:

> http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverable
> s/algorithms-key-sizes-and-parameters-report

There is one point I don't understand:

[3.6 Recommendations]

"there is general agreement this should be above the 100-bit level"

"for long term use AES-256"

But this http://eprint.iacr.org/2009/317 (mentioned by the German Wikipedia 
article for AES) claims that AES-256 was down to 99.5 bits.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: 2048 or 4096 for new keys? aka defaults vs. Debian

2013-10-31 Thread Daniel Kahn Gillmor 
On Thu 2013-10-24 15:05:45 -0400, Sylvain wrote:
> I saw a lot of activity in the Debian project about upgrading to a
> 4096 RSA key,
> e.g. http://lists.debian.org/debian-devel-announce/2010/09/msg3.html
>
> However GnuPG's default is 2048.

ENISA (the European Union Agency for Network and Information Security)
recently issued a report recommending that non-legacy systems using RSA
start with keys that are >= 3072 bits (see page 30 of the PDF):

http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report

Clearly, any OpenPGP implementation needs to deal with legacy systems,
so being able to interact with older, shorter keys is a necessity.  But
the authors of that report do seem to suggest that the default for RSA
keys should be 3072-bits going forward (though they don't mention
OpenPGP explicitly at all).

The fact that the report comes from a fancy governmental web site
doesn't mean it's correct, of course.  I'm just offering it as a data
point in the discussion :)

--dkg


pgpqnyx21ibA1.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: The symmetric ciphers

2013-10-31 Thread Peter Lebbing 
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 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: The symmetric ciphers

2013-10-31 Thread vedaal 


On Thursday, October 31, 2013 at 10:06 AM, "Johan Wevers" 
 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, ; 0Of 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

2013-10-31 Thread Johan Wevers 
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

2013-10-31 Thread Mark H. Wood 
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

2013-10-31 Thread Mark H. Wood 
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

2013-10-31 Thread Mark H. Wood 
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: Quotes from GPG users

2013-10-31 Thread Heinz Diehl 
On 30.10.2013, Sam Tuke wrote: 

> I'm working with Werner to promote GnuPG and raise awareness.

Just my 5ø:

Raised awareness does seldom lead to change (just as knowledge and
attitudes). Before developing a strategy on promoting the use of 
GPG, the barriers which prevent people from using it should be 
explored and fed back into the implementation strategy.

Maybe some principles from social marketing (insight, exchange..) 
would fit as a good starting point for a campaign.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users