Re: NSA Suite B Cryptography

2005-10-17 Thread Alexander Klimov
On Fri, 14 Oct 2005, Sidney Markowitz wrote:
> Does this prevent free software interoperability with Suite B standards?
> It potentially could be used to block non-US vendors, certainly anyone
> who is in the US Government's disfavor, but it seems to me that even
> with no further intentional action by the NSA it would preclude software
> under the GPL and maybe FOSS in general in countries in which the
> patents are valid.

Since it turns out that ECDH and ECDSA with EC(GF_p) (even with point
compression) are not patented the following can be considered as
pro-FOSS:

  All implementations of Suite B must, at a minimum, include AES with
  128-bit keys, the 256-bit prime modulus elliptic curve and SHA-256
  as a common mode for widespread interoperability. [...] ECDH is
  appropriate for incorporation of Suite B into many existing Internet
  protocols such as the Internet Key Exchange (IKE), Transport Layer
  Security (TLS), and Secure MIME (S/MIME).

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-15 Thread Steven M. Bellovin
In message <[EMAIL PROTECTED]>, Sidney Markowitz writes:
>
>The possible twist that I see is if the NSA declares that any freely
>available open source software that interoperates with Suite B is by
>definition "in support of US national security interests" and therefore
>automatically gets one of their sublicenses. That would effectively
>remove the patent encumbrance for GPL code. There would still be patent
>restrictions on the code, but they would not apply to open source freely
>redistributable code, therefore would not get in the way of the GPL.

I strongly suspect that Certicom would sue if NSA tried that.

>So it still comes down to what I think is the important point: BSD
>licensed Suite B code may be possible, GPL'd Suite B code is not
>possible unless Certicom makes appropriate free license to the patents
>available for software licensed under GPL.
>
I think that that's a fair summary.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-15 Thread Sidney Markowitz
Joseph Ashwood wrote:
> U, no. The NSA only licensed the right to use (and sublicense under 
> special circumstances) the patents
[...]
> [snip the rest, it was based on a failed assumption]

Poor phrasing on my part. Exactly as you said, the patent sublicense
cannot be passed on even if the code is released under, say a BSD
copyright license. People would have a right to copy the source code but
would have to obtain patent rights either from the NSA if they are
eligible, or as you said under alternative arrangements from Certicom.

Since the GPL excludes distribution of code with patents that limit
their distribution other than by specific country, the patent
encumbrance that would accompany the code would prevent it from being
released under GPL.

The possible twist that I see is if the NSA declares that any freely
available open source software that interoperates with Suite B is by
definition "in support of US national security interests" and therefore
automatically gets one of their sublicenses. That would effectively
remove the patent encumbrance for GPL code. There would still be patent
restrictions on the code, but they would not apply to open source freely
redistributable code, therefore would not get in the way of the GPL.

Oh, no, that would not be strictly true. GPL allows you to do anything
at all with the code if you use it for yourself without distributing it.
Patent restrictions still apply to such uses. They could be uses that
are not "in support of US national security interests". Therefore you
still could not distribute the code under GPL as the people you give it
to would not have the patent rights to modify the code for their own
private modified use if they do not distribute the changes.

So it still comes down to what I think is the important point: BSD
licensed Suite B code may be possible, GPL'd Suite B code is not
possible unless Certicom makes appropriate free license to the patents
available for software licensed under GPL.

 -- Sidney Markowitz
http://www.sidney.com



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Joseph Ashwood
- Original Message - 
From: "Sidney Markowitz" <[EMAIL PROTECTED]>

Subject: Re: NSA Suite B Cryptography



Ian G wrote:

Which is to say, NSA solved its problem and it
is nothing to do with FOSS.


If you wrote a Suite B program and distributed it under a BSD license
after getting a sub-license for the patent from the NSA, presumably I
could take that code, modify it, and then in order to use or distribute
my modified code I would have to obtain my own sublicense from the NSA.


U, no. The NSA only licensed the right to use (and sublicense under 
special circumstances) the patents, they did not purchase the patents, and 
they do not have exclusive rights to them. You would have to negotiate with 
Certicom, the NSA would only be an alternative licensing agency under 
special circumstance.


[snip the rest, it was based on a failed assumption]
   Joe 




-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Sidney Markowitz
Ian G wrote:
> Which is to say, NSA solved its problem and it
> is nothing to do with FOSS.

If you wrote a Suite B program and distributed it under a BSD license
after getting a sub-license for the patent from the NSA, presumably I
could take that code, modify it, and then in order to use or distribute
 my modified code I would have to obtain my own sublicense from the NSA.

I could do that as long as I met whatever criteria the NSA has for
granting sublicenses. My guess is that at a minimum the program would
have to be available for free or for sale to the US government for some
purpose that allows it to be considered as being "in support of US
national security interests."

It would make no sense for the NSA to grant a sublicense to you that
allowed to you grant me a license to produce possibly proprietary code
that infringes the patent and is not in support of US national security
interests.

So, yes, under those assumptions BSD-like licenses would not be
excluded, with the understanding that in addition to the copyright terms
allowing free use of the code there would also be patent restrictions
affecting the use.

As you say, the NSA's solution to their problem has nothing to do with
FOSS, and it doesn't specifically exclude FOSS. But it will preclude GPL
software that will interoperate with Suite B from being distributed in
countries that recognize the patents.

Unless, I suppose the NSA is able to say that any use of the patent in
open source software can be considered "in support of US national
security interests" and therefore the sublicense can be propagated as
long as the source remains available. In other words, if they include a
GPL-like provision that the patent license will stay with the code as
long as it is distributed under GPL. That would be an interesting twist.

 -- Sidney Markowitz
http://www.sidney.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Sidney Markowitz
Ben Laurie wrote:
> Incidentally, why the focus on GPL?

Because the NSA's assurances that their license would cover open source
software is probably good enough to allow you to write and contribute
code to a non-GPL open source project if they do not have specific rules
against accepting patent-encumbered code, but the GPL has these two
sections regarding patents. I interpret them as meaning that the only
patent restriction there may be on GPL'd code is that it may not be
distributed in certain countries, but _any_ other restriction makes the
code not distributable under GPL.

[begin quote]
7.  If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot distribute
so as to satisfy simultaneously your obligations under this License and
any other pertinent obligations, then as a consequence you may not
distribute the Program at all. For example, if a patent license would
not permit royalty-free redistribution of the Program by all those who
receive copies directly or indirectly through you, then the only way you
could satisfy both it and this License would be to refrain entirely from
distribution of the Program.

If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.

It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is implemented
by public license practices. Many people have made generous
contributions to the wide range of software distributed through that
system in reliance on consistent application of that system; it is up to
the author/donor to decide if he or she is willing to distribute
software through any other system and a licensee cannot impose that choice.

This section is intended to make thoroughly clear what is believed to be
a consequence of the rest of this License.

8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License may
add an explicit geographical distribution limitation excluding those
countries, so that distribution is permitted only in or among countries
not thus excluded. In such case, this License incorporates the
limitation as if written in the body of this License.
[end quote]


 -- Sidney Markowitz
http://www.sidney.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Alexander Klimov
On Fri, 14 Oct 2005, Steven M. Bellovin wrote:
> Precisely.  NSA's actions here are independent of whether or not they
> like open source software on other criteria.  They've determined that
> ECC presents a better cost-benefit tradeoff.  We all understand, I
> think, why they're not enamored with 1024-bit RSA.  Doubling the key
> size means a ~8x performance hit for the signer and 4x for the
> verifier; they need to worry about embedded devices such as secure
> phones, sensors, and things like smart landmines.

I guess that for common people there is no real problem with RSA in
next twenty years:
 * according to NIST [1] RSA-1024 is OK through 2010 and RSA-2048 is
   OK through 2030;
 * even now it takes only about 30 ms for an RSA-2048 decryption /
   signing on a PC [2] and the performance of mobiles is in the same
   range (~100 ms) due to dedicated coprocessors;
 * in most modern applications 256 bytes is not an issue.

Unfortunately, for Top Secret traffic they need 192-bit security that
is RSA-7680 [1] and so they want ECC *right now*.


[1] Recommendation for Key Management -- Part 1: General
NIST Special Publication 800-57
http://csrc.nist.gov/CryptoToolkit/kms/SP800-57Part1August2005.pdf

[2] Crypto++ 5.2.1 Benchmarks
http://www.eskimo.com/~weidai/benchmarks.html
-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Steven M. Bellovin
In message <[EMAIL PROTECTED]>, Ian G writes:

>
>Which is to say, NSA solved its problem and it
>is nothing to do with FOSS.
>

Precisely.  NSA's actions here are independent of whether or not they 
like open source software on other criteria.  They've determined that 
ECC presents a better cost-benefit tradeoff.  We all understand, I 
think, why they're not enamored with 1024-bit RSA.  Doubling the key 
size means a ~8x performance hit for the signer and 4x for the 
verifier; they need to worry about embedded devices such as secure 
phones, sensors, and things like smart landmines.

Besides, they may feel that open source software isn't trustworthy 
enough to get near keys.  NSA isn't fond of software crypto to start 
with, though they're trying to adapt to it.  But they are very 
concerned about development methodology -- note the part about
'Testing, Evaluation and Certification of "Suite B" Products'.  (For
that matter, I'm also getting increasingly concerned about open source
development methodologies.  That, however, is a separate issue; if/when 
I write up something coherent, I'll post a pointer here.)

To me, the really interesting thing about that announcement was NSA's 
endorsement of certain algorithms and sizes.  It states that you can 
protect Top Secret traffic with 192-bit AES, 384-bit ECC DSA, and 
SHA-384.  Those numbers, especially the latter, are lower than I'd have 
guessed.  Note that the web page we're discussing is from Feb 2005, 
*after* Wang et al had successfully attacked MD5, though before the 
publication of their SHA-1 results.  NSA still has enough confidence in 
SHA-384 to rate it for Top Secret traffic.  I wonder what they're going 
to say at the Halloween Hash Bash

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Ian G

Sidney Markowitz wrote:

Excerpt from


"Fact Sheet on NSA Suite B Cryptography"
http://www.nsa.gov/ia/industry/crypto_suite_b.cfm



"NSA has determined that beyond the 1024-bit public key cryptography in
common use today, rather than increase key sizes beyond 1024-bits, a
switch to elliptic curve technology is warranted. In order to facilitate
adoption of Suite B by industry, NSA has licensed the rights to 26
patents held by Certicom Inc. covering a variety of elliptic curve
technology. Under the license, NSA has a right to sublicense vendors
building equipment or components in support of US national security
interests."

Does this prevent free software interoperability with Suite B standards?
It potentially could be used to block non-US vendors, certainly anyone
who is in the US Government's disfavor, but it seems to me that even
with no further intentional action by the NSA it would preclude software
under the GPL and maybe FOSS in general in countries in which the
patents are valid.


I didn't read it that way at all.  AFAICS,
the NSA has acquired the licences it needs
to deliver (have delivered) software to its
government customers.  As all the government
customers will need to use approved software
anyway, it will be acquired on some approved
list, and the licences will be automatically
extended.

Anyone outside the "national security" market
will need to negotiate separately with Certicom
if they need to use it.  This represents a big
subsidy to Certicom, but as they are a Canadian
company it is harder to argue against on purely
statist grounds.

Which is to say, NSA solved its problem and it
is nothing to do with FOSS.

The big question (to me perhaps) is where and
how far the Certicom patents are granted.  If
they are widely granted across the world then
the software standards won't spread as there
won't be enough of an initial free market to
make it bloom (like happened to RSA).  But if
for example they are not granted in Europe
then Europeans will get the free ride on NSA
DD and this will cause the package to become
widespread, which will create the market in
the US.  Of course predicting the future is
tough...

iang

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Ben Laurie

Sidney Markowitz wrote:

Excerpt from


"Fact Sheet on NSA Suite B Cryptography"
http://www.nsa.gov/ia/industry/crypto_suite_b.cfm



"NSA has determined that beyond the 1024-bit public key cryptography in
common use today, rather than increase key sizes beyond 1024-bits, a
switch to elliptic curve technology is warranted. In order to facilitate
adoption of Suite B by industry, NSA has licensed the rights to 26
patents held by Certicom Inc. covering a variety of elliptic curve
technology. Under the license, NSA has a right to sublicense vendors
building equipment or components in support of US national security
interests."

Does this prevent free software interoperability with Suite B standards?
It potentially could be used to block non-US vendors, certainly anyone
who is in the US Government's disfavor, but it seems to me that even
with no further intentional action by the NSA it would preclude software
under the GPL and maybe FOSS in general in countries in which the
patents are valid.


When questioned about this at IETF (the NSA presented on this stuff) 
they said that the licence they had purchased would cover open source 
s/w. But yes, it could be that the NSA has to approve of the particular 
piece of s/w.


Incidentally, why the focus on GPL?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]


Re: NSA Suite B Cryptography

2005-10-14 Thread Sidney Markowitz
Excerpt from
> "Fact Sheet on NSA Suite B Cryptography"
> http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

"NSA has determined that beyond the 1024-bit public key cryptography in
common use today, rather than increase key sizes beyond 1024-bits, a
switch to elliptic curve technology is warranted. In order to facilitate
adoption of Suite B by industry, NSA has licensed the rights to 26
patents held by Certicom Inc. covering a variety of elliptic curve
technology. Under the license, NSA has a right to sublicense vendors
building equipment or components in support of US national security
interests."

Does this prevent free software interoperability with Suite B standards?
It potentially could be used to block non-US vendors, certainly anyone
who is in the US Government's disfavor, but it seems to me that even
with no further intentional action by the NSA it would preclude software
under the GPL and maybe FOSS in general in countries in which the
patents are valid.

 -- Sidney Markowitz
http://www.sidney.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]