Re: 307 digit number factored
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
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
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
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
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?
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]