Re: more re Encryption Technology Limits Eased

[Steven M. Bellovin]

In message <[EMAIL PROTECTED]>, Declan McCullagh wr
ites:
> What I found most interesting was what Attorney General Reno said about the
> government's cryptanalysis abilities. When asked if she can break strong,
> >64 bit equivalent crypto, she said, "We have carefully looked at this and
> think it's possible," and declined to add details.
> 
> DoD's Hamre said that there would be a big chunk assigned to cryptanalysis
> R&D in DoD's requested FY2001 budget but added "some of the parts you may
> be interested [in] I can't discuss." (I wouldn't necessarily read much into
> this. It could simply be a face-saving move.)

This isn't at all improbable -- just do the math.

Deep Crack cost $250,000; it works against a 56-bit cipher.  Multiply that
by 256 and you get $64,000,000 -- hardly a preposterous increase in NSA's
budget.  Sure, they want faster results; they'll also have economies of
scale, processors faster than 40 Mhz, etc.

Re: Intel RNG

[Anonymous]

Bram writes:

> Paul Kocher has said the design looks sound, which I believe, but
> unforotunately the raw output of Intel's RNG just plain can't be accessed
> without it going through whitening first. Unsurprisingly, all the output
> passes all statistical tests. Well, duh, it's been sent through SHA-1. All
> that proves is that there's enough entropy in each block being hashed that
> none of them got repeated in the tests, and even a measly 20 bits are
> likely to do that.

Actually the data analyzed by Jun and Kocher was from _before_ the SHA-1
whitening.  Bram is correct that it would be meaningless to analyze the
output after SHA-1.  None of the statistical results which are reported
in Kocher's writeup are from after SHA-1 (as described in
http://www.cryptography.com/intelRNG.pdf):

: Because subtle output correlations are always a possibility, the
: verification process has included a wide array of statistical tests by
: Cryptography Research and by Intel. These tests are designed to detect
: nonrandom characteristics by comparing statistical distributions in
: large samples of actual RNG outputs against distributions expected from
: a perfect random source.
:
: Tests were performed both before and after the digital
: post-processing. Tests on pre-corrected data help to identify
: characteristics that might be difficult to detect after the correction
: process. All statistical tests were performed on data prior to the
: software library's SHA-1 mixing, as the SHA operation would mask
: nonrandom characteristics.

Bram asks:

> If Intel's RNG really is producing a reliable one bit of entropy per one
> bit of output, why don't they just make it accessible without whitening?

There are a number of reasonable possibilities for why Intel prefers to
provide the post-whitened output:

The main one is that they want people to access the chip via a standard
API which provides high quality random bits.  This is normal software
engineering practice.  It gives Intel freedom in the future to make
changes to the chip interface and accommodate them in the driver.  For
example, they could move the von Neumann bias remover into software if
they desired, and the change would be transparent to software which used
the chip.  Or perhaps they could go in the other direction and put some
kind of SHA-like whitener onto the chip in order to reduce the software
load.  Using a standard API for high quality random bits allows this
kind of design flexibility without concerns about breaking applications
which rely on the previous architecture.

They are also concerned, with the current architecture, that naive users
may use the output of the chip directly without passing it through the
software layers which are necessary to make it fully random.  Of course
most people would hopefully not be foolish enough to do this, but Intel
may be worried about liability issues if they publish the internal
interface to a "random number generator" which is not fully random.

Intel is probably also be motivated by profit.  Got to keep that stock
going up, you know.  Apparently they are charging a great deal of money
(six figures) for access to the RNG library.  If they openly published
the interface to the chip they would not be able to make this kind of
money off of their software driver.

Now, although these reasons are all valid to varying degrees, it is
likely that the interface will be published despite these concerns.
There is little that Intel can do to stop people from reverse
engineering their driver and publishing the interface (anonymously, if
necessary).  This issue will therefore probably be moot in a few months.

Re: more re Encryption Technology Limits Eased

[Declan McCullagh]

John,

I buttonholed William Reinsch, Commerce Dept undersecretary, outside the
White House briefing room a few minutes ago. I happened to ask him the same
question you bring up here: What's up with that one-time technical review?

Things were crowded and noisy, but here's what I learned. (The BXA regs are
still being drafted and are supposed to be published in the Federal
Register no later than December 15.)

Products <64 bit or equivalent are generally decontrolled except for:

1. Can't export to Cuba, Iran, Iraq, Libya, N.Korea, Sudan, Syria, and
2. A one-time technical review is STILL REQUIRED. That process is supposed
to take not more than a few months. According to Reinsch, such a review is
closest to your:
>or:*  BEFORE you post it, you have to send a copy to NSA -- AND THEN WAIT
>  until they say you can export it?

It's unclear to me whether they'll require source. DoD's Hamre simply said
it would have to be a "meaningful" review and said providing a product
brochure just isn't good enough.

Also, the regs differentiate between "retail" and "custom" products.
Reinsch: "There are differences in the way it will be treated." When asked
whether, say, shrinkwrapped software available at CompUSA would be
automatically treated as retail, Reinsch replied, "It's more complicated
than that."

Products >64bit or equivalent are still controlled under EAR but can be
exported through a license exception under these circumstances:

1. Feds get one-time technical review, and
2. You must file post-export reports with Commerce Dept, and
3. Can't export to Cuba, Iran, Iraq, Libya, N.Korea, Sudan, Syria, and

If the destination is a permissible foreign government or a state entity
such as a telecom firm, I believe you must also satisfy these conditions:

4. Product must not "require substantial support" (think technical
support), and
5. Product must be "sold in tangible form or have been specifically
designed for individual consumer use"

For each version of a new product (I gave Reinsch example of PGP 10.0.0.0
and 10.0.0.1), you have to submit it and wait for a new "one-time"
technical review.

Also, I asked Reinsch if "end users" include distributors such as computer
stores in foreign countries. He said yes, and that they're not trying to
pull a fast one.

What I found most interesting was what Attorney General Reno said about the
government's cryptanalysis abilities. When asked if she can break strong,
>64 bit equivalent crypto, she said, "We have carefully looked at this and
think it's possible," and declined to add details.

DoD's Hamre said that there would be a big chunk assigned to cryptanalysis
R&D in DoD's requested FY2001 budget but added "some of the parts you may
be interested [in] I can't discuss." (I wouldn't necessarily read much into
this. It could simply be a face-saving move.)

Finally, Reno indicated that this kind of cryptanalysis may not be enough
-- and legal requirements such as mandatory key escrow may be necessary.
She said:

"This legislation does not provide any new authority for law enforcement to
be able to obtain usable evidence from criminals. We will continue to
operate under our existing authorities and attempt to meet the threat of
the criminal use of encryption. We are hopeful that these existing
authorities will prove sufficient."

Here's hoping...

-Declan

More:
http://www.wired.com/news/news/politics/story/21790.html
http://www.wired.com/news/news/politics/story/21786.html

Re: BOUNCE dcsb@ai.mit.edu: Non-member submission from [JohnGilmore ]

[Robert Hettinga]

At 3:42 PM -0400 on 9/16/99, John Gilmore <[EMAIL PROTECTED]> wrote:


>> For Immediate Release
>> September 16, 1998
>> STATEMENT BY THE PRESS SECRETARY
>
> Robert, that was *last year*'s encryption policy "liberalization".

Tell me about it.

Sheesh.

I saw it fly by, and the old trigger finger just twitched before I 
saw the date.

So, we're still waiting, in other words...

Cheers,
RAH
-
Robert 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'

Ah. That's more like it...

[Robert Hettinga]

--- begin forwarded text


Date: 16 Sep 99 15:09:33 EDT
From: ROBERT HARPER <[EMAIL PROTECTED]>
To: Ignition Point <[EMAIL PROTECTED]>
Subject: IP: White House changes crypto policy!
Sender: [EMAIL PROTECTED]
Reply-To: ROBERT HARPER <[EMAIL PROTECTED]>

http://foxnews.com/

White House bows to pressure from high-tech industry over encryption
2.43 p.m. ET (1848 GMT) September 16, 1999

By Ted Bridis, Associated Press


WASHINGTON (AP) - The White House agreed Thursday to allow U.S.
companies to sell the most powerful data-scrambling technology
overseas with virtually no restrictions, a concession to America's
high-tech industry over law enforcement and national security
objections.

The move was a defeat for the Justice Department, which had forcefully
argued that criminals and terrorists might use the technology to
scramble messages about crimes or deadly plots.

On the other hand, the decision should help U.S. companies in overseas
competition - and help consumers worldwide guarantee the privacy of
their e-mail and online credit-card purchases.

Critics of restrictions on export sales said criminals and terrorists
already could buy or download powerful encryption technology made in
other countries.

"Those who are going to misuse encryption for criminal purchases aren't
going to limit themselves to U.S.-made encryption products,'' said
Ed Gillespie, executive director of Americans for Computer Privacy.

The administration will allow high-tech companies to sell even the
most powerful encryption technology overseas to private and commercial
customers after a one-time technical review of their products.

The White House will still require companies to seek permission to
sell the scrambling technology to a foreign government or military,
and it maintains bans on selling to seven terrorist nations: Iran,
Iraq, Libya, Syria, Sudan, North Korea and Cuba.

Previously, the administration allowed companies to sell the most
powerful scrambling technology only to specific industries overseas;
other foreign customers were generally limited to so-called 56-bit
encryption products, meaning those with 72-quadrillion unlocking
combinations.

"This is a sweeping reform,'' said Dan Scheinman, senior vice
president of legal and government affairs at Cisco Systems Inc. "
Imagine you're banking online - you want to make sure those things are
safe from a hacker. You buy things, you want to make sure your credit
card is secure.''

The export limits never directly affected Americans, who are legally
free to use encryption technology of any strength. But U.S. companies
have been reluctant to develop one version of their technology for
domestic use and a weaker overseas version, so they typically sell
only the most powerful type that's legal for export, even to Americans.

"Forcing U.S. companies to do business under tight export controls was
like asking them to use a black rotary telephone in a cellular, call-
waiting world,'' said Harris Miller, president of the Information
Technology Association of America, a trade group.

Critics cited more than 800 products available worldwide with stronger
scrambling technology than the United States allowed its companies to
sell overseas.

"You can pull it down over the Internet in less than 20 minutes,''
said Gillespie. "Having Japanese and German and Irish companies be at
the forefront of this technology is not in our best interests.''

A non-profit group of researchers demonstrated last summer it can
unscramble a 56-bit coded message in just days using a custom-built
computer worth less than $250,000.

The White House announcement follows its decision exactly one year ago
to relax export restrictions. At the time, Vice President Al Gore
promised the administration would reconsider its limits within the
year.


Get free email and a permanent address at http://www.netaddress.com/?N=1

**
To subscribe or unsubscribe, email:
  [EMAIL PROTECTED]
with the message:
  (un)subscribe ignition-point email@address
**

**

--- end forwarded text


-
Robert 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'

IP: Statement By The Press Secretary: Administration AnnouncesNew Approach to Encryption

[Robert Hettinga]

--- begin forwarded text


Date: Thu, 16 Sep 1999 15:32:09 -0400
To: [EMAIL PROTECTED]
From: David Farber <[EMAIL PROTECTED]>
Subject: IP: Statement By The Press Secretary: Administration Announces New
  Approach to Encryption
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]

>
>  THE WHITE HOUSE
>
>   Office of the Press Secretary
>___
> 
>For Immediate Release
>September 16, 1999
>
>
> STATEMENT BY THE PRESS SECRETARY
>
>Administration Announces New Approach to Encryption
>
> One year ago today, Vice President Gore announced updates to the
>Administration?s encryption policy to serve the full range of national
>interests: promoting electronic commerce, supporting law enforcement and
>national security, and protecting privacy.  The announcement permitted the
>export of strong encryption to protect sensitive information in the
>financial, health, medical, and electronic commerce sectors.  It also
>included support for the continued ability of the nation?s law enforcement
>community to access, under strictly defined legal procedures, the plain
>text of criminally related communications and stored information.  At that
>time the Administration committed to reviewing its policy in one year.
>Today, the Administration announces the results of that review, conducted
>in consultation with industry and privacy groups and the Congress.
>
> The strategy announced today continues to maintain the balance among
>privacy, commercial interests, public safety and national security.  This
>approach is comprised of three elements ? information security and privacy,
>a new framework for export controls, and updated tools for law enforcement.
>First, the strategy recognizes that sensitive electronic information ?
>government, commercial, and privacy information -- requires strong
>protection from unauthorized and unlawful access if the great promise of
>the electronic age is to be realized.  Second, it protects vital national
>security interests through an updated framework for encryption export
>controls that also recognizes growing demands in the global marketplace for
>strong encryption products.   Finally, it is designed to assure that, as
>strong encryption proliferates, law enforcement remains able to protect
>America and Americans in the physical world and in cyberspace.
>
> With respect to encryption export controls, the strategy announced
>today rests on three principles: a one-time technical review of encryption
>products in advance of sale, a streamlined post-export reporting system,
>and a process that permits the government to review the exports of strong
>encryption to foreign government and military organizations and to nations
>of concern.  Consistent with these principles, the government will
>significantly update and simplify export controls on encryption.
>
> The updated guidelines will allow U.S. companies new opportunities to
>sell their products to most end users in global markets.  Under this
>policy:
>
>?Any encryption commodity or software of any key length may be exported
> under license exception (i.e., without a license), after a technical
> review, to individuals, commercial firms, and other non-government end
> users in any country except for the seven state supporters of
> terrorism.
>
>?Any retail encryption commodities and software of any key length may
> be exported under license exception, after a technical review, to any
> end user in any country, except for the seven state supporters of
> terrorism.
>
>?Streamlined post-export reporting will provide government with an
> understanding of where strong encryption is being exported, while also
> reflecting industry business models and distribution channels.
>
>?Sector definitions and country lists are eliminated.
>
> The Administration intends to codify this new policy in export
>regulations by
>December 15, 1999, following consultations on the details with affected
>stakeholders.
>
>   In support of public safety, the President is today transmitting to the
>Congress legislation that seeks to assure that law enforcement has the
>legal tools, personnel, and equipment necessary to investigate crime in an
>encrypted world.  Specifically, the Cyberspace Electronic Security Act of
>1999 would:
>
>?  Ensure that law enforcement maintains its ability to access decryption
>   information stored with third parties, while protecting such information
>   from inappropriate release.
>
>?  Authorize $80 million over four years for the FBI?s Technical Support
>   Center, which will serve as a centralized technical resource for
>   Federal, State, and local law enforcement in responding to the
>   increasing use of encryption by criminals.
>
>?  Protect sensitive investigative techniques

Re: more re Encryption Technology Limits Eased

[Steve Cook]

When we got an export license for Stronghold earlier this year (don't ask),
the process consisted of filling out an application form listing the types
of encryption and ciphers supported, key sizes supported, etc., then
answering a few follow-up questions of that sort from some NSA staffer, and
then pestering them for 5 or 6 weeks until they provided a response. No
source code review. 

--Steve Cook

At 01:27 PM 9/16/99 -0700, Tom Weinstein wrote:
>John Gilmore wrote:
>> 
>> There's a vague and undefined term in the press leaks so far:
>> 
>> One-Time Technical Review
>> 
>> What does this mean?  It appeared in some early crypto liberalization
>> bills floated in Congressional committees.
>
>Based on my previous experience with the export process, here's what I think
>this means:
>
>  You have to tell the NSA what you're doing and let them think
>  about it for a while.  You'll have to answer any questions they
>  have, but they aren't likely to ask for source code.  It's not
>  something you want to do the week before you ship.  It's a process
>  that's likely to take a couple months and involve more than one
>  face to face meeting with NSA people.
>
>Of course it may mean something completely different.  I've been surprised by
>what the NSA does more often than not.


--
Steve Cook   e-mail: [EMAIL PROTECTED]
C2Net Software, Inc.   http://www.c2.net/
1440 Broadway, Suite 700fax: 510-986-8777
Oakland, CA 94612 USA  tel: 510-986-8770 Ext. 312

Re: more re Encryption Technology Limits Eased

[Tom Weinstein]

John Gilmore wrote:
> 
> There's a vague and undefined term in the press leaks so far:
> 
> One-Time Technical Review
> 
> What does this mean?  It appeared in some early crypto liberalization
> bills floated in Congressional committees.

Based on my previous experience with the export process, here's what I think
this means:

  You have to tell the NSA what you're doing and let them think
  about it for a while.  You'll have to answer any questions they
  have, but they aren't likely to ask for source code.  It's not
  something you want to do the week before you ship.  It's a process
  that's likely to take a couple months and involve more than one
  face to face meeting with NSA people.

Of course it may mean something completely different.  I've been surprised by
what the NSA does more often than not.

-- 
What is appropriate for the master is not appropriate| Tom Weinstein
for the novice.  You must understand Tao before  | [EMAIL PROTECTED]
transcending structure.  -- The Tao of Programming   |

Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[Scott G. Kelly]

Greg Broiles wrote:
> 
> > [MODERATOR's NOTE: I'm sorry, but I find this totally wrongheaded. A
> > 3DES ethernet card need not be "trusted" -- if the thing interoperates
> > with other IPSec implementations, its correct, pure and
> > simple. Indeed, the slightest flaw and it would not
> > interoperate. Perhaps they could rig it to leak too much in the RF
> > spectrum, but they could do that with the rest of the chipset, too,
> > and you are using *that*.
> 
> Which part of the IPSec standard would prevent the card from selecting
> key material from a restricted (and known) set of the keyspace, or from
> leaking information through a covert channel (which might include parts
> of other network packets, or timing of packets)?
> 

It's not the IPsec standard that would prevent the card from selecting
key material, it's the OS API.  The Windows 2000 offload spec (which
Intel says they support) runs the IKE as an (OS) application, and hands
the keys to the card/chip. I suppose that if a hardware RNG used by IKE
were compromised, though, then influencing half of the DH exponent would
be possible...

Can't argue with the notion of a covert channel, either. I guess if
you're in a position to be that paranoid, you'd better design your own
hardware, and stay away from commercial operating systems for which you
don't possess the source code.

Scott

Re: Administration Updates Encryption Policy

[John Gilmore]

> For Immediate Release
> September 16, 1998
> STATEMENT BY THE PRESS SECRETARY

Robert, that was *last year*'s encryption policy "liberalization".

Great joke though.  I read through four or five paragraphs before
it became too obvious.  Remember what they promised last year, and
what the regulations actually delivered -- as you read this year's
promises.

John

Re: more re Encryption Technology Limits Eased

[John Gilmore]

Dave Farber:
> As I said , the devil is in the details.

Let me agree.  Remember when the Administration said it was giving
industry what it wanted -- transferring crypto exports to the Commerce
Dept?  And when later "industry" worked out a deal so they could "easily"
export key-recovery products, only to discover that in the final regs 
and procedures it really wasn't so easy?

There's a vague and undefined term in the press leaks so far:

One-Time Technical Review

What does this mean?  It appeared in some early crypto liberalization
bills floated in Congressional committees.  Does it mean:

*  On the same day that you first put your encryption invention
   on your web site, you have to send a binary copy to the NSA?
or: *  BEFORE you post your encryption invention on your web site,
   you have to send a copy to NSA?
or: *  BEFORE you post it, you have to send a copy to NSA -- AND THEN WAIT
   until they say you can export it?
or: *  BEFORE you post it, you have to send the source code to NSA --
   and rather than a mere delay, they have the option to respond
   by telling you that you just can't export it?
or: *  You can't post it at all -- you need to provide details about
   each person who receives it, and you don't know that about the
   people who download it.
or: *  infinite variations

We'll only really know once the regulations are published, which is
rumored to be in a few months.

John

Administration Updates Encryption Policy

[Robert Hettinga]

--- begin forwarded text


Date: Thu, 16 Sep 1999 14:36:39 -0400
To: [EMAIL PROTECTED]
From: Hudson Barton <[EMAIL PROTECTED]>
Subject: Administration Updates Encryption Policy
Sender: <[EMAIL PROTECTED]>
List-Subscribe: 

Office of the Press Secretary


For Immediate Release
September 16, 1998
STATEMENT BY THE PRESS SECRETARY
Administration Updates Encryption Policy
The Clinton Administration today announced a series of steps to 
update its encryption policy in a way that meets the full range of 
national interests: promotes electronic commerce, supports law 
enforcement and national security and protects privacy. These steps 
are a result of several months of intensive dialogue between the 
government and U.S. industry, the law enforcement community and 
privacy groups that was called for by the Vice President and 
supported by members of Congress.
As the Vice President stated in a letter to Senator Daschle, the 
Administration remains committed to assuring that the nation's law 
enforcement community will be able to access, under strictly defined 
legal procedures, the plain text of criminally related communications 
and stored information. The Administration intends to support FBI's 
establishment of a technical support center to help build the 
technical capacity of law enforcement - Federal, State, and local - 
to stay abreast of advancing communications technology.
The Administration will also strengthen its support for electronic 
commerce by permitting the export of strong encryption when used to 
protect sensitive financial, health, medical, and business 
proprietary information in electronic form. The updated export policy 
will allow U.S. companies new opportunities to sell encryption 
products to almost 70 percent of the world's economy, including the 
European Union, the Caribbean and some Asian and South American 
countries. These changes in export policy were based on input from 
industry groups while being protective of national security and law 
enforcement interests.
The new export guidelines will permit exports to other industries 
beyond financial institutions, and further streamline exports of key 
recovery products and other recoverable encryption products. Exports 
to those end users and destination countries not addressed by today's 
announcement will continue to be reviewed on a case-by-case basis.
Very strong encryption with any key length (with or without key 
recovery) will now be permitted for export under license exception, 
to several industry sectors. For example, U.S. companies will be able 
to export very strong encryption for use between their headquarters 
and their foreign subsidiaries worldwide except the seven terrorist 
countries (Iran, Iraq, Libya, Syria, Sudan, North Korea and Cuba) to 
protect their sensitive company proprietary information.
On-line merchants in 45 countries will be able to use robust U.S. 
encryption products to protect their on-line electronic commerce 
transactions with their customers over the Internet.
Insurance companies as well as the health and medical sectors in 
those same 45 countries will be able to purchase and use robust U.S. 
encryption products to secure health and insurance data among 
legitimate users such as hospitals, health care professionals, 
patients, insurers and their customers.
The new guidelines also allow encryption hardware and software 
products with encryption strength up to 56-bit DES or equivalent to 
be exported without a license, after a one time technical review, to 
all users outside the seven terrorist countries. Currently, 
streamlined exports of DES products are permitted for those companies 
that have filed key recovery business plans. However, with the new 
guidelines, key recovery business plans will no longer be required.
The Administration will continue to promote the development of key 
recovery products by easing regulatory requirements. For the more 
than 60 companies which have submitted plans to develop and market 
key recovery encryption products, the six month progress reviews will 
no longer be required. Once the products are ready for market they 
can be exported, with any bit length -- without a license -- 
world-wide (except to terrorist nations) after a one-time review. 
Furthermore, exporters will no longer need to name or submit 
additional information on a key recovery agent prior to export. These 
requirements will be removed from the regulations.
Finally, industry has identified other so-called "recoverable" 
products and techniques that allow for the recovery of plaintext by a 
system or network administrator and that can also assist law 
enforcement access,subject to strict procedures. The administration 
will permit their export for use within most foreign commercial 
firms, and their wholly-owned subsidiaries, in large markets, 
including Western Europ

U.S. to loosen crypto rules

[Steven M. Bellovin]

Several newspapers have reported that the U.S. government will announce major 
changes in the crypto export rules.  See, for example, 
http://www.sjmercury.com/svtech/news/indepth/docs/enc091699.htm; there's also 
been coverage on zdnet and the Wall Street Journal.  I'll hold off posting 
details until after the official announcement, and remember that the devil is 
in the details -- according to the reports I've heard privately, the formal 
rules won't be out till December.  The main thing to watch for, in my opinion, 
is the criteria for the one-time review for exporting strong crypto.

--Steve Bellovin

Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[Greg Broiles]

> [MODERATOR's NOTE: I'm sorry, but I find this totally wrongheaded. A
> 3DES ethernet card need not be "trusted" -- if the thing interoperates
> with other IPSec implementations, its correct, pure and
> simple. Indeed, the slightest flaw and it would not
> interoperate. Perhaps they could rig it to leak too much in the RF
> spectrum, but they could do that with the rest of the chipset, too,
> and you are using *that*.

Which part of the IPSec standard would prevent the card from selecting
key material from a restricted (and known) set of the keyspace, or from
leaking information through a covert channel (which might include parts
of other network packets, or timing of packets)? 

> As for their RNG hardware, Paul Kocher was invited to look inside the
> Kimono and has published a full report on it, and he didn't find
> anything odd... --Perry]

If you're referring to the report at
, it seems that Paul got a
look at some data which supposedly came from inside the kimono - as the
report states, "For this review, Cryptography Research performed a
series of tests and evaluated the results of experiments performed by
Intel. Raw data and design specifications for the analysis were provided
by Intel." (section 4, page 3).

So, assuming we trust Intel, we've got a report which assures us we can
trust Intel. That helps protect against inadvertent design or
implementation flaws, but doesn't address intentional misbehavior.

--
Greg Broiles
[EMAIL PROTECTED]

Anyone looked at robustness of www.javacrypt.com ?

[Caspar Bowden]

> HOT TIP, I would like to announce a new invention of mine the "Secret
> Message Service". This is a free service delivered from my new web site
> at:
> www.javacrypt.com.
> 
> Also while browsing tech news sites to announce my new invetion I
> noticed that the
> hackertimes.com web site has been hacked. I this news?
> 
> Robert Taylor
> [EMAIL PROTECTED]
> www.javacrypt.com

Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[William H. Geiger III]

In <[EMAIL PROTECTED]>, on 09/16/99 
   at 09:20 AM, "William H. Geiger III" <[EMAIL PROTECTED]> said:

>As for their RNG hardware, Paul Kocher was invited to look inside the
>Kimono and has published a full report on it, and he didn't find anything
>odd... --Perry]

I read the report and I was less than impressed. They did not even bother
to test the RNG but was provided with data and design specs from Intel.
There has been considerable discusion on this topic on the CP list. I am
not willing to blindly trust Intel even if Paul and others are.

-- 
---
William H. Geiger III  http://www.openpgp.net
Geiger ConsultingCooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---

Intel RNG

[bram]

Perry Metzger wrote:

> As for their RNG hardware, Paul Kocher was invited to look inside the
> Kimono and has published a full report on it, and he didn't find
> anything odd...

Paul Kocher has said the design looks sound, which I believe, but
unforotunately the raw output of Intel's RNG just plain can't be accessed
without it going through whitening first. Unsurprisingly, all the output
passes all statistical tests. Well, duh, it's been sent through SHA-1. All
that proves is that there's enough entropy in each block being hashed that
none of them got repeated in the tests, and even a measly 20 bits are
likely to do that.

If Intel's RNG really is producing a reliable one bit of entropy per one
bit of output, why don't they just make it accessible without whitening?

Mind you, I don't think Intel's installed a back door with their RNG, I
just think it's likely that the raw output displays some subtle bias, and
they either knew about it or decided to just play it safe, and put the
whitening in.

-Bram

Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[Paul Crowley]

"William H. Geiger III" <[EMAIL PROTECTED]> writes:
> IMHO hardware based crypto is dangerous especially from a company like
> Intel that will not allow it's designs to be peer reviewed. Their entire
> attitude is "trust us we are Intel". Well  sorry I don't. Intel's RNG and
> now it's IPSEC accelerator are to ripe of a target for TLA's to trust
> without complete, open, peer review. Until this happens, IMHO, it is as
> trustworthy as CAPI.
> 
> [MODERATOR's NOTE: I'm sorry, but I find this totally wrongheaded. A
> 3DES ethernet card need not be "trusted" -- if the thing interoperates
> with other IPSec implementations, its correct, pure and
> simple. Indeed, the slightest flaw and it would not
> interoperate. Perhaps they could rig it to leak too much in the RF
> spectrum, but they could do that with the rest of the chipset, too,
> and you are using *that*.

If the thing has an RNG on board for any reason, that might not be
trusted, but I guess in practice it'll only use keys provided from
outside the card.  I suppose you could rig it to return the secret key 
in response to some secret "backdoor packet", but you'd be utterly
destroyed if you were caught, and you might well be caught.  It's not
as easy as introducing an "accidental" flaw in an RNG.

But if PCK has looked at their RNGs and thinks they're good then I
suspect they are.  I agree this is most likely a non-issue, I'm just
wondering what the theoretical possibilities are.
-- 
  __
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley  http://www.hedonism.demon.co.uk/paul/ /~\

Re: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[Eric Young]

John Gilmore wrote:
> raw data rate, since 10-20% is used by packet headers/trailers/interpacket
> spacing/etc.  And I've never seen software 3DES run at 32 Mbits/sec;
> what processor were they using?

On a pentium II 350, I get triple DES in cbc-ede mode doing 23.2
Mbits/sec
(Mbits == 1e6).  The DES cbc mode numbers are 65 Mbits/sec.

So doing the simple maths, I get a 482 mhz, or I'd say a pentium 2/3
500.

eric

[David Farber ] more re Encryption Technology Limits Eased

[Perry E. Metzger]

Forwarded from Dave Farber's IP mailing list.

-- 
Perry Metzger   [EMAIL PROTECTED]
--
"Ask not what your country can force other people to do for you..."
--- Start of forwarded message ---
Message-Id: 
Date: Thu, 16 Sep 1999 11:47:12 -0400
From: David Farber <[EMAIL PROTECTED]>
Subject: IP: more re Encryption Technology Limits Eased
Reply-To: [EMAIL PROTECTED]

>From: "Dave Wilson" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>
>
>I don't want to brag, but it was *first* reported by the San Jose Mercury
>News. Go to http://www.mercurynews.com for a complete report by Jonathan
>Rabinovitz.
>

As I said , the devil is in the details.  I just got off the phone 
with "a well placed person" who said point two , which could 
translate as key escrow, is not intended by the Administration to 
call for mandatory escrow. It is intended to get at places which 
maintain key escrow facilities like corporations  etc. I pointed out 
that in the course of debate in the Congress, someone will surely try 
for mandatory and he said "lets see what happens" I agree lets watch 
and be ready to stop it.

I got a strong impression that the credit for this one goes to the VP 
Gore for leading the parts of the Government   down a path they did 
not want to go. If so , well done!!

Wonder what the FBI will do with $80 m. Subcontract with NSA?

Dave


According to the official, the policy comprises three pillars:

*The administration will give $500 million to the Defense 
Department over the next several years to beef up its information 
security and to become a model for other government agencies and the 
private sector.

*Exporters of the strongest encryption products, which 
generally have keys of 128 bits or more, will no longer need to 
license each shipment. Instead, they will in most instances only need 
to have a one-time technical review of the product. However, the new 
policy will maintain the current ban on sending such products to 
states considered ``terrorist nations'' and will require a 
case-by-case review of sales of high-power custom encryption to 
foreign governments.

* Legislation will be proposed to Congress that will set up a 
system for law enforcement officials to go to court to get from third 
parties the keys that would open encrypted messages. Along with this 
proposal, the administration plans to set aside $80 million over the 
next four years to help the FBI improve its ability to crack codes.



--- End of forwarded message ---

DCSB: Gerald Gold; Internet Content -- Stories from the Front

[Robert Hettinga]

--- begin forwarded text


Date: Thu, 16 Sep 1999 08:24:58 -0400
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Robert Hettinga <[EMAIL PROTECTED]>
Subject: DCSB: Gerald Gold; Internet Content -- Stories from the Front
Cc: Gerald Gold <[EMAIL PROTECTED]>, Warren Agin <[EMAIL PROTECTED]>,
 Rodney Thayer <[EMAIL PROTECTED]>, Muni Savyon <[EMAIL PROTECTED]>,
 Elias Israel <[EMAIL PROTECTED]>, Suzan Dionne <[EMAIL PROTECTED]>
Sender: [EMAIL PROTECTED]
Reply-To: Robert Hettinga <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-

  The Digital Commerce Society of Boston

Presents

   Gerald Gold

 Vice President,
eCommerce Application Development
  Peanut Press

 Internet Content: Stories from the Front


 Tuesday, October 5th, 1999
12 - 2 PM
The Downtown Harvard Club of Boston
   One Federal Street, Boston, MA



Are people willing to spend money to download an electronic file that
contains the text of a novel?  Are book publishers willing to risk piracy
by offering their products in electronic format for sale via the web?
What does geography have to do with selling ebooks online?

Practical answers to these questions (and many others) had to be found
in order to build peanutpress.com: the world's premier provider of
ebooks from publishers' front lists, designed to be read on PDAs (such
as Palm connected organizers).

The discussion will focus on real world issues that surround the
interesting complexities of building an online store that creates,
sells, and delivers electronic books.


Gerald Gold has been working with text since he was a toddler.  From
about the age of two, the alphabet held a particular fascination.
Numbers weren't far behind; arithmetic and then logic soon occupied a
significant part of his daily thinking.  Since 1994 Gerald has been
developing web sites.

What better venue is there than programming for the World Wide Web in
which to share a passion for managing, manipulating, and
processing text and numbers?


This meeting of the Digital Commerce Society of Boston will be held
on Tuesday, October 5, 1999, from 12pm - 2pm at the Downtown Branch of
the Harvard Club of Boston, on One Federal Street. The price for
lunch is $35.00. This price includes lunch, room rental, various A/V
hardware, and the speakers' lunch.  The Harvard Club *does* have
dress code: jackets and ties for men (and no sneakers or jeans), and
"appropriate business attire" (whatever that means), for women.  Fair
warning: since we purchase these luncheons in advance, we will be
unable to refund the price of your lunch if the Club finds you in
violation of the dress code.


We need to receive a company check, or money order, (or, if we
*really* know you, a personal check) payable to "The Harvard Club of
Boston", by Saturday, September 2nd, or you won't be on the list for
lunch.  Checks payable to anyone else but The Harvard Club of Boston
will have to be sent back.

Checks should be sent to Robert Hettinga, 44 Farquhar Street, Boston,
Massachusetts, 02131. Again, they *must* be made payable to "The
Harvard Club of Boston", in the amount of $35.00. Please include your
e-mail address so that we can send you a confirmation

If anyone has questions, or has a problem with these arrangements
(We've had to work with glacial A/P departments more than once, for
instance), please let us know via e-mail, and we'll see if we can
work something out.

Upcoming speakers for DCSB are:

November   Warren AginSecured Internet Lending
December   Rodney Thayer  Cryptographic Transnationality
JanuaryElias Israel   The Libertarians and Digital Commerce
February   Suzan Dionne   The Law of Digital Cash


We are actively searching for future speakers.  If you are in Boston
on the first Tuesday of the month, and you are a principal in digital
commerce, and would like to make a presentation to the Society,
please send e-mail to the DCSB Program Committee, care of Robert
Hettinga, .


For more information about the Digital Commerce Society of Boston,
send "info dcsb" in the body of a message to  . If you want to subscribe to the DCSB e-mail
list, send "subscribe dcsb" in the body of a message to  .

We look forward to seeing you there!

Cheers,
Robert Hettinga
Moderator,
The Digital Commerce Society of Boston

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.1 for non-commercial use 

iQEVAwUBN+DhbMUCGwxmWcHhAQF8YAf/Q/jv2GUJeTfX4hhZKVoOJ/ZQZWiEjrEf
eX0fm90G2HJ+KqIoD7AxEEKOKkS95SUuX4WJrGWkLlyAUm24/isLXhaUizTRBmul
6XuqrSCf+4ijUpdwce9KyFVwqf9vqacg9C7NoDkMg0KBhv+/2uEaZsHKlm4SjBpi
BC6QUgDIIdTXQ/IJDpR4tRVszRtKxbS3wqmyV1N7LFKo8M519VgDhpJE8vUssCYv
W2e8/YFLcAVR1Z12tz8g+AH6x6s8rw8Kb243e9f4YwmEUr3NeUWpvm3NoesfKC7K
53QLf09seTJFI53fm3MP4L/OuZ68keIvm5tPKDC6GMFBi0jjzMQVhQ==
=ItL4
-END PGP SIGNATURE-
-
Robert A. Het

Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[William H. Geiger III]

In <[EMAIL PROTECTED]>, on 09/16/99 
   at 03:28 AM, John Gilmore <[EMAIL PROTECTED]> said:

>With the random number generator and now the IPSEC accelerator, Intel is
>really bidding to be the preferred hardware supplier for people who care
>about security.  Now if they'd only let us dump the braindead insecure
>Microsoft OS's, by publishing programming specs so we can access their
>security hardware from Linux and Unix, real servers running real loads
>could use their stuff.

Hi John,

I don't know if you still follow the CP list but we have been having a
long debate on the trustworthiness of Intel hardware, especially their
RNG.

IMHO hardware based crypto is dangerous especially from a company like
Intel that will not allow it's designs to be peer reviewed. Their entire
attitude is "trust us we are Intel". Well  sorry I don't. Intel's RNG and
now it's IPSEC accelerator are to ripe of a target for TLA's to trust
without complete, open, peer review. Until this happens, IMHO, it is as
trustworthy as CAPI.

[MODERATOR's NOTE: I'm sorry, but I find this totally wrongheaded. A
3DES ethernet card need not be "trusted" -- if the thing interoperates
with other IPSec implementations, its correct, pure and
simple. Indeed, the slightest flaw and it would not
interoperate. Perhaps they could rig it to leak too much in the RF
spectrum, but they could do that with the rest of the chipset, too,
and you are using *that*.

As for their RNG hardware, Paul Kocher was invited to look inside the
Kimono and has published a full report on it, and he didn't find
anything odd... --Perry]

-- 
---
William H. Geiger III  http://www.openpgp.net
Geiger ConsultingCooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---

Intel's new encryption chipset

[Udhay Shankar N]

Does anybody have more info on this ?

http://developer.intel.com/design/network/82559c.htm

Intel® 82559C Fast Ethernet Multifunction PCI CardBus Controller and the
Intel® 82594ED encryption co-processor provide an encryption chipset
that enables high-performance Internet Protocol Security (IPSec) designs
for desktop, mobile, and server platforms. The chipset when used with
the Microsoft Windows* 2000 operating system provides a significant
performance enhancement enabling platforms to deploy security without
sacrificing network performance. The 82559C combines an industry-leading
design that combines low-power and a small package with high-performance
and advanced manageability. 

-- 
 __ 
 http://www.unimobile.com/  http://pobox.com/~udhay  
  Unimobile -- Enabling the World Wide Wireless Web 
In Touch.  Informed.  In Control.

Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet

[John Gilmore]

On Wednesday Intel introduced a new LAN controller chip (82559C) and a
companion IPSEC coprocessor (82594ED) that reportedly runs 10/100 Mbit
Ethernet, full duplex, full speed, minimum packet gaps -- with 3DES
IPSEC encryption.  Windows 2K will supposedly have builtin support for
it.  See:

http://developer.intel.com/design/network/82559c.htm

The controller chip is "almost" compatible with their previous LAN
controllers, so minimal Linux driver rewriting will be needed to use
it.  I'm looking forward to getting technical information for the
encryption accelerator, so our Canadian programmers can build
FreeS/WAN support for it.  Assuming the programming interface is clean
and we can take good advantage of it, this should increase our already
acceptable 3DES performance on common processors from several megabits
to almost a hundred megabits per second.

More info is at:

http://www.intel.com/network/challenges/security.htm

There's a chart in one of the IPSEC white papers there that shows
Windows 2000 running 98 Mbits/sec without encryption, 32 Mbits/sec with
software 3DES, and 72 Mbits/sec with the accelerator.  (These numbers
all look bogus to me -- you can't push 98 mbit/sec through a
100mbit/sec Ethernet, unless you run it full duplex at a 200 mbit/sec
raw data rate, since 10-20% is used by packet headers/trailers/interpacket
spacing/etc.  And I've never seen software 3DES run at 32 Mbits/sec;
what processor were they using?  The same white paper also incorrectly
says 168-bit encryption is "the highest level allowed commercially by law"!)

The product is currently only available in the US, Canada and Puerto
Rico, due to US export controls.  Still, Intel believed that was a big
enough market to make it worth doing, and I think they're right.

My guess is that if Hugh and I hadn't made enough stink about DES
insecurity, and forced the issue of making 3DES the standard cipher
for IPSEC, this chip would've come out supporting single DES rather
than triple DES.  As I tried to explain at the time FreeS/WAN
desupported DES, in the long run this protocol will all be done in
circuitry, so why sacrifice long-term security for a short-term
performance advantage.  The long run has come sooner than even I
expected.

With the random number generator and now the IPSEC accelerator, Intel
is really bidding to be the preferred hardware supplier for people who
care about security.  Now if they'd only let us dump the braindead
insecure Microsoft OS's, by publishing programming specs so we can
access their security hardware from Linux and Unix, real servers
running real loads could use their stuff.

John