Re: 307 digit number factored

2007-05-26 Thread 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 [EMAIL PROTECTED]


Fwd: Study on the standardisation aspects of eSignatures

2007-05-26 Thread Stefan Kelm
from the 'yet another study on signatures of the month' list:


Von: isss-forum - CENORM created 6 March 98
[mailto:[EMAIL PROTECTED] Im Auftrag von Van den Berghe Luc
Gesendet: Freitag, 18. Mai 2007 09:00
An: [EMAIL PROTECTED]
Betreff: Re: Study on the standardisation aspects of eSignatures



Dear Forum member,



Please be informed that:



For the European Commission, SEALED, DLA Piper and Across Communications are
currently conducting a Public Survey on eSignatures standardisation aspects.
This online survey aims to establish objective findings reflecting the
market needs in this area. We urge you not to miss this opportunity to make
your own contribution to a revamped eSignatures standardisation scheme for
Europe. www.esstandardisation.eu http://www.esstandardisation.eu/



___

CEN - European Committee for Standardization

Luc Van den Berghe

Unit Manager, Pre-Standards
Rue de Stassart, 36
B-1050 Brussels
tel: +32 2 550 09 57
fax: +32 2 550 08 19
E-mail:  mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
Website:  http://www.cen.eu www.cen.eu
-- 



Security Awareness Symposium 12.-13.06.2007 KA/Ettlingen
http://www.security-awareness-symposium.de/

Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Ettlinger Strasse 12-14, D-76137 Karlsruhe
Tel. +49 721 255171-304, Fax +49 721 255171-100
[EMAIL PROTECTED], http://www.secorvo.de/
PGP: 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

Mannheim HRB 108319, Geschaeftsfuehrer: Dirk Fox

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


Re: crypto maxims

2007-05-26 Thread Richard Salz
 I have posted my ideas on defensive use of crypto here:
 
 https://www.subspacefield.org/security/cgi-bin/moin.py/CryptoMaxims
 
 This is not about cipher design, it's more about protocol design
 and implementation.

And the very first thing that happened is my browser complained about the 
SSL certificate.

/r$

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


stickers can deter car theft

2007-05-26 Thread James Muir

I thought this was an interesting security-related story:

http://www.cbc.ca/canada/nova-scotia/story/2007/05/25/decal-car.html

quoting from the article:


The black-and-yellow sticker, which only costs a loonie, is an
invitation for police to pull over your vehicle if it's on the road
after 1 a.m.

The problem with car theft is actually bigger than any of us
realize, said Staff Sgt. Peter MacIsaac, with Cape Breton Regional
Police.

Nearly 400 cars were stolen in the Sydney area last year, he said,
and statistics show that most disappear between 1 a.m. and 5 a.m.

MacIsaac said people have been calling the police station to ask
about the Combat Auto Theft (CAT) program, which he says has been a
success in the United States.


Anyone heard of this before?  Is there a reason why a car theft can't 
simply remove or cover up these stickers?


-James

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


RE: stickers can deter car theft

2007-05-26 Thread Dave Korn
On 26 May 2007 04:33, James Muir wrote:

 
 Anyone heard of this before?  

  Been happening all over the place for several years now.  Many references at
http://www.schneier.com/blog/archives/2006/10/please_stop_my.html

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

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


A crazy thought?

2007-05-26 Thread Allen

Hi Gang,

In a class I was in today a statement was made that there is no way 
that anyone could present someone else's digital signature as their 
own because no one has has their private key to sign it with. This 
was in the context of a CA certificate which had it inside. I tried 
to suggest that there might be scenarios that could accomplish this 
but was told impossible. Not being totally clear on all the 
methods that bind the digital signature to an identity I let it be; 
however, the impossible mantra got me to thinking about it and 
wondering what vectors might make this possible.


Validating a digital signature requires getting the public key from 
some source, like a CA, or a publicly accessible database and 
decrypting the signature to validate that the private key associated 
with the public key created the digital signature, or open message.


Which lead me to the thought of trust in the repository for the 
public key. Here in the USA, there is a long history of behind the 
scenes cooperation by various large companies with the forces of 
the law, like the wiretap in the ATT wire room, etc.


What is to prevent this from happening at a CA and it not being 
known for a lengthy period of time? Jurors have been suborned for 
political reasons, why not CAs? Would you, could you trust a CA 
based in a country with a low ethics standard or a low regard for 
human rights?


Which lead me to the thought that if it is possible, what could be 
done to reduce the risk of it happening?


It occurred to me that perhaps some variation of separation of 
duties like two CAs located in different political environments 
might be used to accomplish this by having each cross-signing the 
certificate so that the compromise of one CA would trigger an 
invalid certificate. This might work if the compromise of the CA 
happened *after* the original certificate was issued, but what if 
the compromise was long standing? Is there any way to accomplish this?


Thoughts?

Best to all,

Allen

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