Re: smartcards, electronic ballots

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

David Honig wrote:
> From "Ballot Proposal" version 1.3
> 
> 10 B DISPLAY
> (5) Election software shall print the selected choices on a fixed
> visible medium (such as paper), and shall require the voter to
> affirm those choices prior to electronic registration of the
> completed ballot.
> 
> I took this to mean that "what the machine thinks the voter chose
> is printed on paper" (for feedback/trust reasons).   Am I totally off?
> 
That's correct.  All the considered systems require some permanent 
audit record of the ballots.  This draft requires that the voter 
approve the record.  Thus, the printed record is primary, since the 
voter actually sees it and approves it.  Any electronic fudging can be 
detected and eliminated.

But, nobody is suggesting that the voter takes home the paper.  On the 
contrary, designs mentioned in meetings have the paper behind glass, 
not even touchable by voters.


> I wasn't clear on the architecture you have in mind ---I eventually
> figured out that you're requiring an online system with local and
> central real time reporting (mirroring) of votes.
> 
The Internet is big in legislators' eyes these days.  The network 
connection to a central (state) system is really the main motivation, 
as it allows the eRate funds to be used to run elections. 

Also, central state servers are needed to allow overseas electronic 
voting.  Too many trust relationships to have each base/embassy try 
to interact with every city or precinct.

And the mirroring keeps the locals from fudging the ballot counts.

Basically, I was asked, "Can the Internet be used to carry the votes, 
while still remaining secret?"  My answer is, "Yes, we already have 
SSL/TLS for confidentiality."  "What about ensuring votes only come 
from authorized places?"  "Easy, issue credentials for each machine, 
and use digital signatures on the ballots."  Etc, etc.

I've found a lot of support for open source software, because the 
politicians don't trust vendors or clerks.  They want lots of review. 
Especially with machines programmed by clerks.  And especially with all 
the campaign money that came in this cycle from so-called high-tech 
firms.  A compromised vendor would be a real problem for one party or 
another


> (Other architectures include standalone or LAN-only machines acting only as
> better voting-acquisition-machines; or a pure central server scheme like
> home internet voting.)
> 
There have been a lot of problems with stand-alone machines.  For 
example, in Florida, the recounts were supposed to actually re-run 
the ballots.  Instead, many places just looked at the counters without 
doing any real counting.  Also, elsewhere, machines have been found to 
be mis-programmed.  Etc, etc.

Home internet voting has a lot of problems, too, and is not being 
considered.  Just incremental improvements on the existing polling 
places and absentee ballots.  As you say, better vote acquisition -- 
evolution, not revolution.

The other thing is cost, cost, cost

Anyway, I've basically been answering a lot of questions for free, 
just as most of you are doing.  Admittedly, I've been given access to 
some reports and internal committee documents, but mostly I'm just 
trying to help them add security language.

I really think we've gone pretty far afield for this list.  Just send
messages to me privately, and I'll reply as I have time and interest.  
Thanks again.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOn4xmtm/qMj6R+sxAQElswQAwoZh8ZJ1sJFeQvpagdh2hJijtRNIONzD
Pae1EeCndFJwFfNHQFR87tOoNMNHCw+0Hf/IgUnYNrJVTr4WP8UJ1DAqdKS6Fw19
oLZ05hsaLvLgSwcGoR8WTkcr2emlkRzQ3vczGViPjlbNVPSptklN9nopQxFKe8HO
pGV9vquALz4=
=lZRn
-END PGP SIGNATURE-

Re: smartcards, electronic ballots

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

I'm sorry for the second message, but I could not let the egregious 
error pass uncorrected:

Ed Gerck wrote:
> The law does not allow it, and for good reasons as you mention. 
>...
> > The voting apparatus may keep a serial record of each vote, in order, for
> > auditing purposes.
> 
> No, it MUST not.  See the FEC standards on voting. The FEC standards also
> demand "storage alocation scrambling" in order to avoid even a serial order
> of storage.
> 
> > This is also mentioned in WAS's legislative text.
> 
> which is a miconception, albeit a common one
> 
Mr Gerck would do well to precisely specify the "law" which does not 
allow this?

Mr Gerck would also do well to specify which FEC "standards" have the 
force and effect of law?

The only document of which I am aware is the very old FEC "performance 
and test standards for punchcard, marksense, and direct recording 
electronic voting systems", january, 1990.  Never mandated, and no 
congressional appropriation for implementation.

He might be referring to chapter 4, section 4.5, page 47, where "parity 
and checksums" are required for integrity, and "the unit must 
incorporate multiple memories in the machine itself and in its 
programmable memory devices," and these "stored images of each ballot 
must protect the integrity of the data and the anonymity of each voter, 
by such means as storage location scrambling."

He might note that the subject of cryptography does not seem to be 
mentioned.  He might also note that for punchcards and marksense, 
no "scrambling" occurs.  

Moreover, he might note that the system audit requirements later in 
the same chapter (page 49) require "a complete, indestructable archival 
record of all system activity related to the vote tally."  That is to 
accomplish a "reconstruction" of the election process (repeated several 
times).  Audit data is to be serialized by a "date-and-time stamp" and 
"preserved during any interruption of power" (page 50).

As to the matter of "law", the Congress is granted the power to set 
standards for its own election (Const Article I, Sections 4 and 5). 
The FEC isn't mentioned.

But the FEC proposed standards don't even consider networks, database 
replication with offsite storage, and as mentioned earlier, 
cryptographic security.

'nuff said.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOn37BNm/qMj6R+sxAQGgeAQAm/nj4Ro4zcLALFhIdyggFCSQphIZ3NhH
xunAksi9GyDghK7uQh8KcOZ2b16t3KEsheenmFDmx6ZDUENgnUeY7SCfyH0Egen6
2A8WS5VApivaFcV3PPCQx4/voPamaS8b5NcnDCz7ow8PYWl/bTp5vicxibjnEGpB
VuQeAms8cUY=
=njYh
-END PGP SIGNATURE-

Re: smartcards, electronic ballots

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

David Honig wrote:
> 
> If you give people a paper receipt with their votes on it
> (as WAS's scheme mentions) then their votes can be bought or blackmailed.

I'm unaware of how that interpretation might have arisen?  I don't see 
anything in the proposed text that calls for a receipt to be given to 
any voter, let alone a copy of their votes?

Perhaps there is some confusion in the interoperability requirement 
that electronic ballots be stored in a printable US-ASCII format.  

Why?  Because nobody (other than mathematicians) trusts the machines! 
The threat model is (1) the machines won't work correctly, and then 
(2) the clerks will try to steal the election, and nobody will be able 
to tell for sure, because the machines are unreliable.

Specifying the interface also promotes competition for different 
components of the systems.

The requirement arises from the need for "transparency" -- the votes 
need to look like votes to humans.  The auditors need to compare the 
recorded votes.  Everything points to a simple textual requirement.

For some odd reason, the legislative staff seems to intuitively 
understand the trust paradigm that we often struggle to elucidate:
machines don't vote/spend/publish, people do.  

The use of digital signatures is to ensure that the MACHINE is 
authorized, not the humans.  The use of human readable text is to 
ensure that HUMANS can audit the result.

That means that blinded signature schemes and smartcards and fancy 
unauditable and/or uninspectable equipment are not on the table.

Anyway, this thread has gone off into rampant speculation. 

I asked for assistance in review of the technical cryptographic 
terminology.  I've received that, and I've passed the recommendations 
on to the appropriate parties.  Thank you very much.  

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOn3cf9m/qMj6R+sxAQEChQP+MT1queIoc8YSlkCvmDMyTMRKO2Hz4pQ9
xgj6T0roFy5MRIExj0wLzO/DUtb8T+nsZeeHPADmQCM7u6dIqSWFYD+I3DiiAyJc
goICR8j9phqUESkeu2S5bl7uRySr/KxROBBUMLjfxtbYQFCpwLVfnEVg/I+DTorH
CWeI7K5WIm0=
=2Dkb
-END PGP SIGNATURE-

Re: smartcards, electronic ballots

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

"John R. Levine" wrote:
> The current election system, for all its faults, is the result of two
> centuries of effort by people not all of whom were completely stupid,
> and has a complex and not always set of features to defend against all
> sorts of schemes to corrupt an election.  The punch card ballot
> happens to be a uniquely bad technology for reasons we all know, but
> most of the surrounding infrastructure is old and kludgy but not
> broken.  We need to keep this in mind when designing something new and
> zoomy that's supposed to replace it.
> 
I could not agree more!  The purpose of the legislation is to assist 
the existing election processes, not replace them out of whole cloth!

In fact, the latest #1.3 draft changed the short title to 
``Electronically Assisted Federal Election Requirements Act''.

This discussion has digressed onto smartcards.  That's not helpful, as 
no legislator (that I'm aware of) is proposing use of smartcards, nor 
a national voting ID.  As some have noted, the specifics of this bill 
would create single use public/private key certificates, that would 
expire at the closing of the polls.

However, if there is any language that would prohibit smartcards, 
please let me know.  We are trying to be technology neutral.

And in the same vein, I forwarded Ed Gerck's list of published 
'requirements' to Lynn.  She intends to use them as a perfect example 
of what we DO NOT want!


Ed Gerck wrote:
> 1. Sixteen requirements for voting. The requirements are technologically
> neutral and can be applied to paper, electronic or Internet systems.  There
> is an extensive discussion of alternatives, before the requirements are
> summarized. Available at http://www.thebell.net/archives/thebell1.7.pdf ,
> page 3. 
> 
There are some requirements that are nearly identical to those that 
we've selected.  And I like the kudos to IETF, and open systems.

However, the first half dozen are based on the bad presumption that:

1. Fail-safe voter privacy. Define: “voter privacy is the
inability to know who the voter is.” Assure voter privacy
even if everything fails and everyone colludes.

First of all, that's not "privacy", that's "anonymity". 

We have voter registration precisely so that we know who the voters 
are!  We are not changing voter registration

4. Fail-safe privacy in universal verifiability. If the
encrypted ballots are successfully attacked, even with
court order, the voter’s name must not be revealed. In
addition, the system must provide for “information-theoretic
privacy” (i.e., privacy which cannot be broken
by computation, even with unbounded time and
resources) in contrast to systems that would only provide
for “computational privacy” (i.e., privacy which could be
broken by computation, given time and resources).

I cannot believe any security analyst worth his salt could 'specify' 
such as requirement.  When I specified computational infeasibility of 
100 years, the Science staff came back and asked how NIST would test 
that?  We reduced it to 10 years, something that might be achievable.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOnq+M9m/qMj6R+sxAQFEHQP+PCAyzyyrt/AbJ/yYI+VEm00anTOqvp4J
svSrUhl70xqHaoJ3xwl4quRZeIyjithfsLjc7L1+UsZtwBe0owSvSOeIRIUmgqD6
lmm7YH+Z5yvu1XFdHlPqNI79dUAMnz/sMDkQuQBrkD897A/GST8AeG78rA6rPGlM
HjqPSLmUldw=
=GwNT
-END PGP SIGNATURE-

Re: electronic ballots

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Thanks everyone for the helpful comments.  I've combined them as well 
as I could.  Some folks sent privately, as indicated.

David Honig wrote:
> 
> At 01:03 PM 1/25/01 -0500, William Allen Simpson wrote:
> >I've been working with Congresswoman Lynn Rivers on language for
> >electronic ballots.  My intent is to specify the security sensitive
> >information, and encourage widespread implementation in a competitive
> >environment.  We'd like feedback.
> 
> You should list the desirable properties of a voting system and
> then the threats to those properties.  

Actually, there's a lot of this already, going back many years.  There 
were many such threats described on this list last year, and there have 
been a couple of conferences.  In the process of passing legislation, 
somebody might make a presentation to a committee, or write a report on 
a specific protocol.  But, that kind of information isn't specified in 
an "authorization" statute.  


"Arnold G. Reinhold" wrote:
> I find it unsatisfactory to review a proposed cryptosystem
> design presented in legal language. At the very least, a careful
> system design document, preferably with pseudo code, and a detailed
> threat model should be presented. A working model would be better.
> 
This isn't a proposed cryptosystem design.  It's a compilation of 
minimal requirements for security.  It is expected that there will be 
many designs that meet the requirements.  It's based on known designs, 
and existing analysis. 

Just as in standards development, requirements don't specify the 
result. 

As I tried to indicate, this is to specify the security sensitive 
information, so that when folks come to testify or work on conference 
papers, they are all speaking the same language.  I needed your help to 
ensure that we didn't miss anything important, and we don't go down the 
sad course that electronic signatures suffered last year.


David Honig wrote:
> you're gonna have to educate them in security
> analysis. 

This is exactly the purpose.  The select committee will be designated 
next week.  Most legislators won't bother to be educated until there is 
actual legislation to consider.

Congresscritter Rivers convened a roundtable on Internet Privacy about 
5 years ago, long before most folks in Congress were considering such 
issues.  She went to the trouble to find local talent, such as Honeyman 
and myself.

She has long displayed interest in other security issues.  She's on 
Science and Technology, and has a couple of major universities in her 
district.  Her background is biology and anthropology, so she is 
capable of following scientific rationale.

I actually consider her pretty Internet savvy; however, I'm biased.

On the other hand, she finds PGP too hard to use.  She wants these 
requirements to be simple, low cost, easy to use, and as close to 
existing election practices as possible, so that non-technical people 
can comfortably use the system. 

Those of you that have known me for a long time might remember that I'm 
the fellow that wrote the Michigan appropriations language to provide 
matching funds for NSFnet, the precursor to the commercial Internet.  
I've been involved in electoral politics for going on 25 years.  If you 
know of others with the requisite experience in politics, legislation 
and security, I'd like to meet them.


"(Mr) Lyn R. Kennedy" wrote:
>   1. An electronic election system need only be as good as the current
>  system. While perfection remains the goal, the minimum criteria
>  is that it be no worse.
> 
>   2. There needs to be an absolute disconnect between the voter and the
>  vote. Some kind of voting certificate should allow a vote but make
>  it difficult to determine how someone voted.
> 
I agree.  Very important points.

>   3. The concept of the polling place needs to be re-examined. ...

Someday, remote absentee voting might be practical.  Right now, the 
goal is to gain experience in existing polling places, and remove the 
restriction that military bases and foreign offices cannot be used as 
polling places.  There was a pilot on that last year.

> It seems that something like a smartcard would be the best scheme. 

Not likely.  Voting is very different from banking transactions.  And 
issuing smartcards with special software for voting is likely to be 
prohibitively expensive.


Somebody wrote:
> It strikes me that the greatest cause of confusion in vote counting
> stems from the variation with which voters express their intent.

Yes, that's why most of the language concentrates on uniformity of 
interface and presentation.  The only known way to eliminate that 
variation is to use an entirely digital method.  Every other system 
in

Re: electronic ballots

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Long answer

Matt Crawford wrote:
> 
> It looks as if your VERIFIABILITY constraints allow pay-for-vote to
> take place.  The voter V can show his audit number to ward-heeler W,
> who can subsequently verify, together with poll-watcher P, that V
> voted for Boss B.  

Maybe you meant "clerk", not "poll-watcher".  

There has to be some sort of indication that you've voted, to prevent 
multiple voting.  Granted?

A poll-watcher would only know the same audit-number -- but they 
already know that.  When the clerk writes your name into a poll book, 
or (in other places) writes a poll-number next to your name on the 
printout, a poll-watcher knows when you came in, and what order you 
voted.  Think of it as traffic analysis. 

However, to learn the vote requires the assistance of the clerk,  
revealing the ballot itself.  To prevent those kind of shenanigans,  
all parties have poll-watchers  (In practice, we have problems 
finding enough volunteers, so we place them in tactical locations.)

It _IS_ true that virtually all vote fraud is conducted by clerks.

That's why you have to have the audit numbers.  So that someone can 
catch the clerks (after the fact). 

Good paper ballot systems use the same form of indirection.  The poll 
number is written on the serial tab that is removed from the ballot 
when the ballot is placed in the box/machine.

There are existing systems that don't have the audit number.  In 
Ingham County, Michigan, last year, the punch cards didn't have a 
serial number.  During the recount, ballot boxes in primarily 
Democratic precincts (Michigan State University) "miraculously" had 
more ballots than the number of folks that voted.  Entire precincts 
were thrown out!  The Republican won the recount by less than 100 
votes, when the Democrat should have won by several thousand.

All you have to do is throw a blank ballot or two in the box while 
nobody is looking.  That's why you have to serialize the ballots, so 
that spurious ballots can be removed/ignored.


> The PRIVACY section does not seem strong enough to
> prevent this.
> 
Dunno what to do (in a law) other than outlaw the behaviour, ensure 
that the clerk has a strong probability of being caught, and a stiff 
enough penalty to provide deterrence.

Any other ideas?


-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOnCwndm/qMj6R+sxAQHSzQP8D+DLzPCdER6Ja8aaNvaGZ8tRu/9y5Fb0
Uf3DTW2KOGoZ3YzsHWfLPvW/SMrV9Mv5ij9jDtE0cU/8ydNWjHbXiMGcT6Zbq4ds
cwaegN8cQJX2ZGNNhzVmJaf3DUdkxNRiDO7bMPKC7pr/4Wf1SQTidO3qUJDfhcCK
UEcoRphcsKA=
=Z8SZ
-END PGP SIGNATURE-

electronic ballots

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

I've been working with Congresswoman Lynn Rivers on language for 
electronic ballots.  My intent is to specify the security sensitive 
information, and encourage widespread implementation in a competitive 
environment.  We'd like feedback. 

Unlike last year's so-called "electronic signatures act", this one 
specifies real digital signatures, with definitions culled from the 
usual Menezes et alia Handbook.

Here's what it looks like so far (draft #1.2).

Summary:

Minimal requirements for conducting electronic elections.  Technology and
vendor neutral.  Promotes interoperability, robustness, uniformity, and
verifiability.  Easily integrated into existing equipment and practices.

Handle duplicate votes and/or denial of service through submission of
bogus votes.  Permit multiple persons to use the same machinery.  Inhibit
persons with access to the machine from fraud.  Provides penalties for
circumvention.

Education & telecommunications; all computing equipment purchased for
schools or libraries with federal money under "eRate" or other
assistance program [cite] shall be capable of use for federal elections.
States receiving such funds shall participate in electronic federal
elections.



Title __ -- Electronic Election Requirements

SEC. xx01. SHORT TITLE.

This title may be cited as the ``Electronic Election Requirements Act''.


SEC. xx02. DEFINITIONS. -- In this title:

(A) BASE64 ENCODING -- A standard method for compact display of
arbitrary numeric data, described in Multipurpose Internet Mail
Extensions (MIME), Internet RFC-2045 et seq.

(B) DIGITAL CERTIFICATE -- A verifiable means to bind the identification
and other attributes of a public key to an entity that controls the
corresponding private key using a digital signature.  In this
application, the certificate shall be self-signed, and signed by the
appropriate authorizing state server.

(C) DIGITAL SIGNATURE -- A verifiable means to bind information to an
entity, in a manner that is computationally infeasible for any
adversary to find any second message and signature combination that
appears to originate from the entity.  Any method used for an
election shall ensure integrity and non-repudiation for at least ten
years.

(D) ELECTION SOFTWARE -- Applications or browser applets that display an
electronic ballot and record the voter choices.

(E) ELECTRONIC ELECTION SYSTEMS -- A collection of electronic
components, including election software, hardware, and platform
operating system, on both local clients and remote servers, used in
the election.

(F) MANIPULATION DETECTION CODE (MDC) -- An easily calculated function
that indicates whether the information has been modified. 
Specifically, the output of a one-way hash function, which is
computationally infeasible to find any second input that has the
same output.

(G) PSEUDO-RANDOM NUMBER GENERATOR (PRNG) -- A one-way function that
generates an apparently unpredictable sequence of unique numbers,
initialized by a random starting value (called the "seed").  Any
method used for an election shall inhibit computational discovery of
the sequence, by an adversary with knowledge of the algorithm and
any previously generated numbers, for at least six months.


SEC. xx10.  OPERATIONAL REQUIREMENTS

(A) INSPECTION -- Election software shall be open source implementations
capable of inspection by poll watchers and election inspectors. 
Functional components shall include tamper protection by
manipulation detection code and digital signature, which shall be
separately published and verified.

(B) INTEROPERABILITY -- Election software shall be capable of operation
on at least 3 multiple, independently implemented platforms.  This
applies to all functionally equivalent or interchangeable components
of the system or process in which they are used.

(C) ROBUSTNESS -- Election software shall concurrently register voter
choices at the local client, and municipality or other regional
voting district server(s), and state server(s), using well-known
database transaction multi-phase commit techniques.

(D) UNIFORMITY -- Display of candidates shall be substantially similar
for each race within a state.  On each display, the names of
candidates may be randomly ordered within each race.  Election
software shall prevent overvote and undervote, and shall allow the
voter to correct such conditions.  Voters unwilling to indicate a
choice may select "no vote".  Where "none of the above" or its
equivalent is a valid choice, "no vote" shall be a separately
distinguished choice.

(E) VERIFIABILITY -- Transactions registering voter choices shall be
recorded in a printable textual format using US-ASCII characters.
The first line of each transaction record shall include an au

Re: FC: Congress weighs crypto-in-a-crime, wiretapping legislation

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Declan, I've looked at the floor activity for that day, and searched 
the house record [Page: H12100 et seq].  I cannot find any mention of
HR.46, or "encryption", or "wiretapping".  I also looked at every
reference to the word "computer", which appears frequently.

Could your sources be more specific as to how this was passed? 

Sometimes, it's better to say "Senate" when you mean only the Senate, 
and give specific names of supporters (Stevens, Hatch), rather than 
tarring the whole "Congress" with bills that are going nowhere.

Yes, there is a certain amount of silliness and mislabelling that was 
passed Dec. 15.  S.2924 on "false identification" had all the text 
on identification removed, and replaced with a relaxation of child 
labor restrictions.  That kind of thing can catch members unawares.
My understanding is that's on the way to a pocket veto.

``Children's Internet Protection Act'' (CIPA) passed as part of 
HR.4577, and read in a certain way, it's pretty bad for civil 
liberties, but no restrictions on encryption that I can see.  

There's an easy work-around to CIPA that was adopted here in Ann Arbor.  

The AA public library _will_ provide a filtering program, when it 
becomes commercially available, which can be programmed to reject those 
sites that have been determined by a court of law to be obscene, etc.  
Only those sites!  And, in order for the program to be activated, the 
child must be accompanied by a parent.  No court decision, no parent, 
no need for protection.

I'm a bit more concerned by the so-called ``Neighborhood Children's 
Internet Protection Act'' that follows CIPA.  As far as I can tell, 
it requires every site to continuously review and record all activity 
on the 'net, in order to determine "access by minors to inappropriate 
matter", "using electronic mail, chat rooms, and other forms of direct 
electronic communications", "unauthorized access", "unauthorized 
disclosure ... of personal identification information".

The "inappropriate matter" standard seems much broader than "harmful".

Also, it appears to be an attempt to prohibit judicial review of the 
local criteria for determination of content.  "No agency or 
instrumentality of the United States Government" presumably includes 
the federal courts. 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOktVVdm/qMj6R+sxAQGMBgQAhxsXn4yJ2tD3caqfNOz5PhIM4MY3fOKP
Vrl7HVBSdYXen4DZ5YOrBeTblamHa1a9TElJJ5NVvVcqdxeEXk1QE+x7UZuUL92O
B+S0b4DtxzYezGHf5NLN0pzdzM+ZjmHnwIdvsnTSBNX3bDgIu/eKrbxpGAj4tTMX
fwMzJo61s9Y=
=zexu
-END PGP SIGNATURE-

Re: IBM press release - encryption and authentication

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

David Wagner wrote:
> History shows that it is extremely easy to propose schemes for
> encryption-with-integrity that are plausible-looking yet nonetheless
> entirely broken.  At this point, I don't think I would trust very much
> a proposal without a proof.
> 
For example, the chaining scheme used by Kerberos?

Never-the-less, engineers traditionally propose incremental 
improvements, standing as it were on the shoulders of giants


> And I think it would be fair to say that CBCS falls into the camp of
> plausible but unproven proposals.  (Correct me if I'm wrong!)

Well, had you attended the particular conferences, you'd have heard 
the rationale.  And the design notes in the documents describe the 
specifics.  I'm not a crypto-mathematician, and I make no claim as 
to the sufficiency of proofs.  You did review one of the early drafts 
of CBCS.

In the other case, enhancing XEX-CBC, you provided a major amount 
of improved text regarding Replay Protection in an earlier part of 
the same paper, and agreed to be a named co-author.  Presumably, had 
a proof been available at the time, you would have pointed to it

However, as is often the case, later scholars have verified both 
schemes (for their own purposes)!



CBCS has several security notes, summarized here:

1) the authentication/integrity function is separately keyed, rather 
than from the encryption function.

2) the IV feeds the CBCS function, which then feeds the encryption 
function, to generate unpredictable initial values for the first 
cipher block.

3) the IV is intended to be unique over the lifetime of the cipher 
session-key(s).

4) the IV incorporating the ESP Security Parameters Index (SPI)
and the anti-replay ESP Sequence Number (SN) together
can provide both uniqueness and mutual protection
between the first block and the ESP header.

5) prevent linear cryptanalysis by incorporating a non-linear 
rotation function.  This is specific to my choice for the 
authentication/integrity function, namely the combination of 
addition (sum) with a variable rotation.

As CBCS was based on earlier schemes that XOR a key and/or 
previous ciphertext block with the next plaintext and/or ciphertext  
block, CBCS has the simple unstated assumption that the output
of the cipher is uniformly distributed and unpredictable.  That is, 
it probably is secure only when used with a robust cipher.  I should 
have explicitly stated that -- I merely referenced it in other papers.

Since then, somebody else has written a formal proof for the 
generic class of g(x) functions in the same or similar construction
as CBCS.  He presented at IETF last year.  I'm sorry, I've never read 
the paper.  I was incensed that he claimed a patent on his particular 
variant of the idea.



XEX-CBC "whitening" in draft-simpson-ipsec-enhancement has a very 
simple stated security limitation: "It is insecure without combination 
with a robust cipher."  The only reason that DES-XEX3-CBC wasn't 
adopted as the default cipher by IETF in 1995 was that there was no 
formal proof of its security. 

Likewise, the substitution of a PRNG, or one-way hash function as a 
PRNG, for the fixed secret(s) in XEX2 or XEX3, depends on the 
security of the underlying cipher.

Since then, as referenced in my later XEX3-CBC Transform papers, 
Rogaway did an analysis of the security in 1996.



The upshot of this exercise is that we have proposals developed in 
open fora that are patent free.  We don't need to rely on patented 
variants. 

While I am thankful that later analysts have more rigorous proofs of 
security, I don't believe that the proofs are patentable.

Moreover, I think that we should discourage scholars holding back on
design publication in order to secure patent rights -- especially in 
the "information age", publish early and often!

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOj4x/Nm/qMj6R+sxAQHQwAP/Rz4IqjupVkvr89tQukyYBWVh3w4YQriv
LGfFaOkweWJgDUeugxTRvfVhuxe61C9KKdJYTo5N+9wt/mVdxqJ14n/CT4sxwAek
gE9iaRx1QlXLpQQSz1QOF/i3IRih6LDQRRrl4QGFWbpI3bV5i2kAl8E7NzDBz7+J
i44awIe4m+c=
=9kr9
-END PGP SIGNATURE-

Re: IBM press release - encryption and authentication

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Bruce Schneier wrote (CRYPTO-GRAM, December 15, 2000):
> Combining encryption with authentication is not new.  The literature has
> had algorithms that do both for years.  This reearch has a lot in common
> with Phillip Rogaway's OCB mode.  On the public-key side of things, Y.
> Zheng has been working on "signcryption" since 1998.
> ...
> 
In the IETF, we discussed this on the IPSec mailing list as early as 
August 1994.  As best I can recall, I first presented Cipher Block 
CheckSums (CBCS) at the December 1994 meeting, and wrote the first 
formal draft in February 1995.  The last internet-draft was July 1998.

The IBM scheme also has somewhat in common with various "enhancements" 
to DES-XEX that were discussed.  I'm not sure when the first draft 
was written (this laptop only goes back to 1997), but the last 
internet-draft (draft-simpson-ipsec-enhancement-01.txt) was May 1997.

Both efforts used a separate authentication key to generate a sequence 
that was XOR'd with the plaintext and/or ciphertext.


> Unfortunately, IBM is patenting these modes of operation.  This makes it
> even less likely that anyone will implement it, and very unlikely that NIST
> will make it a standard.  We've lived under the RSA patents for long
> enough; no one will willingly submit themselves to another patent regime
> unless there is a clear and compelling advantage.  It's just not worth it.
> 
(roar of the crowd in agreement)

As far as I can tell, the only unique element is the mod 2^128 - 159 
function.  We just need to use another function.

Greg Rose points out that the function is flawed.

My own favorite (in CBCS) has been rotation by the population count 
(of the number of 1 bits).  Very non-linear.  Some folks think that's 
slow, but it's fast compared to MD5  And that's what we used in the 
old CDC, which had a machine instruction for population count.


Bram Cohen wrote:
> 
> There's an improved version of the IBM mode at
> http://csrc.nist.gov/encryption/aes/modes/ in the 'OCB mode' paper.
> 
> Clearly, it's a good idea to wait for new developments to stop happening
> to use the new modes.
>

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOjtqgdm/qMj6R+sxAQGbxgQArF2xcR7elH9GD71KqacgrIakskpnL1nE
7FCVE/kcYCMnc5QhZlr80gdVGFhvMZLgm7wOzRHAgaPM+U//ZWcdfazVuaHHC8kH
YYlabqeFpJ2SAP2MRIruJde1fFzatpjb87OimhxRC4NTlsc6UQEqBsqzAB5iEh5r
sDNlF5YD+GA=
=8Vry
-END PGP SIGNATURE-

migration paradigm (was: Is PGP broken?)

[William Allen Simpson]

David Bird wrote:
> 
> In my opinion, cryptography should be seen as an evolutionary
> process. Protocols are continuously evaluated for their "fitness" in the
> context of current number theory, advances in computers/CPUs, and many
> individual/company/implementation specific requirements. It may be
> impossible to get the ideal solution, but we optimize to what we consider
> vital for survival.
> 
I've read with interest the thread, and I'd thought that we all came 
to this conclusion some years back.  That's why we had the SPKI 
response to PKIX, OpenPGP, etc.

We could use the excuse of AES implementation to foster a move to a 
new common denominator.  That implies a willingness among ourselves 
to move, abandoning the older solutions (with perhaps some migration 
and translation programs to process archived information).

I once (circa 1996-1997) tried to foster this with PSPKI (Pretty Simple Public Key 
Infrastructure), combining what I saw as
the strengths of 
OpenPGP, SPKI, SPEKE, etc.  Maybe it's time to try again?

My requirements were (off the top of my head, there were more):

 1) simple, easy to process and debug data formats.  Like SPKI and 
KeyNote, not PKIX or even OpenPGP.

 2) possibility of translation of public keys between systems (but 
not the OpenPGP "sub-packets") for easier migration.

 3) explicit inclusion of roles and capabilities.  There are many 
flavors of this -- I simply indicated a "group" of things to be 
signed, but KeyNote attributes might serve better.

 4) an agreed algorithm for generating private keys directly from 
the passphrase, rather than keeping a private key database.  
Moving folks from laptop to desktop has been pretty hard, and 
public terminals are useless.  AFS/Kerberos did this with a 
"well-known" string-to-key algorithm, and it's hard to convince 
folks to use a new system that's actually harder to use.  We need 
to design for ease of use!  

What support is there among us for evolving together?

Are there other requirements?

Is it time?

Re: [Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Now, I didn't start this thread to argue about licenses.  I just wanted 
folks to review code, should they be so inclined.  So, this is my last 
comment.  Sorry that someone took umbrage.

Ben Laurie wrote:
> 
> William Allen Simpson wrote:
> > I was not aware that OpenSSL had changed to be compatible with GPL.
> > And I cannot find the license statement on the web pages.
> 
> The licence has not changed.
> 
I've found the license in the source.

It's not compatible with GPL -- indeed, it is antithetical to GPL, 
specifically mentioning GPL by name!


> I don't see any concerns here, just a history lesson.
> 
Hmmm, since I know you read the thread at the time, I can only 
conclude that you are being disingenuous.  

It not only has the old BSD 4 clause license, it has additional 
clauses


> And this, as far as I can work out, is really just saying "it isn't the
> licence we want". There is no requirement in GPL for the OpenSSL licence
> (or any other) to not have an advertising requirement, again, as far as
> I can work out - where does it say that?
> 
IANAL, but my memory of the argument (without bothering to look it up) 
is that GPL doesn't allow additional requirements to be imposed, and 
monolithic works apply GPL to the entire work.  Your license is 
incompatible (and deliberately so).  It makes your code useless to the 
rest of the project.

So, it isn't the license they want!


> The current beta has MacOS support.
> 
Hmmm, have you personally verified this statement?  AFAIK, by the 
documentation, it won't even run the test apps.  It's a start, but it's 
not ready.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOcfvCdm/qMj6R+sxAQH6+QP9H2kvgl88IxIzV3tA61icv0kU7KoNTvYK
+Fd14tt+UoN35HRwaoNvXeYbwsq8gyCtVl3vQYYponsEt+Ij7sdpxwx5zJDS64gp
LRLSLWAnu9N8buZRdFLd0C0uqXEosZRVNN0ZUFpLKCuwrAG8jwi5L+0NVZZM56N7
Cu5dYGuWPjg=
=5/uU
-END PGP SIGNATURE-

Re: [Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Ben Laurie wrote:
> 
> As far as I can tell, the problems are invented rather than real. At
> least I can't recall any real problems except "it isn't the licence we
> want it to be".
> 
I was not aware that OpenSSL had changed to be compatible with GPL.  
And I cannot find the license statement on the web pages.

Specific concerns from email were:

From: [EMAIL PROTECTED] (Tim Hudson)

BTW the SSLeay license was not derived from the Apache license, but
actually from the original BSD licensing terms with some changes added to
prevent problems that had occured with previously released software being
adopted into other licensing schemes and other people claiming authorship
of software they did not write. 

I wrote the SSLeay license to go with the first public release 
of the SSLeay code so I think that my understanding of the origin of
the license can probably be accepted as accurate :-)

From: Frank Hecker <[EMAIL PROTECTED]>

I think getting rid of the advertising requirement in the OpenSSL
license needs to be done anyway, to eliminate potential problems with
using OpenSSL code in other projects where the GPL is used. However note
that making the change is not as simple as it sounds, because in order
to change the OpenSSL license you'll have to get permission from all the
OpenSSL contributors.


> Gasp! What do you mean? Can you name a platform it doesn't run on?
> 
For example, I'm writing this on MacOS.  Although there was a single 
reference to MacOS buried on the web pages, it doesn't appear to be 
ready for prime time.


> Of free software? That's silly.
> 
> To clarify: there may be a reason to have other implementations to
> _test_ the "real" one, but there's no point in duplicating the massive
> amount of work that has gone into optimising and porting OpenSSL.
> 
I firmly disagree.

For example, the first several implementations of IPSec and Photuris 
were "free", made in different countries and under different licenses.
This continues to be very important to this day.

It often takes a considerable length of time for minor problems to 
surface -- note the recent discovery of buffer overflow issues in 
RSAref 5 years after it had been widely used.  Heterogeneity is 
of the utmost importance in maintaining a passibly secure 
infrastructure during a time of repair.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOcd9aNm/qMj6R+sxAQFMAgP9EiYcJwEND13rdKSl02abBepDPE2gngZ8
f1a99+fC+GBzqwXkCYmV++sKiDpeexFbkvwkiQTH62o0a7o7hsBtwn6oe+1qUgBy
5BZJNvL2a7YSWEbJKPo2GqNFXAtnmUSLPWqltl0mFNJZq4Cc3nlB2t9CtJQAmnvA
7WhItsYOqGY=
=jRSl
-END PGP SIGNATURE-

Re: [Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

I remember you expressing such sentiments on the mozilla security list some
months ago.  But, there are problems with the OpenSSL license.  And not
enough crossplatform support.  And, I'm a big believer in multiple
independent implementations.

Ben Laurie wrote:

> What they _should_ do is use OpenSSL and work on that, instead of
> reinventing the wheel.
>



-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOcbmXdm/qMj6R+sxAQFrYAP+LrW9/guoEdnf/Tpsxi3k2wHMtYVeYE0I
7KzBLo6CY1ikvjI7Gd8AiOYrQC5fUXHTv7VUsRspsAQuQOa4n2ZIbQna1T2pGC03
6VLYu8O4+NL2BITCYCSH6tXlBmsPPt6tUHk2gO/l+B0ibO4qjCui88oejEgQb8HB
HyVxvL3qelI=
=nqZI
-END PGP SIGNATURE-

[Fwd: [ANNOUNCE] NSS 3.1 Beta 1 Release]

[William Allen Simpson]

Fallout from the early RSA release into public domain, the references 
to BSAFE have been replaced, and a bunch of stuff are GPL.  Is there 
a team of folks doing independent code review?  

Since this is likely to show up on a lot of systems, and any bugs 
will plague us for a long time, this seems to me to be a time for 
serious cooperation.


 Original Message 
Subject: [ANNOUNCE] NSS 3.1 Beta 1 Release
Resent-Date: Fri, 15 Sep 2000 19:25:25 -0700 (PDT)
Resent-From: [EMAIL PROTECTED]
Date: Fri, 15 Sep 2000 18:35:00 -0700
From: Wan-Teh Chang <[EMAIL PROTECTED]>

I am happy to announce that NSS 3.1 Beta 1 has been released,
including a new implementation of the RSA algorithm. This
release provides, for the first time, a complete open-source
implementation of the Netscape crypto libraries and will be
used in a future version of Personal Security Manager for
Mozilla. 

The release notes can be found at
http://www.mozilla.org/projects/security/pki/nss/release_notes_31.html.

The final NSS 3.1 release is scheduled for Oct. 13, 2000.
Please help us test NSS and port it to your favorite platforms.

Wan-Teh Chang

Re: Oh for a decently encrypted mobile phone...

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

I was somewhat amused to note that Qualcomm's offering has another 
link for "civilian" versions.  So, what's the difference? 

A major point of the thread is that these are civilian mobile phones.

Another issue is that the Qualcomm phones don't encrypt on analog.

Starium seemed like a good idea, until they decided that the "standard" 
would be licensed by a consortium.  We need an open protocol.

I've advocated for a half dozen years now that we approach some mass 
commercial vendor of wireless phones (say vtech or conair) and ask 
to add security code.  These phones are all digital spread spectrum, 
yet connect to normal analog lines.  No reasons why the security 
couldn't be end-to-end.

We also need some open standards

Greg Rose wrote:
> Stariums (a) should appear RSN (I have one) but (b) are not mobile.
> 
> There's the Qsec-800 CDMA mobile from Qualcomm, but that won't work in
> England I don't think. See http://www.qualcomm.com/govsys/qsec.html .
> 
> Disclaimer: I work for one and invest in both, so I'm biased.
> Greg.
> 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOcNZnNm/qMj6R+sxAQFXYgQAqAlYP8QDjRjWnoLvabaY2h8qVZXQRHp8
9ODqQi37oOp+p5J23rLczIEAQwTYacr4FskZbyix1kkhv3L24GQVWnllLqePfbxZ
v+DXDmXHc1giaAfZ4HcUp6JwlFAPS/WLe1DYC6vxS2i2xbLSjAE5+rgzrNBHAaov
gGnzsbXUhQ8=
=HyGs
-END PGP SIGNATURE-

Re: names to say in late september

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

This was an issue last year.  We've covered the same ground that was 
covered elsewhere last year, including the same proposed names.

Having been awakend by a thunderstorm, I took a little time to check 
on progress over in IEEE.  The latest letter that I found, in 
http://grouper.ieee.org/groups/1363/P1363/patents.html, says:

"... we do not intend to rely on our trademark rights in the RSA 
brand to prevent the use of ... the terms 'RSA public key', 'RSA 
private key', and 'RSA key pair'."

I think we are relatively safe.  I think we are even safer satisfying 
their concerns in their final paragraph by adding explicit language to 
documentation saying:

   "Due to the acrimonious nature of previous interactions, we don't 
   use any products sourced from, licensed from, or endorsed by, 
   RSA Data Security, Inc."

Note that somebody is claiming patents on RIPEMD and SHA1, among many 
other problems.  I suppose that I shouldn't be surprised.  (heavy sigh)

Rodney Thayer wrote:
> However, given the, ah, acrimonious  nature of this corner of this
> marketplace,
> it seems prudent to consider another name.
> 

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOYFxLNm/qMj6R+sxAQHLZQP+OpGPlVHlhd/yLzYo4+kbDUwUypHaZFWT
zCpf+1gRNyMBB1cc2U5CmIN9/i4gnUHOTOb9LJY4GGWHzcl25g87yceTS1rJQu12
wau71YDinBJCbEYTI/VRr1J2XWdT4eIKn2n5NOT+lmhDv8szs3HNCXmOPo9lJQFF
415fSIeeQPw=
=13UZ
-END PGP SIGNATURE-

Re: A proposal for secure videoconferencing and video messaging over the Internet

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

amanda wrote:
> 
> On Wed, 26 Jul 2000, Eugene Leitl wrote:
> > Clearly, you can maintain a secure connection to an anonymous party.
> 
> No you cannot. If Bob is anonymous then it is impossible for Alice to
> know if her secure connection goes to Bob or Mitch. In the classic
> man-in-the-middle attack Mitch impersonates Bob when talking to Alice and
> he impersonates Alice when talking to Bob.
> 
> [Depends on what you mean by "anonymous". If the anonymous party has a
> key he uses (i.e. the equivalent of a "nym") there is no problem at
> all and no need for a CA either... --Perry]
> 
Amanda is correct on technical points, Perry on social points.

Secure key establishment requires an exchange of identification, and 
vise versa.  That's well established in the liturature.

When you have identification, it is not anoNYMous.

Never-the-less, the identification that is exchanged may be a 
pseudo-NYM, and difficult to attach to meat space.  That may very 
well be enough for the application at hand.


> > Authentication and security only touch shoulders when you're
> > trusting the public key server
> 
> You are not supposed to trust key servers. It is the keys that you trust,
> because they are signed by someone you trust (the CA or your WOT).
> 
And I was in a hallway conversation with Honeyman yesterday, where he 
was proposing taking a randomly generated temporary public-key (he 
calls a junk key), establishing it between parties using Kerberos, 
using it to sign a document, and signing the signature via a PKIX 
timestamp.  Throw away the junk key, and you have a time verified 
signature verifiable in the future by a CA, but a completely 
anonymous signer. 

I'll also note that provably secure multicast is an ongoing project 
over at Honeyman's CITI.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOYBz/Nm/qMj6R+sxAQEOOQP/Y8HVpOJ9QOcFUNr+/XcdKjSEipSWpHbA
ivZv/IUgLU0RG/JM/+8x0Bv8NBtglNF4x8qEzR2YK92LKCOESGNhQPSzvnarsdyP
s42X0SFUewV3uXw3Ynn2N703UgnIrbCyZxXGLsvIjLOq3Xn1j9U3Gk/3M7rLsgHw
FhQdqLzdTHY=
=v/1I
-END PGP SIGNATURE-

Re: names to say in late september

[William Allen Simpson]

Rodney Thayer wrote:
> 
> What shall we call
> that-public-key-algorithm-that-will-not-be-patent-protected in late
> September?  we should not use a trademarked or copyrighted term, in my
> opinion.

"The Public Key Algorithm Formerly Known as RSA"

In the usual academic tradition, it should continue to be called after 
the discoverers.  ARS would be nicely alphabetical.  There isn't much 
likelihood of confusion with Agricultural Research Service, Automation 
Research Systems Ltd, or Authorized Remarketing Supplier (checking the 
top google references).

And when you say it, it has a ring of truth about the 20 years that 
we've endured.

Meanwhile, what celebrations are planned?

Is there a conference we should all attend on the 20th/21st?  If one 
was organized, would folks come?

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: Electronic Signatures Yield Unpleasant Surprises

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

"Arnold G. Reinhold" wrote:
> Nothing new here. I often buy stuff on line and only get e-mail
> receipts. My credit card statements are a backup, I suppose. If
> anything the new law will strengthen our case with the IRS.
> 
Possibly, but I also see language in the Act 

   (iv) informing the consumer (I) how, after the consent, the
   consumer may, upon request, obtain a paper copy of an electronic 
   record, and (II) whether any fee will be charged for such copy;

So, what happens when they "inform" you that your statement has a fee? 
Saying, of course, that the new fee was authorized by Congress?

Will lack of a fee be a competitive pressure?  Remember how a few 
years ago _every_ bank began adding statement fees?  Even some credit 
unions began charging.  (I changed credit unions over this issue.)

I expect all ATMs to add a few words to the "Would you like a receipt?"
query, "for only 50 cents?" 

It will be very hard for municipalities to outlaw such ATM charges, 
as the Federal legislation explicitly supercedes state and local laws.


> I am more concerned about all the press coverage that suggests this
> law is about cryptographic signatures, retinal scans and the like,
> when its really about  clicking "I Accept" buttons.
> 
Yeah, CNet blew it again, even after being corrected in the past:
http://news.cnet.com/news/0-1005-200-2179136.html 

I was particularly amused in the WSJ article by Clinton's passphrase: 
Buddy, the name of his dog

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOWC6ctm/qMj6R+sxAQHa6wQAt89V8E4OJI7a0E7A6BZPRij96cgBaoiJ
3EdEr5BiHMB9grZ/1oRjsZ/G3AyeyohT4yD7+VhqZwxEDLFSU6rsYmnuuCmQzv3t
nxEycBIsJKAvDOGS683VutrDMOOMGSccCm3Gifien6O9wJaxHOPqwcPQa7r4HMH0
sNs07PRPCUs=
=ewsh
-END PGP SIGNATURE-

Re: Electronic Signatures Yield Unpleasant Surprises

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Don Davis wrote:
> i'm sorry, but this is a foolish complaint.  their specialty
> is as demanding as ours; why demand that they should master
> our specialty, when we make no effort to master theirs, and
> when we make no effort to help them understand crypto?  
>...  indeed, the crypto community
> goes further, by ridiculing any cryptographer or security
> expert who supports legislative efforts.  we're the ones who
> have screwed this up, not the legislators or their staffers.
> 
I have done my best to "master" theirs for over 20 years.  (Admittedly,
I have gotten some ridicule from the security community, too.) 

In this case, it was deliberate effort by business lobbyists that 
resulted in this language.  I named some.

The original Senate sponsor, Spence Abraham, is from my state, Michigan.  
The rationale given by the staff, namely Kevin Kolevar, was that they 
wanted to keep as close to UETA as possible, since that is the "uniform" 
wording states are adopting.  Of course, the major reason for this push 
was that states _refuse_ to adopt it!

In the enrolled senate bill, the definition was originally:

  The term `electronic signature' means an electronic sound, symbol, 
  or process attached to or logically associated with a record and 
  executed or adopted by a person with the intent to sign the record.

In the house, the definition was changed to:

  The term `electronic signature' means information or data in 
  electronic form, attached to or logically associated with an 
  electronic record, and executed or adopted by a person or an 
  electronic agent of a person, with the intent to sign a contract, 
  agreement, or record.

Note that they killed off the "process" nonsense, and required data! 
Admittedly, it's not perfect, but was the best that folks could 
substitute.  They didn't want to endorse a "specific method", 
partly because of the RSA patent issue.

The house also added privacy language (and a number of other fixes):

  Nothing in this section shall be construed to require the 
  Secretary or the Assistant Secretary to take any action that 
  would adversely affect the privacy of consumers.

The final language adopted in conference committee is a compromise, 
as usually happens, but mostly conforms to the senate (UETA) version:

  The term ``electronic signature'' means an electronic sound, symbol, 
  or process, attached to or logically associated with a contract or 
  other record and executed or adopted by a person with the intent to 
  sign the record.

The next step is signing by the president.  It could be vetoed.  That 
will only happen after a big fuss.  So, make some noise!  Since this 
affects global commerce, international would be appreciated! 

Did the reporter issue a correction?  Time's awasting

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOVfWpNm/qMj6R+sxAQFpogP/UqCDAyPI7Ihqvn7VogWugdHcELMoMrSf
8KvAaBl0Q4LWS1hRHYurgm45H3XTgECiCi7+5pjpOvkPEXWkURmCMDWg4h9gf3wg
mnzPExttk5mLI2bw1hTVx7Xq+qDwb5+1wVKhI8loQ5reQI1y073pscJ3xTAc9yxC
I4ekUTjcNZw=
=sxsE
-END PGP SIGNATURE-

Electronic Signatures Yield Unpleasant Surprises

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Electronic Signatures Yield Unpleasant Surprises

Knowledgeable Internet users might think that the "Electronic Signatures
in Global and National Commerce Act" -- passed overwhelmingly by the US
Congress last week -- would provide virtual world commerce with the same
protections expected in the physical world.

Surprise!  No, that would be "digital signatures", never mentioned in
the Act.  Digital signatures are designed to detect changes in digital
content, and computationally irreversible functions ensure that the
signature belongs to a particular entity.

The Act imposes the language of UETA (the bastard sibling of the
notorious UCITA that has been opposed by the attorney generals of most
states) upon the US as a whole.  


Don't touch that dial (or click that mouse)

Instead, these electronic signatures are a "sound, symbol, or process".
By the simple act of pressing a telephone keypad that makes a sound
("press 9 to agree or 7 to hear this menu again"), clicking a hyper-link
to enter a web site, or clicking "continue" on a software installer, the
consumer consents to be bound to an electronic contract.  

The only protections for the consumer are "a statement of the hardware
and software requirements", and that this legally binding consent is
confirmed "in a manner that reasonably demonstrates that the consumer
can access information in the electronic form that will be used".  This
can be performed by an "electronic agent ... without review or action by
an individual".

Every time a link is clicked, web browsers routinely provide this
hardware and software information, without any user knowledge or
intervention.  For example,
  GET /digsig/ HTTP/1.0  
  Referer: http://www.cdt.org/  
  Connection: Keep-Alive  
  User-Agent: Mozilla/4.73 (Macintosh; U; PPC)  
  Host: www.cdt.org  
  Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*  
  Accept-Encoding: gzip  
  Accept-Language: en  
  Accept-Charset: iso-8859-1,*,utf-8 

Surprise!  The vendor already knows where you've visited previously,
your software version, what kind of computer you are using, the types of
images you can process, that you speak English, and other esoteric
arcana.


Added costs

Using new electronic signatures, will commerce cost less?  It might save
money for the vendor, but it brings new Congressionally approved charges
for the consumer.

Surprise!  If you need a physical copy of the invoice for company
records, or you'd like a printed copy of the manual that describes the
features and operation that motivated your purchase decision, or you
want an actual CD-ROM of the software that you purchased, or an immutable
copy of any other electronic records, the vendor is now authorized to
charge an extra fee.

Surprise!  Many consumers comparison shop on-line, but quit before
purchasing, making their final purchase at a later time in a
conventional manner.  Vendors are now permitted another new fee for
"withdrawal of consent".

According to Congressional staff, this new fee may not have been
intended to be charged until after a consummated transaction.  Such a
limitation is not explicitly stated in the legislation.  It is hard to
imagine that a court would enforce the new fee without an actual
purchase of a product.

However, according to the same staff, this specific language was vetted
with Dell, Gateway, Hewlett-Packard, MicroSoft, and other vendors.  No
consumer advocates were mentioned.


Incredible shrinking wrap

In technical terms, each request and response for an electronic record
is called a transaction.  These requests may be separated by
considerable time, and may even be made from browsing sessions on
different computers.

The Act defines transaction as 

  "an action or set of actions relating to the conduct of business,
  consumer, or commercial affairs between two or more persons"

The Act specifically contemplates that the vendor can specify 

  "whether the consent applies (I) only to the particular transaction
  which gave rise to the obligation to provide the record, or (II) to
  identified categories of records that may be provided or made
  available during the course of the parties' relationship;"

Surprise!  The process of clicking now generates a legal relationship
with a vendor, and can bind the consumer for categories of records. 
This gives legal weight to web site product disclaimers, poor privacy
practices, or installer shrink-wrap conditions, simply by making them
available (perhaps via another URL).

Note the use of future tense in the language: "the electronic form that
will be used", "may be provided or made available".  There is no
guarantee that the records have actually been seen by the consumer
prior to contract.


Binding the consumer

Although consent for the use of electronic transactions is streamlined,
and may already be automated by using standard browsers, vendors
apparently found this is too onerous.  An escape clause is provided:

  "The lega

Re: Extracting Entropy?

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Ben Laurie wrote:
> 
> OK, so if I've got a passphrase of arbitrary length, and I wish to
> condense it to make a key of length n bits (n > 160), what's the
> approved method(s) of doing that?
> 
> I assume it goes without saying that we wish to preserve as much entropy
> as we can, but I'll say it anyway.
> 
Long ago, I had the same problem, and after much discussion about 
preserving entropy, I formulated (for Photuris):

  H(s,p1) || H(s,s,p2) || H(s,s,s,p3) ...

Thus, the entropy from secret (s) is reintroduced in every hash. 
The MD padding (p) has a count of the number of bits (better than a 
leading counter).

The code is easy and pretty efficient (just copy the intermediate 
result before xxxFinal).

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOU7o49m/qMj6R+sxAQG0vAP9FuERLONf4dhDMgZuRROcoChVNisIkVw8
c/dhZtsicot5DDM7Rl2tUcu1uTePQ35Bj19Wf8/MBePYtqAP4J7DU3YRLsYmKCh+
2vcQLQCInoJ9cDyXr5m8ywUj/2u6GFVjofbmG8/uxV6qekqs2LE0mohXeDCL8MVd
oSpNcQdUF1k=
=TMlr
-END PGP SIGNATURE-

Update: legal status of digital signatures

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

OK, thomas.loc.gov put up the text of the revised conference report 
this morning, just in time for the US House "debate" and vote.  It 
was hard to find, being accessed under "bill status" rather than 
"bill text".



By the tone of the self-congratulatory "debate", I think this is 
going to fly right through, even though the conference was 
reportedly very contentious.


 * The privacy language is gone -- absolutely deleted.

 * There is a lot of new "consumer" protection language.  However, 
as far as I can tell, the only remedy is to "vote with your feet"; 
if you don't like the terms, stop using it.

 * If you want an immutable paper version, they can charge you for it.  
Even then, they can change hardware and software terms at any time.

 * There are a lot of automatic exemptions, including UETA, the 
UCITA companion that has no protections what-so-ever.

 * The language from UETA is back (it had been replaced by something 
more sensible in an earlier House version):

 ** This is not about secure digital signatures.  These are 
"electronic signatures", such as a "sound" on a recorder on a phone.  

 ** There is new contradictory language in 101(c)(6) and 106(5); 
thus the "sound" cannot be a voice saying "yes" (which I would have 
thought more identifiable than a touch tone button).

 ** These "signatures" do not involve "signing" anything.  You are 
not even required to have a copy of whatever you thought you were 
agreeing about.  You merely have to "demonstrate" that you have the 
"hardware and software" to "access information":

   (i) prior to consenting, is provided with a statement of the
   hardware and software requirements for access to and retention 
   of the electronic records; and 

   (ii) consents electronically, or confirms his or her consent
   electronically, in a manner that reasonably demonstrates that the   
   consumer can access information in the electronic form that will
   be used to provide the information that is the subject of the consent;

 ** However, they apparently think that this is too onerous, and 
provide:
   (2) ... The legal effectiveness, validity, or enforceability of any
   contract executed by a consumer shall not be denied solely because of   
   the failure to obtain electronic consent or confirmation of consent by  
   that consumer in accordance with paragraph (1)(C)(ii).

 ** And they want to eliminate even that bare bones "burden": 
 
  105(b) ... Within 12 months after the date of 
  the enactment of this Act, the Secretary of Commerce and the Federal
  Trade Commission shall submit a report to the Congress evaluating any   
  benefits provided to consumers by the procedure required by section 
  101(c)(1)(C)(ii); any burdens imposed on electronic commerce by that
  provision; whether the benefits outweigh the burdens; whether the   
  absence of the procedure required by section 101(c)(1)(C)(ii) would 
  increase the incidence of fraud directed against consumers; ...

 ** It can be a "process", such as a click on an Install button, 
making shrinkwrap licenses enforcable!



-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOUfER9m/qMj6R+sxAQFoDQQA04IYEE8aD4G+vmbnrYEm6RZk2Cfsbbsq
HQhpL3iLDpst9BG/uz8Nq9O+jyQEcoihx4sjvMgVI6rhX4VEnEOc7I7ZAFo1s4qX
1aNljDJTwV54GbRkZ35KJQOpHCtxrUtMosp0lhYfi6INDPU/Jxbh8DWmx1E75LPT
v6NXH2q3xB0=
=++FD
-END PGP SIGNATURE-

Re: random seed generation without user interaction?

[William Allen Simpson]

I've been putting a cheap sound card in every machine, not connected to 
any external wires, cp'ing from it on reboot.  Seems to generate a nice 
chunk of randomness, but I've never measured it.  

[EMAIL PROTECTED] wrote:
> 
> So I'm curious about what all methods do folks currently use (on NT and unix)
> to generate a random seed in the case where user interaction (e.g. the ol'
> mouse pointer waving or keyboard tapping approaches) isn't a viable option?
> 

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: Voting systems

[William Allen Simpson]

[I'd like this message to be the end of the voting thread... --Perry]

-BEGIN PGP SIGNED MESSAGE-

I have read the electronic voting messages with some interest.  Many 
of them miss important points about the real reasons for registration 
and validation of traditional physical voting.

But I was most surprised by my friend Perry's preference for physical  
over electronic voting.

(I'm basing this on my experience implementing software to verify 
petition and poll signatures -- a mainstay of my consulting business 
throughout the '80s and early '90s.  My PPP efforts were funded by 
the campaigns of my then Congressman and US Senator, to better 
transfer drivers license and registration information between 
networked machines.  I've been actively involved in electoral 
politics for over 25 years, and my current SO is an elected official.)

Poll watching is a fine thing.  But most polls aren't watched.  More 
frequently, we use poll "closers" to carry the counts back to central 
locations.  The abuses that I've uncovered electronically were hard 
(or impossible) to discern by poll watchers.  

The most common problem is a corrupt clerk or vote tabulating 
organization.  Since the counters usually have an interest in the 
outcome of the election (Michigan county and township clerks are 
elected, too), they are motivated to skew local elections.

The old mechanical polling machines are notoriously unreliable.  The 
root of the problem is the manual transfer of the counts from the 
machine to paper. 

When an aged machine "jams", it has to be cleared.  The official 
tally of intermediate counts is the only tally.  There are many 
reports of suspicious jamming.

Later verifications only occur when the election is challenged -- 
a rarity.  We uncovered a probable fraud using statistical measures 
some 6 years after the election, much too late for verification.  
In other cases, a challenge found the errors before the machines 
could be wiped.

Local elections usually have fewer votes than national.  A closely 
contested local election can be reversed by adding a few dozen or 
hundred votes to each precinct tally for that race -- completely 
undetectably by poll watchers. 

We've found that punched card ballots significantly ease later 
verification, as they are kept for longer periods of time, are not 
wiped for later elections, and are electronically counted.  These 
advantages would be available for electronic voting, too.

Multiple registrations are extremely common.  Once domicile has 
been established in any location (or faked), it is easy to register.  
Many folks simply forget to resign their old registrations as they 
move (or the lazy or corrupt clerks don't process the resignations).

Likewise, deaths are not cross-tabulated with voting registrations.

The signatures were virtually impossible to cross-check until 
recently (using electronic means).  Cheap photocopies (most of the 
leading FOIA cases in Michigan are over access to voter address, 
registration and poll records) and now digital cameras have helped 
a lot.  Before, there simply was no good way to check for duplicate 
names and signatures.

Cross-checking electronic registrations should be much easier, 
and any system that doesn't take such things into account is 
useless.

Meanwhile, the names of voters at polling places are inscribed by 
the poll worker, not by the voter.  This aids readability, but not 
checking that the actual voter arrived, or the correct voter was 
listed.  Here poll watchers can help, but only where the precincts 
are small enough that the poll watcher know the voters.  Michigan 
precincts typically have several thousand voters, because such a 
small proportion actually vote.

Moreover, there have been suspicious reversals of elections by 
absentee ballot (processed entirely by clerks).  Not much a poll 
watcher can do there.

Electronic voting will completely obviate the need for direct poll 
watching.  Instead, we'll need election certification of the 
software and processing by independent third parties.

I don't see how anything about electronic voting will improve 
participation.  That's largely due to the negative tenor of our 
adversarial process.  There's nothing to inspire the voters.  
Instead, it makes them hate the process and the candidates.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOTV2pdm/qMj6R+sxAQFQhAP+O/fmv+fhIl9jv1P/j+Kcrz69CHNF7hEN
fxS+08IscCWPMgyzHtHNa3jDd00Gzb4/w38AVHZKBPYcsHUNiz1b3FcZPhgRPTsx
Ekz+/KAcLEACQF9TMnKtlpVVyOIXUr3v22ouskJKY4JEcwBE7zf3gEsO1dAg31R1
UYLxxM4G9DY=
=Rw/P
-END PGP SIGNATURE-

Re: Critics blast Windows 2000's quiet use of DES instead of 3DES

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

"L. Sassaman" wrote:
> On Wed, 17 May 2000, Dennis Glatting wrote:
> 
> > > Frankly, I can't understand why the IPsec protocol still allows DES. It
> > > should require strong encryption. Having DES in a product these days
> > > makes about as much sense as mandating the usage of ROT13. 
> > >
> >
> > We are waiting for AES.
> 
> So am I correct in assuming you are saying that DES will be disallowed as
> part of the IPsec protocol when AES is finalized?
> 
> This would be good. I still think that DES should be dropped immediately,
> however.
> 

"Steven M. Bellovin" wrote:
> 
> In message <[EMAIL PROTECTED]>, Paul
> C rowley writes: 
> 
> >I'm guessing that they have to have a MUST cipher, and they don't want
> >to change twice, so it makes sense to wait until September and then
> >make AES (or AES primary) the only MUST cipher.
> 
> Correct.
> 
Not historically.  This has been an issue since long before AES was viable. 

When Perry and Phil and I wrote the first IPSec DES RFC in 1995, we 
recommended:

   It is suggested that DES is not a good encryption algorithm for the
   protection of even moderate value information in the face of such
   equipment.  Triple DES is probably a better choice for such purposes.

But the IPSec WG refused to make 3DES an official option.  We had to 
publish as "Experimental".

Since immediately after Deep Crack, Scott Bradner and I have had an 
Applicability Statement draft out for years!  An Applicability Statement 
is a "Best Current Practice" that tells everyone in the Internet what 
is recommended.

The Steering Group (IESG) officially REJECTED Last Call for the IETF, 
saying:

   The Security ADs do not agree with the conclusion "Currently
   deployed equipment using DES should be eliminated, or upgraded to a
   more robust algorithm and key length." Instead they believe that
   new applications should use stronger technology and that efforts
   should be made to gracefully phase out the use of DES. The IESG
   therefore considers summary elimination proposed by your document
   inappropriate

   We are also not prepared to move RFC-2419, RFC-2405, RFC-1829 to
   Historic status at this time.

   If the relevant Working Group makes a request to the IESG to move its 
   RFCs to Historic Status, the IESG will consider it.

FYI, the PPP WG _DID_ ask!  Here's the current history section from the 
latest (unposted) draft:

History

   On July 20, 1998, William Allen Simpson, with the concurrance of
   Perry Metzger and Phil Karn, asked that their DES encryption Proposed
   Standard [RFC-1829], and the related PPP DES encryption Proposed
   Standard [RFC-1619], be declared Historic (removed from the Standards
   Track), and recommended DESX [SB97] and Triple-DES [SMKD97] as
   interim Proposed Standards until the selection of AES.  With the
   assistance of Scott Bradner, this Applicability Statement was written
   to reflect the recommendation.

   Instead, the IESG approved RFC-2405 (November 1998) and RFC-2419
   (September 1998) for publication as Proposed Standards.

   On March 18, 1999, the Security Area Advisory Group overwhelmingly
   approved removal of DES from the Standards Track, and recommended
   Triple-DES as mandatory to implement.  This Applicability Statement
   was updated to reflect the recommendation.

   Instead, the IESG approved RFC-2574 (April 1999) for publication as   +
   Proposed Standard.+

   On November 8, 1999, the Point-to-Point Protocol Extentions Working   +
   Group overwhelmingly approved removal of DES [RFC-2419] from the  +
   Standards Track, and recommended Triple-DES [RFC-2420] as mandatory   +
   to implement.  On November 10, 1999, this recommendation was  +
   forwarded to the IESG Internet Area Directors by the Working Group+
   Chair.+

   Unfortunately, in a communication dated December 3, 1999, the IESG+
   officially refused to publish this document as an Applicability   +
   Statement, stating they are "not prepared to move RFC-2419, RFC-2405, +
   RFC-1829 to Historic status at this time."






-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBOSWLedm/qMj6R+sxAQEALgQAo+JYQjKU5H5W8QcPUjNzCmf7tRpGWv1w
v5lRXkzYs0Vlgfe/im/dm2fdA9T0YUmwcM0CqCY9FlC66iHeyKbeW69DhjvYk//i
QF3TqovutleLPawCzJil58dF8UQNVT2Ph2XET7SuA167haL33LSNTARqZWkcg1gZ
B0gd935BFeU=
=VaLi
-END PGP SIGNATURE-

Re: Perfect Forward Security def wanted

[William Allen Simpson]

In response to Perry's editorial comment:

William Allen Simpson wrote:
> [I'm not sure I like this definition, Bill. It would make exchange of
> random session keys by RSA a form of PFS, which it most certainly
> isn't. The definition from Diffie et al given in another message
> really conveys the flavor properly. --Perry]
> 
An exchange of random session keys by RSA provides Forward Secrecy, 
assuming the keys are truly random.  The disclosure of one key won't 
reveal previous keys.

Once the private RSA key is _destroyed_ PFS is attained.

Note that it is the inability to recover secret information that 
provides "perfect" forward secrecy, moving from "hard" to "impossible".

I'll have to look up the '90 and '92 references when I get home. 

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: Perfect Forward Security def wanted

[William Allen Simpson]

I've been using the following (based on references dating back to 
Diffie in '90):

 Forward Secrecy:

  Session-key generation values should not be directly derived from the 
  values of any previous session-keys.  Knowledge of a previous session 
  key will not permit derivation of any later key.  The generation 
  pseudo-random function data values are carefully arranged to avoid 
  related key analysis.

 Perfect Forward Secrecy:

  When initializing pseudo-random function data values are periodically 
  destroyed, and this destruction is sooner than the feasible recovery 
  of the key (computationally) from the publically exchanged values,
  or recovery (by theft or coercion) from the parties, the derived 
  session-keys are never recoverable.

[I'm not sure I like this definition, Bill. It would make exchange of
random session keys by RSA a form of PFS, which it most certainly
isn't. The definition from Diffie et al given in another message
really conveys the flavor properly. --Perry]

"Arnold G. Reinhold" wrote:
> 
> Can anyone point me to a good definition of "Perfect Forward Security"?

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

[Fwd: Export Administration Act of 1979]

[William Allen Simpson]

It was reported that Clinton was keeping the export controls going by 
executive order, even tho' congress had failed to re-authorize the 
sunsetted legislation.  I asked my local congress-critter about it, and 
here is the response.  I found it enlightening.

Now, they are checking to see whether there was any _explicit_ funding
for the export controls.  Perhaps that could be blocked, as a money-
saving initiative.

The last line might be taken as a call to action -- we need to watch.

   Original Message 
 If congress did not
accept his action, it could have legislated his executive order out of
existence. Certainly, when the Republicans took control of congress in 1995,
they could have rescinded his order if they did not want it to operate.
Since 1994, the 104th, 105th and 106th congresses have chosen to allow the
Export Administration Act to exist under emergency authority.

Many, possibly, hundreds of programs whose authorization has run out, are in
existence. Congress frequently appropriates funds for these programs. For
example, the National Endowment for the Arts' authorization ran out. Even
though many in the current majority would like to eliminate the NEA, each
year it is funded because a majority of all members want to. It is not
brought up for reauthorization because no one wants to engage in the fight.

The authorization for the Great Lakes Environmental Research Lab has expired
also. Even so, it is funded every year. 

Congress failed to reauthorize the Federal Aviation Administration. However,
it continues to be funded. Reauthorization legislation was up last year, but
no consensus was reached on certain key issues.

Congress often lets programs ride until a consensus can be reached. There is
some talk that the EAA may be reauthorized this year.

Re: [Fwd: Export Administration Act of 1979]

[William Allen Simpson]

LOTT EYES CLOTURE FOR EXPORT ADMINISTRATION REAUTHORIZATION:
Senate leaders have yet to determine this week's schedule, but
Senate Majority Leader Trent Lott, R-Miss., today said he would like to
move tomorrow or Wednesday to a bill (S 1712) to reauthorize the Export
Administration Act. The measure would rewrite the Cold War-era law
regulating exports with dual commercial and military uses. Lott said he may
have to file cloture to proceed because several senators object to the
bill, contending that it could weaken national security. Bill sponsor Phil
Gramm, R-Texas, and several committee chairmen met Friday to try to reach a
compromise, but aides said they still have some work left. "We should move
forward on this even if there are concerns about it," said Minority Whip
Harry Reid, D-Nev. A cloture vote on either the bill or the motion to
proceed could occur Wednesday if cloture is filed today.

Re: Copy protection proposed for digital displays

[William Allen Simpson]

Hmmm, I didn't see any:

"Xing, you'd better do a pretty good job of securing your keys, as if 
your systems are compromised you'll wear the financial consequences."

What I saw was keys compromised, sue the folks that tell anyone about 
it


Ian Farquhar wrote:
> Look at it this way:
> 
> "Sony, you'd better do a pretty good job of securing your keys, as if
> your systems are compromised you'll wear the financial consequences."
> 
> There is already precident for Sony (and many others) signing up to
> a very similar scheme: DVD's CSS.  

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: The problem with Steganography

[William Allen Simpson]

Catching up on the thread, the comments about fitting the stego into the 
image reminded me of http://www.outguess.org/ by Niels Provos.  Looks like 
he's a few months ahead of you

Marc Horowitz wrote:
> 
> Rick Smith <[EMAIL PROTECTED]> writes:
> 
> >> Thus, a 'good' stego system must use a crypto
> >> strategy whose statistical properties mimic the noise properties of the
> >> carrying document. ... So, can't we detect the presence of stego'ed data by
> >> looking for 'noise' in the document that's *too* random?
> >>
> >> ... Once we replace those bits
> >> with data, the bits will have serously random statistical properties. So,
> >> we can detect stego'ed data if the implementation uses any well known
> >> strong encryption algorithm.
> 
> If the picture was taken by an actual camera, the least significant
> bits will be random due to the nature of the way CCDs work in the real
> world.  They might be biased, but it's not very hard to bias a
> "random" data stream.  

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: draft regulations?

[William Allen Simpson]

"Steven M. Bellovin" wrote:
> > I was about to make a snide comment that they're just endorsing open source
> software -- but is there any definition of "other restriction"?  Does the GPL
> count?  Are they trying to ban any publication of anything that isn't flat-out
> public domain?  And if something is flat-out public domain, how can the
> "exporter" impose the viral restrictions?  For that matter, what is "export"?
> Posting something to Usenet?  Putting it up on a Web page or FTP server?  The
> act of downloading it?
> 
These are excellent questions.

I think the GPL counts.  I think that BSD counts.  I have no idea how 
the exporter imposes the viral restrictions, but I suspect that it 
could result in prosecution -- "a compare shows this line of code is 
identical to that line of US origin code, guilty as charged."


"Salz, Rich" wrote:
> I think they want to make sure that if some non-US package
> (openssl being the example most obvious to me) picks it up
> that it doesn't suddenly become "free."  So it's not the GPL,
> really, but more like the old BSD license.
> /r$
What I meant is, I'd like to contribute code to FreeSWAN, or OpenSSL, 
or whatever, but the inclusion of a single line of my code will make 
the entire thing subject to EAR regulation.  Worse, a single line of 
code that "looks" like a line I published will subject the whole thing 
to regulation.  Means we cannot publish _anything_ for fear of damaging 
the efforts of our freinds.  Not good.

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

draft regulations?

[William Allen Simpson]

>From: Alan Davidson <[EMAIL PROTECTED]> 
>The draft regulations are available now on CDT's web site at:
>
> http://www.cdt.org/crypto/regs112399.shtml
>

  (2) Source code released under this provision remains of U.S. origin 
  even when used or commingled with software or products of any origin, 
  and any encryption product developed with source code released under 
  this provision is subject to the EAR (see Section 740.17).

Looks like they are reinventing the GPL, except to infect other sources.

  (4)(i) for encryption source code (including published source code 
  which is subject to proprietary commercial agreements or other 
  restriction), any new product developed with this source code must be 
  classified by BXA (see paragraph (e) of this section) prior to 
  re-export.

A little slap in the face to PGP -- and may make GPG code classifiable.

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: PGPphone sources released.

[William Allen Simpson]

It is more important to look at both sources, and document the protocol(s), 
for interoperability!  Enough religiousity on source licenses.  Let's get 
together and do it!

Ted Lemon wrote:
> 
> > SpeakFreely (http://www.speakfreely.org) is already open source, so it
> > sets a minimum bar on the restrictions you can expect to be able to
> > set on the distribution of a freeware encrypting telephone package.
> 
> Precisely.   Too bad, though - I'd like to see PGPphone Open Sourced.
> 
[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: more re Encryption Technology Limits Eased

[William Allen Simpson]

Zombie Cow wrote:
> Or start producing Open Sourced CPUs and motherboards.
> 
> IBM has an Open Source PPC motherboard, and here's an
> article referring to an Open Source CPU by Sun:
> 
> (Well, they're not really "Open Source", but still, open enough..)
> (Search www.techweb.com for the source URL, I don't have it here.)
> 
I rather like this direction.  The PowerPC chips seem well suited to
practical crypto on firewalls and servers.  They have good support for
both little endian (think MD5), and big-endian (think SHA1), and the
new AltiVec stuff may be great for running a large number of
Diffie-Hellman operations.

On the other hand, having the actual CPU source, we could stop worrying
about Intel's ID gaffs, and RNG support, and "know" it is built correctly.

Either way, the crypto community needs to come together and have a plan!



On the original topic of this thread, I talked to my congresscritter today,
and she'll talk to Zoe Baird and others.  I think she understood the
implications of the secret court evidence.  And she was very surprised to
learn about the quotes about no "relaxation" from the press conference.

They're on recess at the moment, from the hurricane, so this is a good time
to catch them at the local office.  Talk to yours!  Especially if they were
signed on as co-sponsors of SAFE (look it up in Thomas or thru CDT).

Again, the crypto community needs to educate (as best we can) the
legislators, to dispel some of the murk that's coming down from the
administration.  Personal contact would do a lot for our community.

You need to think of a good local hook to get their attention, tho.
Some of mine were:

 - That Detroit teachers strike 2 weeks ago was technically illegal,
   even though they had no contract.  Our state law requires that they go
   to work even without pay.  They are "lawbreakers", and their cell phones
   could be tracked and calls recorded, and their computers searched to
   uncover the "conspiracy".  (As the former A2 school board president,
   she got that right away.)

 - Do we trust the same people that lied to the Attorney General about
   snipers and use of incendiaries for Waco, with telling the truth and
   always getting proper warrants?  Haven't we had this problem before
   with J Edgar, civil rights, union busting, and secretly spying on
   congress members?

 - We just learned a few weeks ago that every copy of Windows has a secret
   NSA key.  We don't know why.  Remember the Lotus Notes secret NSA key
   fiasco that got us in trouble with the Swedish government?  How can we
   ever compete, when nobody trusts our software?

 - The prohibition against revealing key recovery techniques could make
   me a criminal.  Do you want to see me go to jail?

 - We have a whole lab of people that break smart cards and such at U-Mich.
   Should they go to jail?

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: more re Encryption Technology Limits Eased

[William Allen Simpson]

Declan McCullagh wrote:
> 
> Lucky, actually not everyone missed it. It's our top story on Wired News
> this morning.
> 
> http://www.wired.com/news/news/politics/story/21810.html
>   Decoding the Crypto Policy Change
>   3:00 a.m. Why did the White House suddenly change its mind on
>   regulating encryption? It couldn't be because the NSA has
>   changed its spying agenda. Or could it? A Wired News
>   perspective by Declan McCullagh.
> 
> -Declan
>
Read your story, and it's pretty good, but I also read your transcript
last night.  So, I don't understand what limits have been eased?



The transcript says:

Q It isn't relaxation?

MR. HAMRE: Actually, I don't think so.  I think it's a very different approach
to the export problem.  The path that we were on before was a very complex
path. ... But we were going to have to do that anyway, and we think this is going to
be a much better process for us.  It's not a relaxation.  It's really a very
different approach.

Q Ms. Reno, would you describe this as a relaxing of restrictions?  And if so,
how can you possibly support it after having opposed it for all this time?

ATTY GEN. RENO: What we did approximately a year ago is to meet with industry.
We talked to them in a very full and frank way.  We said, together let's look at
it.  They sympathized with our law enforcement responsibilities.  And they said,
if we can work together, they suggested the concept of a technical support
center; we can, I think, according to the people that were there, address the
problem.

In the interim, we have had the opportunity to have those discussions, to expand
on that dialogue, and I think we will be able to.

Q Why wouldn't you consider this a relaxing of restrictions on encryption?

ATTY GEN. RENO: No.



For example, I have a set of source code for Photuris in KA9Q.  It is an
authentication only version that I created during the window of
opportunity that John Gilmore brought us for DNS Sec.  But, the window
closed when the Feds reversed themselves.  It makes more than 64 bit keys.
It supports 1024 bit D-H, and would be easily modified to larger sizes.

Walnut Creek won't put it on the MSDOS CDROM.  They don't want to apply
for review, track sales, or any of the other things required.  I've
been encouraged to put it on the net, but the sites that I might use
won't allow it.  They cannot afford the Fed confiscation risk.

I've already endured an FBI investigation for treason, 8 years of IRS audit
and resulting 2 Tax Court cases (I substantially won both of them at high
cost to myself) over my earlier net release of PPP CHAP.  (Apparently,
my code showed up in the old Societ Union.  Big surprise.)  They
wouldn't believe I'd given the code away for free, and kept searching
for "unexplained" income right up to the court dates.

So, this is not theoretical for me.  What exactly has eased?  How does
this "different approach" make life easier for me?

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

semantics of /dev/{u}random

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Catching up, and after talking with John Kelsey and Sandy Harris at
SAC'99, it seems clear that there is some consensus on these lists that
the semantics of /dev/urandom need improvement, and that some principles
of Yarrow should be incorporated.  I think that most posters can be
satisfied by making the functionality of /dev/random and /dev/urandom
more orthogonal.

/dev/random would be essentially the same as today:
 * provide TRNG stream to kernel/system-wide processes
 * maintain entropy "accumulator" pool(s)
 * estimate "available" entropy
 * block when more requested than available

/dev/urandom would be updated:
 * provide PRNG stream to userland processes
 * counter mode
 * non-blocking
 * fast re-seed in smaller chunks periodically
 * slow re-seed in large chunks when TRNG is "full"
 * force ("explicit") re-seed function at critical times

By dividing the responsibilities, each can be better analysed, and
future changes made without disturbing applications.

There does not seem to be consensus whether to limit /dev/random to
"rw---", as this might affect current applications.  I think that
we should bite the bullet, and make this change, to make future changes
more clean and prevent "entropy exhaustion" attacks from userland.
Consider this as a security bug fix for a known attack.

I suggest that fast re-seed occur when estimated new entropy (since last
fast re-seed) from all sources is 128-bits, but that only 64 bits be
used.  This is different than Yarrow-160, as a concession to the
blocking nature of /dev/random.  Leaving half the entropy will allow a
build-up to the slow re-seed, and accomodate other uses of /dev/random.

I suggest that slow re-seed occur when estimated new entropy (since last
slow re-seed) from all sources is 320-bits, with at least TWO sources of
160-bits each (see Yarrow-160 section 5.4), but that only 160 bits be
used.

I suggest that the force re-seed function be rewind(), and that only
min( available-bits/2, 64-bits ) be used, counting as a fast re-seed.

The re-seed threshholds probably have to be implemented in /dev/random,
requiring a close coupling with /dev/urandom.  But as long as the
defined semantics are clearly delineated, details can more easily be
changed transparently.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBN7bHjtm/qMj6R+sxAQH9iQP/bLCHCV5LrkehICGQzoGchC8lB0OL6lRC
Ut4uDxUZ6/zGSP4nAnwE3MqPuNOf2R16y90CR6LwsF9kPI9yr90SbCJL/aaJsXI7
xilXSdYAyatfZd3ETWzBmuYwdG63Gchxu6v2xU7NqVPIvy9q1Xz8hhaAFEFgCmml
Ee0RCu12bDw=
=4XF/
-END PGP SIGNATURE-

questions on AES analysis

[William Allen Simpson]

I know I'm a bit out of the loop, as I have not been studying the AES
submissions like the rest of you, but a couple of questions come to mind
on reading the meeting reports.

 1) Does the power analysis apply to all smart cards, or only those that
draw from a reader?

The reason that I ask is I know of a project where they want to
build an entire IPv6 stack into a smart card, with kerberos and
IPSec.  But, I believe that the card has its own power supply and
antennae.  What are the constraints?

 2) What's this about patenting data dependent rotations?

I certainly used data dependent rotations in my "Cipher Block
CheckSum" (CBCS) internet-drafts, and discussed it on the IPSec
mailing list as far back as '94.  (It's just a modification on the
theme of CBC, with an extra key added, bit counted, and rotated; a
later version has two keys and two rotations.)

I've plenty of old printouts of using the CDC population count and
rotate instructions for checksumming as far back as mid-70s.  Not
precisely "cryptography", but ought to be related, as we used it for
both hashing and integrity.

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: references to password sniffer incident

[William Allen Simpson]

Catching up on email, I will point out that every major service provider
is probably compromised to one degree or another as frequently as 3
times per year from terminal rooms.  For example, in addition to Usenix
meetings: IETF meetings, NANOG meetings, and every other computer
meeting or show that hosts an unsecured unswitched local net

At IETF, I've certainly known folks that have snooped the traffic from
the terminal room.  This is routine, over the past 5-6 years.  The last
time that I went (Chicago), such folks discovered that there was only
one person on the net using IPSec (they tracked it down to me).  They
found nobody even using OTP.

(heavy sigh)  We go to all the trouble of designing these security
techniques, but then don't use them in our own production environments!

These were security folks, and I'm pretty sure they didn't save the
passwords after laughing at them -- but anyone else in the room could.
Remember, we have a lot more "unknown" folks attending.

Meanwhile, I know that Merit and UMich reorganized the backbone topology
a few years back after some major servers were compromised.  Now, most
traffic flows over links with no machines other than routers.  General
purpose servers are segregated, and on switched links to the extent
practical.

That doesn't help the dorms, or other public access unswitched networks
on campus.  And with MediaOne finally deploying cable access this year
in Ann Arbor, I'd expect the whole kit and kaboodle to get worse before
it gets better!


> Date: Tue, 09 Mar 1999 17:19:24 +1100
> From: Greg Rose <[EMAIL PROTECTED]>
> I had no idea there had been so many, so well hushed up! MILNET, JANET (4
> independent incidents in the UK in Q3 1995 alone), Panix and other ISPs,
> several universities, the USENIX terminal room, ...
>
[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

FBI secret police FAQ#1

[William Allen Simpson]

This has gotten forwarded to many groups, and I have been overwhelmed 
by the response.  Here are the answers to several of the most frequently 
asked questions, so that I don't have to answer so many private messages.

 1) Why ask for the FBI records?
 2) Why were the records kept secret?
 3) How to ask for FOIA records?



At the Columbus IETF meeting in March 1993, a couple of PPP working group 
members told me that the FBI had come and questioned them for a "treason" 
investigation.  My own parents had been contacted (the agent left a card).  
According to neighbors, my residence had been staked out for weeks.  As 
a consultant, I travel a lot, so they were disappointed.

Also, the IRS started a 7 (now 8) year investigation of my tax records, 
citing a criminal investigation.  This is still ongoing today -- it 
takes years to work through the courts.  I have "substantially 
prevailed" on every issue in these cases.

Through the grapevine, John Gilmore (whom I had not yet met) told 
Phil Karn that I ought to request my records through the Freedom of 
Information and Privacy Acts.  I requested the records from both the 
FBI and IRS.  After several years of repeated requests, and a refusal 
to provide those records under Discovery during the court cases, the 
IRS gave me some of my records last June, and the FBI apparently was 
examining their records at about the same time (May).  In both cases, 
they only filled part of the requests.



The folder title page says:

  Subject: William Allen Simpson
  File: Classified File Number

The FBI cover sheets read as follows (special typed paragraph):

  "The enclosed documents responsive to your request are exempt from 
  disclosure in their entirety pursuant to the Privacy Act, Title 5, 
  United States Code, Section 552(a), subsection (j)(2).  However, 
  these records have been processed pursuant to the Freedom of 
  Information Act, Title 5, United States Code, Section 552, thereby 
  affording you the greatest degree of access authorized by both laws."

subsection (j)(2) reads:

  "material reporting investigative efforts pertaining to the 
  enforcement of criminal law including efforts to prevent, control, 
  or reduce crime or apprehend criminals;"

As explained by others:

  G-3: Assuming a .mil-like hierarchy, G3 would be Operations -- G1 is 
  Personnel and Admin, G2 is Intel and Security, G4 is Logistics.  

  OADR: Originating Agency's Determination Required, which means the 
  FBI didn't generate that information, some other agency did, and 
  they're the ones who get to make classification determinations 
  regarding it. 

I understand these indications to mean that the various agencies are 
hiding behind one another, probably requested by the "security" part 
of an organization of the "operations" part, the very source of the 
file is secret -- and that they interpret the law to mean that this 
material is forever secret, by simply claiming that this is an 
enforcement of criminal law, even though no criminal acts were 
ever discovered.

I've started to scan in the documents.  You can view the first two 
pages that they've given me (clearly not the real first two pages, 
as these pages reference earlier dates), at the "Proceedings of the 
Institute for Obscure Studies": http://potifos.com/was/

(Hopefully, this will not get my freindly lawyer in too much trouble.)



The initial roadblocks in submitting a FOIPA request turned out to be 
(1) finding where to submit it, and (2) giving them lots of personal 
identification.  They want it to be notarized, include a social security 
number, and be accompanied by a copy of a photographic identification, 
such as driver's licence.  AFAIK, none of this is required by the statute, 
but both FBI and IRS kept returning my requests.

I laboriously found the FBI offices that I used, in the local phone 
books, and from the rejection letters.  Glen L. Roberts, editor of 
Full Disclosure, has a good list on-line.  I wish I'd known about it 
when I started:  http://www.glr.com/fbiform.txt

The FOIPA statute requires that they answer within 20 days.  In my case, 
each time a year or so had gone by, they sent me a letter asking whether 
I still wanted the information.

Here's what my FBI request looked like.  Replace with your information. 
Don't forget to get each copy notarized as you send them out


Freedom of Information and Privacy Act Request

Director, Attention FOIPA
FBI Headquarters
J Edgar Hoover Bldg  
9th St & Pennsylvania Ave NW
Washington DC 20535

Special Agent in Charge, FBI, Attention FOIPA
P O Box 2118
Detroit MI 48231

Special Agent in Charge, FBI, Attention FOIPA
200 E Liberty
Ann Arbor MI 48104
313-995-1310

Special Agent in Charge, FBI, Attention FOIPA
P O Box 14195
Lansing MI 48901
517-487-1850

Special Agent in Charge, FBI, Attention FOIPA
2 North

Re: Large Primes

[William Allen Simpson]

> From: Wei Dai <[EMAIL PROTECTED]>
> This code is kind of hard to understand.

More comments about construction.  Good idea.

One of the main reasons for the design was to find as many prime
candidates as possible in one pass, rather than going through all the
work for only one prime, as the various libraries do.  Photuris can
select moduli from a frequently changing list, a design feature intended
to discourage anyone from bothering to analyze any particular modulus.


> I couldn't figure out why you're
> using three sieves (large, small, and tiny).

Tiny is for primes from 2 .. 2**16-1.

Small is for primes from 2**16 .. 2**32-2**16.  It is derived by
applying the tiny sieve.  Saved memory, so that as much memory as
possible could be used for the large sieve.

Large is the large candidate sieve, and is derived by applying the small
sieve.

Experiment found that sieving as much as possible has a significant
reduction of computation effort in the Miller-Rabin.  Pushing the small
sieve from 2**24 to 2**32 cut the time for finding 4K-bit primes on my
machine from a week to a weekend.


> Also, your sieve appears to
> sieve candidates for p that are 3 mod 4, but you only need to sieve
> integers that are 11 mod 12.
>
Clever!  That would save space in the bit array, at the expense of
additional computation (a shift right 2 being fast compared to mod 12).
Just skipping evens (3 mod 4) was merely more obvious.


> You might want to take a look at the safe prime generation code in
> Crypto++ 3.0 (see the first constructor of PrimeAndGenerator in
> nbtheory.cpp). The sieving code there is influenced by Colin Plumb's
> bignum library.
>
Although not a fan of C++, I will take a look at the recently announced
code.  Thanks!

[EMAIL PROTECTED]
Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

Re: Large Primes

[William Allen Simpson]

> Does anybody know of a source for large (1000+ bit) STRONG prime
> numbers?
> Generating software or archives would be helpful.
>
There are probably quite a few out there, but here is what Karn and I
worked up over the years to generate safe moduli for Photuris -- a pair
of programs: qsieve.c is memory intensive, qsafe.c is cpu intensive.  It
uses an intermediate and final output file format that was discussed on
the photuris mailing list.

This generates "safe" primes, rather than "strong" primes.

I meant to put this in a RFC someday, but it would be nice to know
whether I'd done something wrong first  Any problems/suggestions?

qsieve.c:

/* Sieve candidates for "safe" primes,
 * suitable for use as Diffie-Hellman moduli;
 * that is, where q = (p-1)/2 is also prime.
 *
 * This is the first of two steps.  This step is memory intensive.
 *
 * 1996 May William Allen Simpson
 *  extracted from earlier code by Phil Karn, April 1994.
 *  save large primes list for later processing.
 * 1998 May William Allen Simpson
 *  parameterized.
 */
#include 
#include 
#include /* after stdio */

//#define SMALL_CHECK   1
//#define LARGE_CHECK   1


/* Chosen for commonly available machines with at least 12 MB of
 * available main memory.  Using virtual memory can cause thrashing.
 * Therefore, this should be the largest number that is supported
 * without a large amount of disk activity -- that would increase the
 * run time from minutes to days or weeks!
 *** Do not increase this number beyond the unsigned integer bit size.
 *** Due to a multiple of 4, it must be LESS than 128 (yielding 2**30 bits).
 */
#define LARGE_MEMORY(12UL)  /* megabytes */

/* Constant: When used with 32-bit integers, the largest sieve prime
 * has to be less than 2**32.
 */
#define SMALL_MAXIMUM(0xUL)

/* Constant: can sieve all primes less than 2**32, as 65537**2 > 2**32-1.
 */
#define TINY_NUMBER (1UL<<16)

/* Ensure enough bit space for testing 2*q.
 */
#define TEST_DOUBLER(3) /* 2**n, n < 5 */
#define TEST_LIMIT  (LARGE_MEMORY << ((18 - 6) - TEST_DOUBLER))
#define TEST_MAXIMUM(TEST_LIMIT < (1L<<16) ? TEST_LIMIT : (1L<<16))
#define TEST_MINIMUM(1L << 6)

/* Bit operations on 32-bit words
 */
#define BIT_CLEAR(a,n)  ((a)[(n)>>5] &= ~(1L << ((n) & 31)))
#define BIT_SET(a,n)((a)[(n)>>5] |= (1L << ((n) & 31)))
#define BIT_TEST(a,n)   ((a)[(n)>>5] & (1L << ((n) & 31)))

typedef unsigned long int   uint32; /* 32-bit unsigned integer */

uint32 *LargeSieve;
uint32 largewords;
uint32 largetries;
uint32 largenumbers;
uint32 largebits;
MP_INT largebase;

uint32 *SmallSieve;
uint32 smallbits;
uint32 smallbase;

uint32 *TinySieve;
uint32 tinybits;


/* Sieve out p's and q's with small factors
 */
void
sieve_large( uint32 s )
{
uint32 r;
uint32 u;
uint32 v;

#ifdef  SMALL_CHECK
printf("%lu\n",s);
#endif
largetries++;

/* r = largebase mod s */
r = mpz_fdiv_ui(&largebase,s);
if(r == 0)
{
/* s divides into largebase exactly */
u = 0;
}
else
{
/* largebase+u is first entry divisible by s */
u = s - r;
}

if ( u < largebits * 2 )
{
/* The sieve omits p's and q's divisible by 2,
 * so ensure that largebase+u is odd.
 * Then, step through the sieve in increments of 2*s
 */
if (u & 0x1)
{
/* Make largebase+u odd, and u even */
u += s;
}
/* Mark all multiples of 2*s */
for ( u /= 2; u < largebits; u += s )
{
BIT_SET(LargeSieve,u);
};
}

/* r = p mod s */
r = (2*r+1) % s;
if(r == 0)
{
/* s divides p exactly */
u = 0;
}
else
{
/* p+u is first entry divisible by s */
u = s - r;
}

if ( u < largebits * 4 )
{
/* The sieve omits p's divisible by 4,
 * so ensure that largebase+u is not.
 * Then, step through the sieve in increments of 4*s
 */
while (u & 0x3)
{
if ( SMALL_MAXIMUM - u < s )
{
return;
}
u += s;
};
/* Mark all multiples of 4*s */
for ( u /= 4; u < largebits; u += s )
{