Re: dual-use digital signature vulnerability
attempt to address this area; rather than simple i agree/disagree buttons ... they put little checkmarks at places in scrolled form you have to at least scroll thru the document and click on one or more checkmarks before doing the i agree button. a digital signature has somewhat higher integrity than simple clicking on the i agree button ... See US patent 5,995,625. The abstract: A method of unwrapping wrapped digital data that is unusable while wrapped, includes obtaining an acceptance phrase from a user; deriving a cryptographic key from the acceptance phrase; and unwrapping the package of digital data using the derived cryptographic key. The acceptance phrase is a phrase entered by a user in response to information provided to the user. The information and the acceptance phrase can be in any appropriate language. The digital data includes, alone or in combination, any of: software, a cryptographic key, an identifying certificate, an authorizing certificate, a data element or field of an identifying or authorizing certificate, a data file representing an images, data representing text, numbers, audio, and video. -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptography and the Open Source Security Debate
There doesn't appear to be a discussion forum related to the Web post, so I'll reply here. We've gone through a similar thought process at my company. We have a commercial security product (MatrixSSL), but provide an open source version for many of the good points Daniel makes. There are a few additional reasons that the general open-source conclusion isn't as clear cut however. One of the benefits of having security algorithms open source is that the code can be better trusted in terms of back doors. So while Daniel may trust the NSA, others may not. Standard software typically isn't treated with the same positive paranoia, and therefore doesn't often have the same requirement. Back doors in closed source networked software, for example can be somewhat tested for through network protocol analysis and controlled through firewalls. Cryptography must be trusted at an algorithm level, since protocol analysis of the resultant data (should be) very difficult. A larger problem with the expansion from cryptographic algorithm benefits to open source benefits in general is one of pure code size. The number of lines of code of both Windows and Linux distributions is 30-40 million. The number of developers that 1. bother reading the code, 2. can actually understand it, 3. have the expertise and motivation to suggest/correct problems is a very small subset of developers for either proprietary or open source solutions. Developers that understand the complex interactions between software components are even fewer. When it comes down to it, a very small set of people becomes trusted in whatever code area they specialize in. Crypto algorithms are typically on the order of 1000 lines of code, with a large portion containing static key blocks. Experts looking at an open crypto algorithm require a great deal of expertise, but can also be much more focused in their analysis. Do you trust both the talent and moral integrity of the company you are getting your closed source software from so much that you think the products they are supplying you are superior (from a security standpoint) to those that can be created via peer review and attack by tens of thousands? This question is less related to the crypto specific conclusion, so I'll keep it short. The power of capitalism to produce competition and better products is underestimated here. Market pressure is growing for closed source to become more secure, and when money is at stake, the products will improve. Peer review by tens of thousands of largely unpaid, untrained developers vs. a corporation's all important shareholder value in this increasingly security conscious market is a much more even fight than one might expect. This is why we have combined both sides of the debate to produce a dual licensed product that has the security benefits of open source, with the market responsibility of a commercial product. J Harper PeerSec Networks http://www.peersec.com - Original Message - From: R. A. Hettinga [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 20, 2004 9:46 AM Subject: Cryptography and the Open Source Security Debate http://www.osopinion.com/print.php?sid=1792 osViews | osOpinion Cryptography and the Open Source Security Debate Articles / Security Date: Jul 20, 2004 - 01:03 AM Contributed by: Daniel R. Miessler :: Open Content If you follow technology trends, you're probably aware of the two schools of thought with regard to security and/or cryptography. Does cryptography and security solutions become more secure as the number of eyes pouring over its source code increases or is a private solution which leverages security through obscurity provide a more secure environment? Daniel R. Miessler submitted the following editorial to osOpinion/osViews, which offers some compelling arguments for both scenarios. In the end, his well thought out opinion, comes to a universal conclusion. -- I've been reading Bruce Schneier's Book on cryptography for the last couple of days, and one of the main concepts in the text struck me as interesting. One of the points of discussion when looking at the security of a given algorithm is its exposure to scrutiny. Bruce explicitly states that no one should ever trust a proprietary algorithm. He states that with few exceptions, the only relatively secure algorithms are those that have stood the test of time while being poured over by thousands of cryptanalysts. Similar Situations What struck me is the similarity between this mode of thought and that of the open source community on the topic of security. In that debate there is much disagreement about which is better - open or closed -, while in the crypto world it's considered common knowledge that open is better. According to the crypto paradigm, having any measure of an algorithm's security based on the fact that it's a secret is generally a bad thing. There, keys are what makes the system
Identity theft case could be largest so far
http://www.cnn.com/2004/LAW/07/21/cyber.theft/index.html CNN Identity theft case could be largest so far Wednesday, July 21, 2004 Posted: 10:49 PM EDT (0249 GMT) WASHINGTON (CNN) -- A Florida man was indicted Wednesday in an alleged scheme to steal vast amounts of personal information, and the Justice Department said it might be the largest illegal invasion and theft of personal data to date. The 144-count indictment against Scott Levine, 45, also includes charges of conspiracy, fraud, money laundering and obstruction of justice, according to the Justice Department. Levine's alleged target was Acxiom Corp., one of the world's largest companies managing personal, financial and corporate data, federal authorities said. Levine is accused of stealing vast amounts of personal information from the company via the Internet. Federal officials said the theft of approximately 8.2 gigabytes of data resulted in losses of more than $7 million. The protection of personal information stored on our nation's computer systems is critical to public trust in those networks and to the health of our economy, said Assistant Attorney General Christopher Wray at a news conference in Washington. We will aggressively pursue those who steal private information from computer networks and make it clear that there are serious consequences for such crimes, he said. Levine, a resident of Boca Raton, Florida, is described in the indictment as the controlling force in Snipermail.com Inc., a Florida corporation engaged in distributing advertisements via the Internet on behalf of advertisers and brokers. Acxiom, headquartered in Little Rock and Conway, Arkansas, stores and processes millions of bits of data on behalf of a wide range of clients that include IBM, GE, Microsoft and many major credit card companies. The invasions from Snipermail were discovered during another investigation of another intrusion at Acxiom last year, authorities said. The FBI's regional computer forensics laboratory in Dallas, Texas, and computer forensic experts from the FBI and the Secret Service were unleashed on the cyber intruders. The indictment alleges that Levine and others at the company attempted to hide computers from investigators. Six employees at the company agreed to cooperate with the investigation, authorities said. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
On SSL, SET, `real PKI` and real code against Phishing/Spoofing
brief comments/suggestions: 1. The whole discussion on how much eavesdropping is a threat is irrelevant. We all know it is a threat and the level is not important, as SSL/TLS provide a good, inexpensive solution. Drop this topic. 2. Stop beating the dead horse (SET). But yes, we should learn from mistakes... and Steve is right: SET main failure was lack of incentive to buyers and sellers. Such an incentive was our design assumption and I was assured by the CC `suits` they'll do it, but when they did, it was too little and much too late. And also they added so much baggage on this poor protocol that it became really so complex. But I am proud of few things in SET, especially... It wasn't even a real PKI ... No, exactly, it wasn't. Because what you refer to as `real PKI` (see original note...) - identities, revocation etc. - are not needed for this application (and many others). We need to use the tool that fits the job. 3. Which brings us back to SSL and Ian's objection... I think Ian _really_ objects to the fact that the major SSL/TLS deployments (browsers, servers) depend on `browser PKI`. And I agree: I think the `browser PKI` is a sad joke (on us), with the weakly-secure, not-really-trusted list of over-100 CAs. We can do much better - use SSL, but checking certificates better; display the logo of the site and/or of the CA, and allow users to decide on sites they trust (and their logos) manually... We have been discussing these things on this list for ages, and some even asked `is there a real use for crypto`. Then, with Ahmad, we implement and document a cute little extension to Mozilla that uses SSL and certificates, but probably not what some may call `real PKI`. And guess what? You go back to argue on SSL vs. SET and such. Guys: give us some feedback! Ok, it's a paper, not a note, but it is really pretty easy reading. And if this is too much, at least look at the screen shot: http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing_files/image006.gif And then speak up - is it the right approach? Should we change something before releasing (hoping in a week or two) or longer term? Can you do it for IE or other browser? (for the paper, see my homepage as below...) -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) Mirror site: http://www.mfn.org/~herzbea/ begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com , mirror: http://www.mfn.org/~herzbea/ version:2.1 end:vcard
Re: dual-use digital signature vulnerability
Barney Wolff wrote: Pardon a naive question, but shouldn't the signing algorithm allow the signer to add two nonces before and after the thing to be signed, and make the nonces part of the signature? That would eliminate the risk of ever signing something exactly chosen by an attacker, or at least so it would seem. Most (secure) signature schemes actually include the randomization as part of their process, so adding nonces to the text before signing is not necessary. OTOH, I don't see any problem in defining between the parties (in the `meta-contract` defining their use of public key signatures) that the signed documents are structured with a random field before and after the `actual contract`, as long as the fields are well defined. -- Best regards, Amir Herzberg Associate Professor, Computer Science Dept., Bar Ilan University http://amirherzberg.com (information and lectures in cryptography security) Mirror site: http://www.mfn.org/~herzbea/ begin:vcard fn:Amir Herzberg n:Herzberg;Amir org:Bar Ilan University;Computer Science adr:;;;Ramat Gan ;;52900;Israel email;internet:[EMAIL PROTECTED] title:Associate Professor tel;work:+972-3-531-8863 tel;fax:+972-3-531-8863 x-mozilla-html:FALSE url:http://AmirHerzberg.com , mirror: http://www.mfn.org/~herzbea/ version:2.1 end:vcard
Re: RP -- Re: Using crypto against Phishing, Spoofing and Spamming...
At 01:39 PM 7/21/2004, Ed Gerck wrote: The PKI model is not tied to any legal jurisdiction and is not a business process. What is meant then by relying-party (RP) and RP Reliance in X.509 and PKIX? I hope the text below, from a work in progress submitted as an IETF ID, helps clarify this issue. the TTP (trusted third party) PKI business model typically described in the early 90s ... had a business exchange between a key owner and a certification authority ... where the key owner paid the certification authority for the issuing of a certificate that bound some information to the public key. The payment of money by the key owner to the certification authority created some sort of legal relationship between the key owner and the certification authority with regard to the certificate. in that environment the key owner then digitally signed something, and sent the something with a digital signature and the certificate to a relying-party. The relying-party was frequently assumed to be making some sort of legal reliance and recourse on the performance of the certification authority. However, w/o payment of funds and/or other legal arrangement between the relying-party and the certification authority there was no legal bases for reliance (unless mandated outside of traditional business context by some gov. mandate) it appears that the GAO working within that semantic structural business context ... has taken some effort to create a legal basis for reliance and recourse between the relying parties and the certification authorities for the federal PKI . It basically has something along the lines of the certification authorities signing a contractual relationship with the GAO. Then all the relying parties also sign a contractual relationship with the GAO then there is recourse for the relying parties on certification authority performance based on the relying parties contract with GAO (for certification authority performance) and the GAOs contract with the certification authorities (for certification authority performance). This is sort of trying to get around the lack of any implied performance and/or contractual relationship (and therefor recourse) because the relying parties haven't actually paid any money to the certification authorities. In the simple case, having any sort of legal obligation between the certification authority and the key-owner ... and any sort of totally different legal obligation between the key-owner and a relying party ... normally would fail to create any sort of legal obligation between (the traditional TTP PKI) certification authorities (described in the early 90s) and the set of relying parties. some of this became mute by the mid-90s with the observation that the traditionally considered identity x.509 certificates represented a significant privacy and liability exposure ... and the retrenching by infrastructures to relying-party-only certificates (effectively account number and public key ... although even a relying-party-only SET certificates could represent a factor of 100-times payload bloat). the other issue that quickly became observed if the relying-party and the certification authority were the same then the relying party would typically have a large superset of the information that they included in any relying-party-only certificate ... and that having the key-owner to return this small subset of information repeatedly to the relying-party (/certification authority) was redundant and superfluous other than possibly contributing huge computational and transmission overheads for no useful purpose. IETF standards tend to be descriptions of protocol and parties role in the protocol. Such syntactical and semantical description of the protocols has rarely included description of any possible syntactical and semantic business relationships especially of the typical kind being proposed in the early 90s for TTP certification authorities. for pkix references see http://www.garlic.com/~lynn/rfcietff.htm and click on Term (term-RFC#) in the RFC's listed by section then click on PKI in the Acronym fastpath section. the current results: public key infrastructure (PKI) see also file:///D:/users/http/rfcterms.htm#t508authentication , file:///D:/users/http/rfcterms.htm#t600encryption , file:///D:/users/http/rfcterms.htm#t770public key file:///D:/users/http/rfcidx12.htm#38203820 file:///D:/users/http/rfcidx12.htm#37793779 file:///D:/users/http/rfcidx12.htm#37783778 file:///D:/users/http/rfcidx12.htm#37703770 file:///D:/users/http/rfcidx12.htm#37413741 file:///D:/users/http/rfcidx12.htm#37393739 file:///D:/users/http/rfcidx12.htm#37093709 file:///D:/users/http/rfcidx12.htm#36533653 file:///D:/users/http/rfcidx12.htm#36473647 file:///D:/users/http/rfcidx11.htm#35623562 file:///D:/users/http/rfcidx11.htm#34473447 file:///D:/users/http/rfcidx11.htm#33793379
Re: Identity theft case could be largest so far
R. A. Hettinga wrote: http://www.cnn.com/2004/LAW/07/21/cyber.theft/index.html Identity theft case could be largest so far From other reports, the indictment alleges that Levine gained access ... by misusing a legitimate password and user name while working for a company doing business with Acxiom. I.e., not even a hack, but an insider theft. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
