Re: NSA Suite B Cryptography

[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]

mixing authentication and identification?

[Anne & Lynn Wheeler]

FFIEC Guidance; Authentication in an Internet Banking Environment
http://www.fdic.gov/news/news/financial/2005/fil10305.html

The Federal Financial Institutions Examination Council (FFIEC) has
issued the attached guidance, “Authentication in an Internet Banking
Environment.” For banks offering Internet-based financial services, the
guidance describes enhanced authentication methods that regulators
expect banks to use when authenticating the identity of customers using
the on-line products and services. Examiners will review this area to
determine a financial institution’s progress in complying with this
guidance during upcoming examinations. Financial Institutions will be
expected to achieve compliance with the guidance no later than year-end
2006.

... snip ..

and some comments from some other thread:
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance

and ...

Uncle Sam Comes Knocking
http://www.banktechnews.com/article.html?id=20051003PV1B6000

The U.S. government's interest in having banks help it form networks of
federated identity, thus allowing vetted, shared user-credentials
between government and private industry, is obvious. So far, only four
banks-Wells Fargo, Wachovia, National City and an unidentified bank-have
signed on, though more are expected to join Uncle Sam's E-Authentication
Federation. The looming question: What's in it for banks?

... snip ...

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

Re: US Banks: Training the next generation of phishing victims

[Amir Herzberg]

I probably wasted more time than anybody on this crazy topic, and in 
particular:
1. I keep `Hall of Shame` site of such unprotected login pages (even got 
me a DigiCrime title:  Inter-Net Fraud League Commissioner!)
2. With others, we develop TrustBar, an improved security indicator 
toolbar for FireFox, which also tries to protect users of unprotected 
login pages, e.g. by automatically redirecting to protected pages when 
found.


Some results/observations:
1. Few companies that had a dialog with me said their marketing/site 
design folks insist on login via the homepage, claiming this is so much 
better for consumers compared to a separate login page. I see this as a 
very very extreme case of `usability beats security`.
2. Same companies also claimed that using SSL on homepage is too much 
overhead. Extreme case of `performance beats security`.
3. One company responded (to my warning of their unprotected login and 
the fact I'm going to add them to `hall of shame`) by legal threats. 
Typical case of `pay lawyers a lot, to avoid doing things right`.

4. One company sent me coupons for free trades. Rare example, I'm afraid...

--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: 
http://AmirHerzberg.com/TrustBar
Visit my Hall Of Shame of Unprotected Login pages: 
http://AmirHerzberg.com/shame


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

Re: NSA Suite B Cryptography

[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

[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]

[Clips] Lloyds steps up online security (SecureID)

[R.A. Hettinga]

--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Fri, 14 Oct 2005 10:44:32 -0400
 To: Philodox Clips List <[EMAIL PROTECTED]>
 From: "R.A. Hettinga" <[EMAIL PROTECTED]>
 Subject: [Clips] Lloyds steps up online security (SecureID)
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]

 

 The BBC

 Friday, 14 October 2005, 10:46 GMT 11:46 UK

 Lloyds steps up online security

 Lloyds TSB is to trial a new security system for online banking customers,
 in an attempt to beat internet fraud.

 About 30,000 customers will receive keyring-sized security devices, which
 generate a six-digit code to be used alongside usernames and passwords.

 The code, which changes every 30 seconds, could help fight fraudsters who
 hack people's PCs or use "phishing" emails to steal login details.

 Similar systems are already in use in Asia, Scandinavia and Australia.

 Password sniffers

 Until now, Lloyds TSB has used a two-stage system for identifying its
 customers.

 First, users must enter a username and password. Then, on a second screen,
 they are asked to use drop-down menus to choose three letters from a
 self-chosen memorable piece of information.

 The aim of using menus rather than the keyboard has been to defeat
 so-called "keyloggers", tiny bits of software which can be used by hackers
 who have breached a PC's security to read every key pressed and thus sniff
 out passwords.

  "There's no hiding the fact that fraud is on the increase"
 Matthew Timms, Lloyds TSB


 But newer keyloggers now also take screenshots, which can reveal the entire
 memorable word after the bank's website has been used just a few times.

 Alternatively, fraudsters use "phishing" emails, which tempt customers to
 log onto a fake banking website and enter their details.

 Lloyds says that about £12m was lost to this kind of scam in 2004 - but it
 warns that attacks are multiplying fast.

 One-time deal

 The bank says it is guaranteeing that they will not suffer from losses even
 if their PCs are compromised, as long as they have not - for instance -
 given their password away intentionally.

 This stance contrasts with warnings from some other banks - notably HSBC -
 that in future customers could be held responsible if they do not keep
 security up to date on their machines.

 But Lloyds also hopes that its trial system could effectively toughen up
 customer access - regardless of the state of their computer.

 The customers testing Lloyds TSB's new system will press a button on their
 device to generate a new six-digit number every time they log on.

 They will do the same every time they need to confirm a transaction,
 instead of simply repeating their password.

 Lloyds TSB hopes the move will mean keyloggers and phishing emails will not
 have time to use any details they collect.

 "Fraudsters are becoming increasingly cunning with their tactics, and
 there's no hiding the fact that fraud is on the increase," said Matthew
 Timms, Lloyds TSB's internet banking director.

 Other banks are trying different devices, and Mr Timms acknowledged that
 the keyring-style token would probably not be the final format.

 "The journey we're on will probably end up as a card which can do both
 internet banking and card-not-present (credit card) transactions," he said.



 --
 -
 R. A. Hettinga 
 The Internet Bearer Underwriting Corporation 
 44 Farquhar Street, Boston, MA 02131 USA
 "... however it may deserve respect for its usefulness and antiquity,
 [predicting the end of the world] has not been found agreeable to
 experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
 ___
 Clips mailing list
 [EMAIL PROTECTED]
 http://www.philodox.com/mailman/listinfo/clips

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

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

Re: NSA Suite B Cryptography

[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

[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

[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

[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

[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]

[ANNOUNCE] OpenSSL version 0.9.7i released

[Richard Levitte - VMS Whacker]

   OpenSSL version 0.9.7i released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   OpenSSL 0.9.7h caused crashes when the shared libcrypto was
   upgraded.  This release fixes that problem.  For those who want
   or have to stay with the 0.9.7 series of OpenSSL instead of using
   the 0.9.8 series, we strongly recommend that you upgrade to OpenSSL
   0.9.7h soon as possible.  For a complete list of changes, please
   see http://www.openssl.org/source/exp/CHANGES.

   OpenSSL 0.9.7i is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors
   under http://www.openssl.org/source/mirror.html):

 * http://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file names are:

 * openssl-0.9.7i.tar.gz
   MD5 checksum: f69d82b206ff8bff9d0e721f97380b9e
   SHA1 checksum: 4c23925744d43272fa19615454da44e01465eb06

   The checksums were calculated using the following commands:

openssl md5 openssl-0.9.*.tar.gz
openssl sha1 openssl-0.9.*.tar.gz

   Yours,

   The OpenSSL Project Team...

Mark J. Cox Nils Larsch Ulf Möller
Ralf S. Engelschall Ben Laurie  Andy Polyakov
Dr. Stephen Henson  Richard Levitte Geoff Thorpe
Lutz JänickeBodo Möller



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