307 digit number factored

[Anne & Lynn Wheeler]

StealthMonger wrote:
> This would destroy the protection of one who depends on off-line,
> message-based communication for self-defense.
> 
> Such a person may create and maintain a persistent pseudonym through
> untraceable chains of random latency, anonymizing remailers which
> thwart traffic analysis through mixing.
> 
> On-line, connection-based communication has low latency and can be
> traced by traffic analysis.

re:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored 


the credential/licensing/certificate paradigm was certification of strangers
who have never before communicated before ... and there was no timely, available
mechanism for providing information about the other party (aka the analogy
of letters of credit/introduction from sailing ship days and before).

parties with previous relationship can have available information about each
other based on prior relationship ... or strangers in first time communication
may have access to timely sources of information about the other party.

the issue wasn't that the offline stranger paradigm didn't exist ... it just
was a rapidly disappearing scenario ... aka digital certificates were somewhat
modeled after the sailing ship "days" letters of credit/introduction for
the early 80s offline email scenario for first time communication between
complete strangers ... dial-up local electronic post-office, exchange email,
hang-up ... and then potentially faced with first-time email from total stranger.

while digital certificate wasn't as high a quality information paradigm as
real-time, online ... in this particular scenario, it was better than the
alternative ... nothing.

the issue isn't eliminating digital certificates for the situations 
where they may be appropriate ... it is eliminating digital certificates
for uses where they are obsolete, never intended for, redundant and/or 
superfluous. For all the situations where digital certificates 
and PKI aren't applicable (or redundant and superfluous) they tend to represent
and extraneous and unnecessary business cost providing little or no added
value.

in the wake of some of the original stuff (w/SSL that is frequently no referred
to as electronic commerce) there was some investigations that looked at
adding digital certificate kinds of processing to existing real time payment
transactions
http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored

.... some of the comments was that adding such digital certificate processing would
bring payment transactions into the modern era. Our observation was that
reverting to an offline PKI, digital certificate processing paradigm would
set back real-time payment transactions several decades. That if you
were doing real-time payment transactions that online, timely processing
had significantly higher quality information processing ... real-time status
of public key onfile in the account record as well as aggregated information ...
recent payment transaction patterns, current balance and/or credit limit, etc.
It was in the wake of that series of exchanges that you saw OCSP work start
in IETF.

We observed that not only was the stale, static digital certificate addition
to real-time payment transactions redundant and superfluous ... that the typical
proposals of the period represented a factor of 100 times in payload size bloat
(enormous payload cost addition providing no added benefit) as well as the
redundant and superfluous digital certificate processing increased real-time
payment transaction processing by nearly a factor of 100 times. Misc. past
posts mentioning enormous redundant and superfluous stale static digital certificate 
added overhead
http://www.garlic.com/~lynn/subpubkey.html#bloat

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com