SSO (was Re: biometrics)

[Marc Branchaud]

Dan Geer wrote:
> 
> 
> >   In the article they repeat the recommendation that you never
> >   use/register the same shared-secret in different domains
> 
> Compare and contrast, please, with the market's overwhelming
> desire for single-sign-on (SSO).  Put differently, would the
> actual emergence of an actual SSO signal a market failure by
> the above analysis?

In most SSO schemes, the password is only used to authenticate to a single
domain, and (a token attesting to) the fact that the authentication succeded
is passed around to other domains.  The authenticating domain is typically
akin to the user's "home" domain (as opposed to the user just logging into
some arbitrary domain) so the password isn't widely shared.  Most of these
schemes are web-based, and users that first surf to a non-home domain are
redirected (as tranparently as possible) to their local domain for
authentication, and something like an authentication "ticket" is encoded in a
cookie or in a return-redirecting URL.

M.

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

CertCo Patent Suit Delays PayPal IPO

[R. A. Hettinga]

http://www0.mercurycenter.com/business/top/024186.htm

Suit delays eagerly awaited IPO

Posted at 7:05 p.m. PST Wednesday, Feb. 6, 2002
BY DEBORAH LOHSE

Mercury News


PayPal's hotly anticipated initial public offering was delayed this week
after the online payment company was sued over alleged patent infringement.

New York online risk-management company CertCo claimed in a lawsuit filed
Monday in federal court in Delaware that PayPal was violating CertCo's
patent covering electronic payments.

Palo Alto-based PayPal was slated Wednesday night to set a pre-trading
price for 5.4 million shares of its stock, or about 9 percent of the
company's outstanding shares. The expected price range was $12 to $14 a
share. The stock would have begun trading today on the Nasdaq stock market,
using the symbol PYPL.

Despite having racked up $277 million in losses over two years, PayPal had
been generating a great deal of buzz among investors due to its rapid
growth in customers and revenue. Investors had been expected to
significantly bid up shares of PayPal, perhaps making it the first time a
profitless Internet company has popped since the Internet bubble burst in
2000 and burned many investors.

But bankers and PayPal management made the decision Wednesday to hold the
deal, possibly to allow PayPal time to amend its securities documents to
fully disclose the lawsuit to potential investors. A new date for the IPO
hasn't been set.

The lawsuit alleges that the payment and transaction system PayPal uses to
enable customers to send and receive payments electronically violates a
Feb. 2000 patent secured by CertCo, a privately held company.

PayPal's spokesman, Vincent Sollitto, said he couldn't comment on the
lawsuit because of a ``quiet period'' imposed by the Securities and
Exchange Commission on comments before or after an IPO.

Dale Lazar, a lawyer with Pillsbury Winthrop in McLean, Va., who represents
CertCo, said the patent entails a CertCo technology using certain
electronic signals to represent a payment request. ``Our patent covers the
heart of the PayPal payment system,'' he said.

PayPal's SEC IPO document says the company believes it has unique
technology for ``transferring value'' among customers; for detecting fraud,
and for obtaining alternate funding sources if a primary source isn't
available. The company is seeking five patents covering such proprietary
technology, it said.

But the boilerplate risk language in the prospectus reveals the potential
for lawsuits like CertCo's. ``We cannot assure you that our product
features do not infringe on patents held by others or that they will not in
the future.''


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

[ISN] Hacker costs CryptoLogic US$1.3M charge

[R. A. Hettinga]

--- begin forwarded text


Status:  U
Date: Thu, 7 Feb 2002 01:02:16 -0600 (CST)
From: InfoSec News <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [ISN] Hacker costs CryptoLogic US$1.3M charge
Sender: [EMAIL PROTECTED]
Reply-To: InfoSec News <[EMAIL PROTECTED]>

http://www.canada.com/news/story.asp?id={9BAF2BB1-87C1-4725-AF77-9881D5B89E1D}

[This has to be one of the first times I have seen a corporation
listing a hacker attack as a loss on their financial statement.
$1.3 million is no chump change today, all the managers on this list
looking for additional $$$ in their infosec budget should be pointing
this article out when the powers that be think that something like
this will never happen to their company, and that the V.P's really
should have new Herman Miller chairs instead.  - WK]


Paul Vieira
National Post
Tuesday, February 05, 2002

CryptoLogic Inc., a gambling software maker, saw its fourth-quarter
profit drop 10%, largely because it took a charge related to a hacker
attack last August that saw 140 online gamblers pocket winnings of
about US$1.9-million.

The company, in a conference call with analysts yesterday, said it
hopes to recover a good chunk of the illicit gains through an
insurance claim. Nevertheless, it is taking a US$1.3-million charge.
"A prudent approach was necessary," said Jean Nolting, CryptoLogic's
chief executive.

In the span of a couple of hours, a computer hacker broke into
CryptoLogic's Web servers and reprogrammed slot machines and a craps
table at two Web-based casinos that use the company's software.

Slot machine and craps players at the casinos won each time they
played.

The charge pulled down profit for the three-month period ended Dec. 31
to US$3.7-million, or US28¢ a share, from US$4.1-million (US29¢).
Meanwhile, revenue for the quarter increased 15%, to US$11.2-million
from $9.7-million.

Despite the fourth-quarter charge, the company posted higher profit in
2001. For the full fiscal year, CryptoLogic earned US$18.1-million
(US$1.33) on revenue of US$43.5-million, compared with $15.5-million
(US$1.18) on sales of US$34.4-million.

Excluding the writeoff, profit would have been US$4.2-million for the
fourth quarter and US$18.6-million for the year, the company said.

Also, the Toronto firm said it posted profit margin of 45% and has
US$60-million in cash as of the end of 2001.

During its call with analysts, Mr. Nolting said 2002 had the makings
of a "profitable year, with solidly upside potential," especially in
the second half.

For this fiscal year, the company forecasts revenue of US$45-million
to US$50-million and profit between US$17-million and US$20-million.

It expects to hit the "bottom" of the growth curve in the first
quarter.

However, CryptoLogic said U.S. banks' refusal to accept credit card
charges from online gambling sites could hinder growth prospects in
North America. Credit card rejections in the United States jumped 25%
in December as anti-terrorism efforts and the uncertain legality of
online gambling in North America cast a chill over U.S. banks.

Therefore, the company said, it will be examining offshore markets.
"Europe and Asia -- those will be our key areas," Mr. Nolting said.

By the end of the year, it wants half of its revenue to come from
Europe and Asia, the rest from North America. About 65% of its sales
now come from North America.

A key part of its foreign focus will be an online casino to be
operated by Littlewoods, a British-based gambling operator. However,
the launch of Littlewoods.com has been delayed as regulators in the
Isle of Man, where the online casino will be incorporated, want more
information about the software.

But Mr. Nolting said he expected Littlewoods to be in operation by the
end of the first quarter, and to generate up to 10% of total revenue.

Growth in 2002 will also be aided by the release of online versions of
bingo and poker that the company has been developing.



-
ISN is currently hosted by Attrition.org

To unsubscribe email [EMAIL PROTECTED] with 'unsubscribe isn' in the BODY
of the mail.

--- 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: Welome to the Internet, here's your private key

[Greg Rose]

>And if the runs test in FIPS were slightly extended, your sequence of
>consecutive 8-bit numbers would have been easily caught too.  Here's the
>full spectrum of runs for your sequence:
>
> Run-length  # of gaps   # of blocks
> ==  =   ===
> 1   24972529
> 2   12521255
> 3   628 621
> 4   317 307
> 5   159 152
> 6 80  75
> 7 70   0
> 8  0  74
> 9-14   0   0
> 1510   0
> 16 and up  0   0
>
>That there are 70 gaps of length exactly 7 but no blocks at all of the
>same length is extremely anomalous behavior for the output of a putative
>RNG.  Extending the runs test from 6 to 8 categories, i.e. counting blocks
>and gaps for run-lengths of exactly 1 to 7 and for run-lengths of 8 and
>greater, would easily have caught this.

Yes, I agree, but it isn't my test, it's just my code for the FIPS test.

>As you have noted, simple LFSRs are easily detected by FIPS.  LFSRs of
>longer period can be detected by using both a larger sample and analyzing
>the full, rather than the truncated, runs spectrum.  Alternatively, if you
>simply want to eliminate any possibility of an LFSR, just apply
>Berlekamp-Massey.

B-M is not something I'd normally recommend to run in power-up tests...

> > 15  multiple runs test failures (byte alignment too good?),
> >  but passes poker test
>
>You want to recheck your last result.[...]
>FIPS passes the sequence.

Correct, thank you. I've delayed releasing a bunch of my utilities for 
stuff like this because I hadn't yet had time to clean them all up and make 
them consistent... and it turned around and bit me. The "LFSR" program 
outputs ascii 0 or 1... I then used "binbin" to turn it into packed bytes, 
and this program was putting bits into bytes lsb-first. But the FIPS test 
(which originally did lsb-first too, but I was then convinced msb-first was 
"more conventional") didn't agree. It's interesting (but not worth 
pursuing) that simply reversing the bits in the bytes makes it fail the 
test. Anyway, now that I've changed this convention, my results agree with 
yours.

We've probably worn out everyone's interest with this, now. I'm happy to go 
offline with it though.

regards,
Greg.

Greg Rose   INTERNET: [EMAIL PROTECTED]
Qualcomm Australia  VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


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

RE: Welome to the Internet, here's your private key

[Kim-Ee Yeoh]

On Wed, 6 Feb 2002, Greg Rose wrote:

> At 03:48 PM 2/5/2002 -0600, Kim-Ee Yeoh wrote:
>
> >Could you clarify what you mean by "counter output"?  Are we talking about
> >a sequence of consecutive 8-, 16-, or 32-bit numbers?  If so, FIPS will
> >detect and flunk such sequences.
> 
> While priming the RC4 table, I accidentally filled the data buffer instead 
> (D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
> 
> This very much passes the FIPS 140 tests for randomness, despite being 
> nothing like it:
>   

For 16-bit or 32-bit sequences of consecutive numbers starting with 0,
FIPS easily flunks them because there are too many gaps (consecutive runs
of zeroes). 

And if the runs test in FIPS were slightly extended, your sequence of
consecutive 8-bit numbers would have been easily caught too.  Here's the
full spectrum of runs for your sequence:

Run-length  # of gaps   # of blocks
==  =   ===
1   24972529
2   12521255
3628 621
4317 307
5159 152
6 80  75
7 70   0
8  0  74
9-14   0   0
1510   0
16 and up  0   0

That there are 70 gaps of length exactly 7 but no blocks at all of the
same length is extremely anomalous behavior for the output of a putative
RNG.  Extending the runs test from 6 to 8 categories, i.e. counting blocks
and gaps for run-lengths of exactly 1 to 7 and for run-lengths of 8 and
greater, would easily have caught this.

I will even go further as to quantify what I mean by "extremely anomalous
behavior."  The expected number of blocks (or gaps) of length exactly p in
a uniformly random n-bit sequence is e(n,p) = (n-p+3)/2^(p+2) with a
variance of v(n,p) = (3*p^2-2*n*p-8*p+n-3)/2^(2*p+4) + e(n,p), a result
that can be shown without too much difficulty.  As n tends toward
infinity, the distribution in the limit is Gaussian (see Knuth V2 3E p69).
The probability that a uniformly random 2-bit sequence has no blocks
of length 7 is no more than 2.1 * 10^(-10), several orders of magnitude
lower than the one-in-a-million threshold at which the FIPS tests are
calibrated.

> Up to LFSR length 8, there are too few runs of length 6 or greater, so they 
> must fail. LFSR Length 9 fails the low end of the chi-squared test... too 
> evenly distributed. (Note that the counter above only passes this because 
> it cuts off in the middle of a byte count, and so skews away from the 
> one-heavy end of the spectrum). Hmmm... a table is required. (I'm using the 
> first polynomial specified in Schneier of each length, impulse sequence:
> $ lfsr -n 2 16 5 3 2 | binbin | fips140)

As you have noted, simple LFSRs are easily detected by FIPS.  LFSRs of
longer period can be detected by using both a larger sample and analyzing
the full, rather than the truncated, runs spectrum.  Alternatively, if you
simply want to eliminate any possibility of an LFSR, just apply
Berlekamp-Massey. 

> Poly Length Description of failure
> --- --
> 9   Poker test too regular
> 10  Poker test too regular
> 11  Poker test too regular
> 12  Passes test! (12, 6, 4, 1, 0)
> 13  Passes test! (13, 4, 3, 1, 0)
> 14  Passes test! (14, 5, 3, 1, 0)
> 15  multiple runs test failures (byte alignment too good?),
>  but passes poker test

You want to recheck your last result.  The primitive binary polynomial
x^15+x+1 with a starting seed of 1 produces a sequence that starts with a
length-14 gap followed by a length-15 block.  The FIPS runs spectrum is:

Run-length  # of gaps   # of blocks
==  =   ===
 1  25362514
 2  12841250
 3   633 650
 4   310 322
 5   153 157
 6 and up131 154

FIPS passes the sequence.



Kim-Ee


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

Re: Losing the Code War by Stephen Budiansky

[marius]

Joshua Hill wrote:
> 
> marius wrote:
> > Not quite true. Encrypting each message twice would not increase the
> > "effective" key size to 112 bits.
> > There is an attack named "meet in the middle" which will make the
> > effective key size to be just 63 bits.
> 
> Peter Trei wrote:
> > Don't forget that the MITM attack (which Schneier claims
> > takes 2^(2n) = 2^112 time), also requires 2^56 blocks
> > of storage.
> [...]
> > I don't lose sleep over MITM attacks on 3DES.
> 
> Unless I'm mistaken, the 2^63 operation MITM attack referenced in the
> original message referred to Double-DES, not Triple-DES.  The original
> cited value of 2^63 is incorrect; the Double-DES MITM attack (as proposed
> by Merkle and Hellman) is a known plaintext attack that takes 2^57
> operations, with 2^56 blocks of storage.
> 
> Your provided values are correct for attacking Triple-DES, but I don't
> think that's what the original author was referring to.
> 
> Josh

2^57 operations, with 2^56 blocks of storage manipulation can be
approximated to: 2^56 * log(2^56) + 2^56 * log(2^56) = 2^62 + 2^62 =
2^63

Betting on storage as a show stopper is not a good idea, regardless of
sleep pattern.

Marius

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

RE: Welome to the Internet, here's your private key

[Rick Smith at Secure Computing]

At 12:20 PM 2/4/2002, Bill Stewart wrote:

>A smartcard-only system probably _is_ too limited to generate keys,
>but that's the only realistic case I see.

Here are some manufacturer claims for the DataKey 330 smart card: average 
of 23 seconds to generate a 1,024-bit RSA key, average of 3 minutes to 
generate a 2,048-bit RSA key.

In practice this becomes one of those "installing something new" delays on 
your computer. You stick the smart card into the reader and watch the watch 
dial spin or the hourglass or whatever. Once it's done, the thing is 
"installed" and you're ready to go. Unsophisticated users may worry that 
they'll face the same delay the next time it's plugged in, but presumably 
people will learn from experience.

Of course, you don't want to use such a key to protect a set of closely 
held encryption keys that protect critical data, since you'll lose the data 
if the smart card gets damaged or breaks down.


Rick.
[EMAIL PROTECTED]roseville, minnesota
"Authentication" in bookstores http://www.visi.com/crypto/


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

Government, Industry Claim DMCA Not a Threat to Science? HUH?

[Hack Hawk]

Huh?  Take their word for it?  What are they talking about?  Looks like the 
DMCA will remain with us even longer now.  Why aren't the big cases being 
tried all the way to the Supreme Court?!  Damn the recording industry!

http://www.eff.org/IP/DMCA/Felten_v_RIAA/20020206_eff_felten_pr.html

- hawk


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

RE: Welome to the Internet, here's your private key

[Greg Rose]

At 05:55 AM 2/7/2002 +1300, Peter Gutmann wrote:
>Greg Rose <[EMAIL PROTECTED]> writes:
>
> >While priming the RC4 table, I accidentally filled the data buffer instead
> >(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
> >
> >This very much passes the FIPS 140 tests for randomness, despite being 
> nothing
> >like it:
>
>A generic order-0 entropy estimator (think Huffman coder) will pass this,
>because each symbol occurs with equal probability.  The reason this is a
>problem is because any introductory information theory text will give the
>standard formula for entropy estimation (H = -sum(prob(x) * log( 
>prob(x and
>users will either stop reading there or the text won't go any further.

But it is interesting that, had the FIPS test worked on a multiple of 256 
bytes, it would have caught it, because it uses a two-sided ChiSquare test. 
In other words, perfect frequency distribution (of nybbles) is also 
something it will reject... but it wasn't perfect because a sequence 
stopped early.

Greg.

Greg Rose   INTERNET: [EMAIL PROTECTED]
Qualcomm Australia  VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/
Gladesville NSW 2111232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C


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

Re: biometrics

[Ben Laurie]

Dan Geer wrote:
> 
> 
> >   In the article they repeat the recommendation that you never
> >   use/register the same shared-secret in different domains ... for
> >   every environment you are involved with ... you have to choose a
> >   different shared-secret. One of the issues of biometrics as a
> >   "shared-secret password" (as opposed to the interface between you
> >   and your chipcard) is that you could very quickly run out of
> >   different, unique body parts.
> 
> Compare and contrast, please, with the market's overwhelming
> desire for single-sign-on (SSO).  Put differently, would the
> actual emergence of an actual SSO signal a market failure by
> the above analysis?

Surely the point about (good) SSO is that you control the domain you
share secrets with and that domain then certifies you to other domains -
thus avoiding the problem of sharing your secrets across domains.

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: Welome to the Internet, here's your private key

[Arnold G. Reinhold]

At 6:18 PM -0500 2/5/02, Ryan McBride wrote:
>On Tue, Feb 05, 2002 at 11:16:40AM -0800, Bill Frantz wrote:
>> I expect you could initialize the random data in that memory during
>> manufacture with little loss of real security.  (If you are concerned about
>> the card's manufacturer, then you have bigger problems.  If anyone does,
>> the manufacturer has the necessary equipment to extract data from secret
>> parts of the card, install Trojans etc.)
>
>"They say a secret is something you tell one other person"
>  -- U2, "The Fly"
>
>While it is true that most users of smartcards will choose to simply
>trust the manufacturer, paranoid users could use a n choose m type of
>approach to achieve a certain level of assurance. In most cases
>verifying that a card is trojan free is a destructive process, so the
>user would test a relatively low percentage of cards and make the
>penalty for cheating high enough to ensure that the manufacturer stays
>honest.

One criteria for a cryptographic system that is rarely mentioned is 
auditability. To the maximum extent possible users should be able to 
verify every component of the system that affects security. We have 
gotten too used to systems so bloated that they no one can know 
what's in them. There are historic reasons for this but that is no 
excuse. Finding out how to simplify systems is far more important 
today than designing the next great cipher.  A great virtue of doing 
all crypto on a smart card is that they can be verified, at least 
with some effort.


>Having the manufacturer provide the random data changes the burden of
>proof drastically - there is no way for to _prove_ that they did not
>retain a copy of the random data, while it can be proved that they did
>not try to cheat simply by testing all the cards.

And creates a potential legal liability  for the smart card 
manufacturer. This gets to the original question of this thread. I 
wonder why the CA's lawyers let them generate private keys 
themselves. If it ever came out that private keys were misused by CA 
employees or even someone who penetrated their security, they would 
be legally defenseless, all the gobbledygook in their practice 
statements not withstanding. There is no good business reason for a 
CA to generate private keys and very powerful business reasons for 
them not to.


Arnold Reinhold

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

"One Card to Rule Them All..." Not?

[R. A. Hettinga]

http://www.usatoday.com/life/cyber/tech/review/2002/2/06/smartcard.htm




02/05/2002 - Updated 08:53 PM ET


One smart card for all your debts

By Edward C. Baig, USA TODAY

The annual Demo conference that kicks off in Phoenix next week may be the
most influential high-tech gabfest you've probably never heard of. But Demo
is very much on the radar screen of technology luminaries across the
spectrum - executives, financial analysts, venture capitalists and the
press.

No wonder. Demo has been the launching pad for everything from E*Trade to
the PalmPilot. And though most of the 66 new products and services are
being kept under wraps until the conference opens Sunday, this year's event
will flaunt advances in battery technology and computer displays, along
with new features for Microsoft's Tablet PC. I'll elaborate on the
goings-on at Demo in next week's column.

But for now, here's a sneak peek at one new technology that will surely
appeal to anyone whose wallet bulges from carrying too many credit cards: A
San Francisco company called PrivaSys will demonstrate a battery-powered
electronic credit card with an internal chip capable of holding, say, an
American Express, MasterCard and Visa - plus your debit cards, gas cards
and all other accounts - on a single piece of plastic identical in size and
shape to your other cards. Of course, PrivaSys is quick to point out that a
whole lot of complicated industry association issues must be dealt with
before each of the various financial institutions could appear on such a
card. (PrivaSys has struck a deal with First Data, the largest credit card
processor.) Merchants, by the way, need not change point-of-sale magnetic
stripe terminals.

For security purposes, whenever a consumer wants to conduct a transaction,
he or she punches in a PIN directly on the card's built-in keypad,
generating a code unique to the sale. The plastic includes a 10- to
16-digit readout for displaying credit card information and to let folks
select the appropriate charge account to use at the store - you push arrow
keys on the keypad to scroll through the list of accounts held on the card.
The cards also will be able to store "loyalty" account info, allowing
instant coupons and other rewards, perhaps a free soft drink in a fast-food
restaurant or an upgrade to first class when seats are available. An icon
on the card's readout may light up when you earn such an award.


Front Page News Money Sports Life Tech Weather Shop
Terms of service Privacy Policy How to advertise About us
© Copyright 2002 USA TODAY, a division of Gannett Co. Inc.

-- 
-
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: Welome to the Internet, here's your private key

[Peter Gutmann]

Greg Rose <[EMAIL PROTECTED]> writes:

>While priming the RC4 table, I accidentally filled the data buffer instead
>(D'oh!) with consecutive byte values 0x00, 0x01, ... 0xFF, 0x00, ...
>
>This very much passes the FIPS 140 tests for randomness, despite being nothing
>like it:

A generic order-0 entropy estimator (think Huffman coder) will pass this,
because each symbol occurs with equal probability.  The reason this is a
problem is because any introductory information theory text will give the
standard formula for entropy estimation (H = -sum(prob(x) * log( prob(x and
users will either stop reading there or the text won't go any further.  I've
seen a (fielded) crypto RNG which uses this sort of estimator, which won't
catch a whole pile of failure modes which the FIPS tests would get.

Peter.

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