Subject: [Cfrg] Cryptographic meta-principles

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 23 May 2012 10:30:59 -0400

Some cryptographic meta-principles.  Feel free to disagree or make
additions.    I think 2, 5, 7 and 8 

are the most relevant to the CFRG.   I always found #1 useful in
analyzing systems.  Always

ask "where have we moved the risk?".

1.       You can't eliminate risk, you can just move it around. 

2.       Needless complexity is the enemy of security.

3.       There is no such thing as a secure algorithm, only a secure
system.  Even the most "secure" algorithm, if used improperly, can be
worthless.   Without the proper architecture, implementation, and
management we are effectively "putting bank vault doors on cardboard
boxes". 

4.       In the end everything  comes down to  a cost analysis: how much
does it cost an adversary to attempt to exploit a
given system and what is the adversary's expected gain from succeeding?
Our goal is to select cryptographic mechanisms and parameter sizes that
make the adversary's expected return on investment negative. 

5.       Moore's Law continually decreases an adversary's cost to attack
a system. so we must assume that eventually all parameter sizes will
need to be readjusted.

6.       In the limit as the parameter size/number of rounds goes to
infinity, almost anything is secure.  The art is in picking mechanisms
and parameter sizes that meet our needs efficiently.

7.       As far as possible, we should strive to provide a cryptographic
environment that is both practical and stable.

8.       We don't exist in a vacuum.  We need to constantly monitor the
impact of current cryptographic practices on vendors and IETF working
groups, try to foresee  emerging requirements, monitor the results being
produced by the cryptologic research community, and co-ordinate our
efforts with other standards bodies.

Strive to be simple, practical and consistent, but always be aware that
in the long run change is inevitable.

Kevin M. Igoe        |   "Everyone is entitled to their own
[email-masked] <mailto:[email-masked]>    |    opinions, but not to
their own facts."
co-chair CFRG       |       - Daniel Patrick Moynihan -

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 23 May 2012 12:00:25 -0400

These are excellent.  Are they published anywhere stable and citable?  I'd also incorporate some of Shamir's Ten Commandments (from http://www.ieee-security.org/Cipher/ConfReports/conf-rep-Crypto95.html), especially #4.

On May 23, 2012, at 10:30 59AM, Igoe, Kevin M. wrote:

> Some cryptographic meta-principles.  Feel free to disagree or make additions.    I think 2, 5, 7 and 8
> are the most relevant to the CFRG.   I always found #1 useful in analyzing systems.  Always
> ask “where have we moved the risk?”.
>  
> 1.       You can’t eliminate risk, you can just move it around.
> 3.       There is no such thing as a secure algorithm, only a secure system.  Even the most “secure” algorithm, if used improperly, can be  worthless.   Without the proper architecture, implementation, and management we are effectively “putting bank vault doors on cardboard boxes”.
> 4.       In the end everything  comes down to  a cost analysis: how much does it cost an adversary to attempt to exploit a
> given system and what is the adversary's expected gain from succeeding? Our goal is to select cryptographic mechanisms and parameter sizes that make the adversary’s expected return on investment negative.
> 5.       Moore’s Law continually decreases an adversary’s cost to attack a system. so we must assume that eventually all parameter sizes will need to be readjusted.
> 6.       In the limit as the parameter size/number of rounds goes to infinity, almost anything is secure.  The art is in picking mechanisms and parameter sizes that meet our needs efficiently.
> 7.       As far as possible, we should strive to provide a cryptographic environment that is both practical and stable.
> 8.       We don’t exist in a vacuum.  We need to constantly monitor the impact of current cryptographic practices on vendors and IETF working groups, try to foresee  emerging requirements, monitor the results being produced by the cryptologic research community, and co-ordinate our efforts with other standards bodies.
>  
> Strive to be simple, practical and consistent, but always be aware that in the long run change is inevitable.
>  
>  
>  
> [email-masked]   |    opinions, but not to their own facts."
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 May 2012 09:00:35 -0700

> 5.       Moore’s Law continually decreases an adversary’s cost to attack a system. so we must assume that eventually all parameter sizes will need to be readjusted.

This statement assumes that there are always parameter sizes, which is incorrect. SHA2-256 does not have a parameter to make its strength 300 bits; AES-128 does not have a parameter to make its strength 150 bits; and so on.

This is not just a pedantic discussion. For many cryptographic functions, you cannot make them stronger by changing parameters: you have to change algorithms. The operational cost of this is much higher than the cost of telling an administrator to change a configuration setting and then verifying that the setting was changed.

--Paul Hoffman

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 23 May 2012 12:37:26 -0400

> This statement assumes that there are always parameter sizes, which is incorrect. SHA2-256 does not have a parameter to make its strength 300 bits; AES-128 does not have a parameter to make its str…

The 256 and 128 *are* parameters -- but of the system design, not the algorithm.  (Both also have a number of rounds which is in principle tunable, if not in reality, though Schneier suggested changing the number of rounds for AES: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html)
> This is not just a pedantic discussion. For many cryptographic functions, you cannot make them stronger by changing parameters: you have to change algorithms. The operational cost of this is much h…

Sure -- which is why the protocol has to allow for changes in such things, too, and not just in a config file setting.  For example, one can envision an IKEvN initial exchange where one side or the other listed a round count for SHA++ or a blocksize parameter for Rijndael (note: not AES, Rijndael).  But the implications of such fields are very different than the "let's negotiate a new algorithm entirely" idea, per the paper that ekr and I wrote some years back about hash functions.

---

From: "Rose, Greg" <[email-masked]>
Date: Wed, 23 May 2012 17:08:04 +0000

> This is not just a pedantic discussion. For many cryptographic functions, you cannot make them stronger by changing parameters: you have to change algorithms. The operational cost of this is much h…

Also, while Moore's law is exponential, we know there are physical limits. Suitable parameter sizes like AES-256 are manageable today, but won't be compromised by Moore's law in the forseeable future. If it breaks, it will be because of new attacks or a new computing model. So I would change point 5 to say that there has to be provision for changing algorithms to adapt to a changing world.

Greg.

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 23 May 2012 14:20:13 -0400

On Wed, May 23, 2012 at 10:30 AM, Igoe, Kevin M. <[email-masked]> wrote:
> system.  Even the most “secure” algorithm, if used improperly, can be
> management we are effectively “putting bank vault doors on cardboard boxes”.
>
> given system and what is the adversary's expected gain from succeeding? Our
> goal is to select cryptographic mechanisms and parameter sizes that make the
> adversary’s expected return on investment negative.

This is a classic one, but I am not sure how relevant it is to us.

In the military, you can say something like "information about the
movement of a platoon is only really important for a day or
so, while information about the movement of an entire army may be
sensitive for months, so we will use a much larger key size for army
movement messages than for platoon movement messages."

However, in the Internet, I do not think that we can make such
judgements, at least not at the protocol level. We don't have control
on how things are used.

What is the value of a packet, say one containing an email ? Consider
the recent Facebook IPO. There, an adversary's gain from inside
information might easily have been $ 1 billion or more. And, yet, it
is not common to use a more complicated  encryption modes to send an
email or hold a videoconference about a $16 billion IPO than for a
kid's birthday party. So, in practice, the adversary's expected gain
should always be regarded as infinite on the Internet. Likewise, the
time of sensitivity is effectively forever, at least for some packets,
which makes it effectively forever for all of them.

Regards
Marshall

>
> 5.       Moore’s Law continually decreases an adversary’s cost to attack a
> system. so we must assume that eventually all parameter sizes will need to
> be readjusted.
>
> infinity, almost anything is secure.  The art is in picking mechanisms and
> parameter sizes that meet our needs efficiently.
>
> 8.       We don’t exist in a vacuum.  We need to constantly monitor the
> produced by the cryptologic research community, and co-ordinate our efforts
> with other standards bodies.
>
>
>

---

From: Gé Weijers <[email-masked]>
Date: Wed, 23 May 2012 15:20:32 -0700

> 2.       Needless complexity is the enemy of security.

Even if the complexity is unavoidable: it's _still_ the enemy of security.

-- 
Gé

---

From: Vadym Fedyukovych <[email-masked]>
Date: Thu, 24 May 2012 08:03:39 +0300

> Even if the complexity is unavoidable: it's _still_ the enemy of security.

At the same time, complexity of computational Diffie-Hellman problem
often is the basis of security.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 24 May 2012 09:40:50 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vadym Fedyukovych
Sent: Thursday, May 24, 2012 1:04 AM
To: [email-masked]
Subject: Re: [Cfrg] Cryptographic meta-principles

Actually, we're talking about two aspects of "complexity":

- Kevin, Steve and Marshall are talking about complexity from the implementation's (the "good guys") point of view.  The idea here is that if you have a cryptographical system with a lot of moving parts, well, then there's a lot that can go wrong.  In contrast, a simple system is considerably easier to analyze to make sure that there wasn't anything we missed.  Remember, it is implementation mistakes, not cryptographical issues, that are far more likely to cause actual security problems

- You are talking about complexity from the attacker's (the "bad guys") point of view.  We don't mind at all making his job harder; in fact, that's rather the goal.

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 24 May 2012 12:51:55 -0400

> - Kevin, Steve and Marshall are talking about complexity from the implementation's (the "good guys") point of view.  The idea here is that if you have a cryptographical system with a lot of moving…

+<some large number>

(This is why I will be dubious about at least the first implementation
of quantum cryptography.)

Regards
Marshall

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 24 May 2012 12:52:13 -0400

Simply stated one is "computational complexity" and the other is "software/system complexity"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Thursday, May 24, 2012 12:41 PM
To: Vadym Fedyukovych; [email-masked]
Subject: Re: [Cfrg] Cryptographic meta-principles

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vadym Fedyukovych
Sent: Thursday, May 24, 2012 1:04 AM
To: [email-masked]
Subject: Re: [Cfrg] Cryptographic meta-principles

> Even if the complexity is unavoidable: it's _still_ the enemy of security.

At the same time, complexity of computational Diffie-Hellman problem often is the basis of security.