Re: Quiet in the list...
IanG wrote, On 7/9/08 2:06 AM: Then, when a new Thunderbird comes out, you load that up and the other packages cease to work As far as I recall, the last time Thunderbird had an upgrade it told me that one was available, I clicked to upgrade, and the addons, including Enigmail, continue to work. When there was an upgrade available to Enigmail, same thing. And the upgrade to GNUgpg also installed cleanly with no reconfiguration necessary. It has all been as transparent as can be. My only problem with it is that I keep having this nagging feeling in the back of my mind that set it and forget it is not the best approach to security. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Kaminsky finds DNS exploit
Udhay Shankar N wrote, On 9/7/08 5:52 PM: I think Dan Kaminsky is on this list. Any other tidbits you can add prior to Black Hat? He's posted a quite long article on his blog http://www.doxpara.com/?p=1162 that looks like all the details he is likely to provide for the next 30 days. It does seem to address the speculation on this list about how the patch relates to stuff that has been known for years, Dan Bernstein's code, who knew what when, etc. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS and port 587
Ed Gerck wrote, On 23/1/08 7:38 AM: The often expressed idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping and so on, or protect any private communications, is IMO simply not supported by facts. I would like to see some facts to support the assertion that the idea that SSL/TLS and port 587 are somehow able to prevent warrantless wiretapping is often expressed. A Google search for ssl port 587 warrantless wiretapping got exactly one hit, which was your posting to the mailing list where it had been archived on security-basic.blogspot.com and snarfed up by Google within the hour. (As an aside, see Google Taking Blog Comments Searching Real-Time? http://www.groklaw.net/article.php?story=20080122132516514 for a discussion of this remarkable update to their search engine). Sidney Markowitz http://www.sidney.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
Ivan Krsti? wrote, On 6/1/08 1:33 PM: On Jan 3, 2008, at 10:47 PM, Peter Gutmann wrote: That's because there's nothing much to publish: In the US, notify the BIS via email. Our outside counsel -- specializing in this area -- thought this was insufficient That's the problem with using lawyers, they'll always give you a conservative cautious answer. Unfortunately for people who don't use them, sometimes those really are the correct, prudent answers. When I worked for a company that had to face this we acted according to what looked like the plain language documentation from the BIS, concluding that use of an existing open source package required just sending an email. We were never as high profile as OLPC and in fact never ended up exporting anything, so our interpretation of the laws was not only not made by qualified legal counsel, it also was never tested. I do look forwrd to seeing what you discover were the considerations that your outide counsel had. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
Ivan Krsti? wrote, On 31/12/07 12:48 PM: We've recently had to jump through the BIS crypto export hoops at OLPC I find that very strange considering this from a BIS FAQ http://www.bis.doc.gov/encryption/encfaqs6_17_02.html all encryption source code that would be considered publicly available under Section 734.3(b)(3) of the EAR (such as source code posted to the Internet) and the corresponding object code may be exported and reexported under License Exception TSU -- Technology and Software Unrestricted (specifically, Section 740.13(e) of the EAR), once notification (or a copy of the source code) is provided to BIS and the ENC Encryption Request Coordinator. What hoops did you have to jump through? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Sidney Markowitz wrote, On 21/9/07 8:24 AM: Ben Laurie wrote, On 21/9/07 1:34 AM: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j. The without i's knowledge part is critical to the argument, as the author is assuming that entity i is monitoring all of entity j's channels of communication Curse this non-standard notation! I of course meant entity l everywhere I said entity j to keep with the original author's nomenclature. Whatever happened to Alice, Bob, and Eve? -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Scare tactic?
Ben Laurie wrote, On 21/9/07 1:34 AM: It seems to me that the requirement cited: Entity i cannot be coerced into sharing a key with entity j without i’s knowledge, ie, when i believes the key is shared with some entity l != j. The without i's knowledge part is critical to the argument, as the author is assuming that entity i is monitoring all of entity j's channels of communication and either entity j has no communication of any kind outside of that used for the DH protocol with entity i, or else entity i would be able to recognize whether any other communication with anyone is a revelation of the secret session key that entity i is sharing with entity j. Note that entity i would even have to be sure that entity j is not using any side channels such as variations in the timing of response packets during the subsequent encrypted session to communicate with a colluding passive attacker who is eavesdropping. That is an awfully impractical constraint on the threat model, which makes this issue moot in practice. Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Latest AACS key cracked a week before release
Ars Technica reports that a new volume key which has been issued to replace the one that was cracked earlier this month and which is being used in DVDs to be released for sale next week has been cracked using a beta version of SlySoft's AnyDVD HD program and early release previews of The Matrix trilogy. Here's the article http://arstechnica.com/news.ars/post/20070517-latest-aacs-revision-defeated-a-week-before-release.html This is the same link in preview tinyurl form: http://preview.tinyurl.com/2zl4gv I know that there is nothing technologically new or interesting about this crack, but it does add a certain emphasis to the arguments for the futility of DRM, seeing systems cracked before they are released. What does it do to Ed Felten's model when C drops below 0? (reference Hal Finney's post to this list about two weeks ago http://article.gmane.org/gmane.comp.encryption.general/10065) -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Yet a deeper crack in the AACS
Article AACS cracks cannot be revoked, says hacker http://arstechnica.com/news.ars/post/20070415-aacs-cracks-cannot-be-revoked-says-hacker.html Excerpt: The latest attack vector bypasses the encryption performed by the Device Keys -- the same keys that were revoked by the WinDVD update -- and the so-called 'Host Private Key,' which as yet has not been found. This was accomplished by de-soldering the HD DVD drive's firmware chip, reading its contents, and then patching it. Once that was done, the firmware was soldered back onto the drive. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 128 bit number T-shirt?
Ivan Krstić wrote, On 3/5/07 4:50 AM: But all the artwork is just ugly numbers in a monospace font My thoughts too. This one looks much better, but I don't see a link anywhere to get it. Perhaps the author just photoshopped the picture as a proof of concept to go with his blog comment? http://www.ghacks.net/2007/04/30/09-f9-11-02-t-shirt -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptome cut off by NTT/Verio
Cryptome.org has not been shut down yet (the notice from Verio dated 28 April says they were being given two weeks to find another provider). They seem to have been slashdotted. The shutdown notice page is not yet archivd at archive.org, but is mirrored on a responsive site, mirror.org: http://www.mirrordot.org/stories/e231a81023b07bf399b68b2c295e9736/ Here's a comment by John Young in the slashdot thread: http://slashdot.org/comments.pl?sid=232691cid=18919481 It links to a page on cryptome.org, which of course is unavailable during the slashdotting but is in the archive.org archives: http://web.archive.org/web/*/http://cryptome.org/stoa-atpc.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES128-CBC Question
Aram Perez wrote, On 19/4/07 6:29 PM: Is there any danger in using AES128-CBC with a fixed IV of all zeros? Here is some discussion about doing this, in the context of PGP doing just that and why PGP inserts random characters at the begining of the plaintext. http://archive.cert.uni-stuttgart.de/openpgp/2003/04/msg00026.html It points out that a fixed IV results in information leakage if the first block or more of plaintext is the same in two messages encrypted with the same key. Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: general defensive crypto coding principles
Simon Josefsson wrote: Travis H. [EMAIL PROTECTED] writes: ... 3) Authenticate the plaintext, not the ciphertext. This is a general [...] I wonder whether this is really a good suggestion, considering Krawczyk's paper that show that this construct is not generically secure. See http://eprint.iacr.org/2001/045. Schneier deals with that explicitly when he makes the suggestion, on pp 115-117 in Practical Cryptography, referring to theoretical results rather than referencing Krawczyk's paper directly. Krawczyk's paper shows that authenticate before encryption is not secure under assumptions that are not realistic, such as the encryption being subject to a chosen ciphertext attack, use of ECB mode, separate MAC authentication of each block along with an encryption oracle so you can use a kind of block level replay attack in CBC mode. If you use a good cipher with an appropriate mode and apply the authentication to the entire message with proper use of message ID or timestamp to prevent replay attacks, you avoid Krawczyk's vulnerabilities four times over. Schneier deals with the argument about potential DoS attacks by pointing out that most real-life DoS attacks saturate the communication channel, not the CPU. He also presents arguments for authenticating before encrypting which I won't repeat here -- It's all there in a pretty clear three pages in his book. -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: serious threat models
Matt Blaze wrote: Yes, it's not at all clear from these stories just what was going on or how high tech the attack would have to be. What does diverting to a prepaid mobile mean? There is more information in Bruce Scheier's blog entry and his links to blog and news articles. It hit slashdot yesterday: http://www.schneier.com/blog/archives/2006/02/phone_tapping_i.html According to those reports, the attack involved modifying (configuring?) software on a Vodafone switch to cause all calls to/from some 100 mobile phone numbers to be conference calls with some prepaid mobile numbers that recorded the conversations. Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RNG quality verification
Philipp Gühring wrote: I took OpenSSL, generated 1 RSA keys, and took them apart. First I analyzed the raw keys: Try this: Generate 256000 bytes from MD5(i), i=1...16000 and run the same tests. That is clearly not acceptable as a PRNG because it is completely predictable if you know that the sequence is MD5(1) ... MD5(16000), but it should pass any tests other than one that checks specifically if it is correlated to MD5(1) ... MD5(16000). Perhaps you would say that example is unfair because MD5 makes a perfectly good PRNG as long as the software package seeds it properly. In that case, how are you going to ensure that the package you are testing is seeding the PRNG properly? In fact, the famous Netscape vulnerability was based on a PRNG that was simply MD5 of a counter, with the vulnerability being predictability of the seed. See http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html for a clear description of that. Your tests would not detect that kind of vulnerability. You asked, Has anyone tested yet, how much samples are needed to detect those PRNGs? The point is that your tests will not detect the difference between a PRNG using a properly seeded MD5(counter) and one with a predictable seed. More generally, a sequence can be predictable while still being statistically random. Carrying it even further, back in 1996 the only problem with using MD5 of a counter as a PRNG was making sure that the seed was unpredictable. That may not be true anymore because of recent results of MD5 collisions, or more accurately, it may not remain true if stronger attacks continue to be found. Statistical tests have not all of a sudden changed their results: MD5 will not appear any less random in those tests just because vulnerabilities are found. So how do you certify PRNGs used by your customers? You have them use well known software packages that have been analyzed and vetted by the cryptographic community, such as OpenSSL. It would be a shock if any of them did not pass the simple statistical tests that you can perform. Passing those tests does not ensure that there are none of the more subtle vulnerabilities that are only discovered by many smart people taking a very hard look over a significant time period. -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
On 12/19/05 9:54 AM, [EMAIL PROTECTED] wrote: Imagine a E-commerce front end: Instead of little-guy.com buying a cert which you are supposed to trust, they go to e-commerce.com and pay for a link. Everyone trusts e-commerce.com and its cert. e-commerce provides a guarantee of some sort to customers who go through it, and charges the little guys for the right. Do you mean like Amazon Marketplace and Amazon zShops? I think it's been done already: http://www.amazon.com/exec/obidos/tg/browse/-/1161232/103-4791981-1614232 -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
Joseph Ashwood wrote: Apparently, they are, I'm ran a sample, but even with the added second sanity check, every one of them that passes a single round comes up prime. I then proceeded to move it to 2048-bit numbers. It takes longer and the gaps between primes is averaging around 700 right now, but once again if it passes a single test it passes all 128+128 Ok, I did misunderstand you. If that failed 120-130 times is talking about the number of trials between primes, then you are getting within the range of expected results. According to the prime number theorem, the probability of selecting a prime number at random from odd numbers is about 2/ln(n) which for a 512 bit number is about 1 in 177, which means you have about a 50% chance of 120 tries before finding a prime. According to the results that Anton quoted there is a 2^56 chance that a 512 bit odd number that passes one round of Miller-Rabin is actually prime. So all of your results do make sense. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
Joseph Ashwood wrote: Granted this is only a test of the generation of 128 numbers, but I got 128 primes (based on 128 MR rounds). That doesn't make sense, unless I'm misinterpreting what you are saying. Primes aren't that common, are they? I don't have time right now to look for a bug in your code, but you could add a sanity check that would catch a bug immediately by adding in the appropriate spot a test like if (!curnum.isProbablePrime(128)) System.out.println(Something wrong, number is not really a prime!); to check that your primality test gets the same result as the M-R primality test that comes with BigInteger. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
Joseph Ashwood wrote: byte [] rawBytes = new byte[lenNum/8]; rand.nextBytes(rawBytes); curNum = new BigInteger(rawBytes); I haven't thought through why it would produce non-primes, but it doesn't seem to do what you want. That produces a 512 bit twos-complement number, which gives you a 511 bit positive integer, not 512 bit. It also is unnecessarily complicated compared to this form of the BigInteger constructor and the or method (see the javadoc): curNum = BigInteger.ONE.or(new BigInteger(512, rand)); -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA Suite B Cryptography
Joseph Ashwood wrote: U, no. The NSA only licensed the right to use (and sublicense under special circumstances) the patents [...] [snip the rest, it was based on a failed assumption] Poor phrasing on my part. Exactly as you said, the patent sublicense cannot be passed on even if the code is released under, say a BSD copyright license. People would have a right to copy the source code but would have to obtain patent rights either from the NSA if they are eligible, or as you said under alternative arrangements from Certicom. Since the GPL excludes distribution of code with patents that limit their distribution other than by specific country, the patent encumbrance that would accompany the code would prevent it from being released under GPL. The possible twist that I see is if the NSA declares that any freely available open source software that interoperates with Suite B is by definition in support of US national security interests and therefore automatically gets one of their sublicenses. That would effectively remove the patent encumbrance for GPL code. There would still be patent restrictions on the code, but they would not apply to open source freely redistributable code, therefore would not get in the way of the GPL. Oh, no, that would not be strictly true. GPL allows you to do anything at all with the code if you use it for yourself without distributing it. Patent restrictions still apply to such uses. They could be uses that are not in support of US national security interests. Therefore you still could not distribute the code under GPL as the people you give it to would not have the patent rights to modify the code for their own private modified use if they do not distribute the changes. So it still comes down to what I think is the important point: BSD licensed Suite B code may be possible, GPL'd Suite B code is not possible unless Certicom makes appropriate free license to the patents available for software licensed under GPL. -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA Suite B Cryptography
Excerpt from Fact Sheet on NSA Suite B Cryptography http://www.nsa.gov/ia/industry/crypto_suite_b.cfm NSA has determined that beyond the 1024-bit public key cryptography in common use today, rather than increase key sizes beyond 1024-bits, a switch to elliptic curve technology is warranted. In order to facilitate adoption of Suite B by industry, NSA has licensed the rights to 26 patents held by Certicom Inc. covering a variety of elliptic curve technology. Under the license, NSA has a right to sublicense vendors building equipment or components in support of US national security interests. Does this prevent free software interoperability with Suite B standards? It potentially could be used to block non-US vendors, certainly anyone who is in the US Government's disfavor, but it seems to me that even with no further intentional action by the NSA it would preclude software under the GPL and maybe FOSS in general in countries in which the patents are valid. -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA Suite B Cryptography
Ian G wrote: Which is to say, NSA solved its problem and it is nothing to do with FOSS. If you wrote a Suite B program and distributed it under a BSD license after getting a sub-license for the patent from the NSA, presumably I could take that code, modify it, and then in order to use or distribute my modified code I would have to obtain my own sublicense from the NSA. I could do that as long as I met whatever criteria the NSA has for granting sublicenses. My guess is that at a minimum the program would have to be available for free or for sale to the US government for some purpose that allows it to be considered as being in support of US national security interests. It would make no sense for the NSA to grant a sublicense to you that allowed to you grant me a license to produce possibly proprietary code that infringes the patent and is not in support of US national security interests. So, yes, under those assumptions BSD-like licenses would not be excluded, with the understanding that in addition to the copyright terms allowing free use of the code there would also be patent restrictions affecting the use. As you say, the NSA's solution to their problem has nothing to do with FOSS, and it doesn't specifically exclude FOSS. But it will preclude GPL software that will interoperate with Suite B from being distributed in countries that recognize the patents. Unless, I suppose the NSA is able to say that any use of the patent in open source software can be considered in support of US national security interests and therefore the sublicense can be propagated as long as the source remains available. In other words, if they include a GPL-like provision that the patent license will stay with the code as long as it is distributed under GPL. That would be an interesting twist. -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: European country forbids its citizens from smiling for passport photos
New Zealand did this earlier this year, as part of giving in to pressure from the US to have passports with biometric information. Here is a press release of last June from the NZ Green Party's Human Rights spokesperson. A quote from it Most people arriving in our fair land have smiles on their faces and there is nothing wrong with having passport photos to match http://www.greens.org.nz/searchdocs/PR8903.html -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Clearing sensitive in-memory data in perl
Does anyone know of an open source crypto package written in perl that is careful to try to clear sensitive data structures before they are released to the garbage collector? Failing that, does anyone know of an example that tries to deal with the particularly bad effect that at least on some perl platforms writing to a tied DB_File results in data from garbage collected strings appearing in the unused space between the logical end of file and the end of the allocated disk block? And failing that, how about a reference to how one would go about preventing leaking sensitive information in garbage collected strings when writing in perl. Google and reading perl documentation hasn't helped me so far, but I find it hard to believe that this has not been considered when writing crypto software in perl. Thanks, Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES implementation in C - any recommendations?
Ian G wrote: I'm after an AES implementation in C, preferably with something approximating BSD/open licence. Does anyone have a view on which would be a current favourite? Brian Gladman's code is the fastest free version I know of, is widely used, and has a BSD-like license. http://fp.gladman.plus.com/AES/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Digital Water Marks Thieves
Matt Crawford wrote: How do the tiny particles know that it's not a civilian illuminating them with ultraviolet light? And how does Wired reporter Robert Andrews fail to ask that question? And other people complain about how someone can spray their paint on someone else's valuable and then call the police. These arguments remind me of Peter Gutmann's recent post to the list about good enough security... You can make the same arguments about the DNA signature in blood. A civilian can analyze it. It is conceivable that someone can get a sample of someone else's blood or other biological sample and frame them by leaving DNA evidence somewhere. That does not make DNA analysis useless as a tool in forensics. So now there is a way of marking items that cannot be engraved and a way of marking intruders. It sounds more sophisticated than a red dye bomb in a sack of cash stored in a bank vault -- which also has its uses and its drawbacks. Now it will be easier to tie the dyed material and the dyed thieves to the specific crime. It is not a big deal that it does not solve all problems in one stroke. -- sidney markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The Pointlessness of the MD5 'attacks'
This isn't worked out enough to be a proof of concept, but I can imagine a piece of code that has a comment This can't overflow because value X computed from the magic bits table will always be between A and B. Get 0.1% speed boost by leaving out range check here but don't change magic bits. That doesn't even have to be so obscure. It provides a place to introduce a security hole that will not be noticed by substituting a new magic bits table without the protective property. Unless someone takes their copy of the source code that has MD5 equal to the MD5 of the sources that have been reviewed by the experts and verifies for themselves whether their magic bits table does compute a value X between A and B, they are vulnerable. If MD5 is trusted, there is no reason to audit every downloaded copy of the source code like that, as long as you are sure that someone has done the audit. -- sidney http://www.sidney.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [OT] Encryption
[Moderator's note: that's one -- but only one -- of the reasons I think Bob found the exchange so funny. --Perry] Ah, I thought he was being honest but naive and couldn't understand how he could apply for clearance from the US for an import. I looked at the rest of the thread in their mailing list archive and see where he has claimed to be able to crack any AES-128 encrypted document in 20 minutes and that he has references to the current scientific literature showing that such times are well known state of the art. He says he will demonstrate decrypting a document one of the list members sent him and post the literature references when he is back in his office during the week. If I had read that first I would not have wondered about the US import restrictions :-) -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
[EMAIL PROTECTED] wrote: Does anybody know what has become of the low-tech, no-cryptography-needed RMX DNS record entry proposal? A google search for rmx dns without quotes brings up as its first hit the Internet Draft at IETF which is dated October 2003. The subsequent hits show lots of discussion about it. You might also be interested in http://spf.pobox.com which seems to be a similar proposal that extends the MX record rather than define a new rmx record. To bring it back to the cryptography topic of this list, the draft proposal for rmx brings up a problem with crypto solutions that I did not see mentioned here yet. I'll just quote the relevant paragraph from the Draft rather than summarize it. Note that the draft states that it specifies only non-cryptographic mechanisms but still allows use of cryptography. [begin quote] 2.4. Shortcomings of cryptographical approaches At a first glance, the problem of sender address forgery might appear to be solvable with cryptographic methods such as challenge response authentications or digital signatures. A deeper analysis shows that only a small, closed user group could be covered with cryptographical methods. Any method used to stop spam forgery must be suitable to detect forgery not only for a small number of particular addresses, but for all addresses on the world. An attacker does not need to know the secrets belonging to a particular address. It is sufficient to be able to forge any address and thus to know any secret key. Since there are several hundreds of millions of users, there will always be a large amount of compromised keys, thus spoiling any common cryptographic method. Furthermore, cryptography has proven to be far too complicated and error prone to be commonly administered and reliably implemented. Many e-mail and DNS administrators do not have the knowledge required to deal with cryptographic mechanisms. Many legislations do not allow the general deployment of cryptography and a directory service with public keys. For these reasons, cryptography is applicable only to a small and closed group of users, but not to all participants of the e-mail service. [end quote] -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
Carl Ellison wrote: So, in capsule: this proposal assumes that you use the same machine for outgoing and incoming e-mail. No, it implies a service that your outgoing mail server makes available that has you authenticate to it in some way and then signs your mail in some way. The article doesn't make clear exactly how it would work. The signature might just certify that the mail really was sent through the mail server that the headers claim was used. That would allow you to use any email address that you want, such as your acm.org address, and the signature certifies that you authenticated yourself with the SMTP server. My ISP recently switched to using TLS SMTP/Auth for access to their SMTP server from outside their network for their customers. It would be easy and useful for them to stamp mail that I send to show that it really was sent through their SMTP server and that they know who I am. This might not be exactly the same as what Yahoo! is talking about: They might be thinking only about mail with a yahoo.com From address being sent through a yahoo.com server and being signed with a key associated with the yahoo.com domain. But if the signature is taken to authenticate the domain of the SMTP server in the initial Received header, then it is possible to maintain lists of servers of ISPs who are trusted to authenticate users of their SMTP servers and to have anti-spam policies, and blacklists of servers that are spam sources. The From address would be irrelevant. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: yahoo to use public key technology for anti-spam
[EMAIL PROTECTED] wrote: To avoid replay attacks one needs to sign a string that is tied to a specific message or time period I agree. Even time period and message content aren't good enough: Let's say that the outgoing SMTP mailer at example.com is trusted. Spammer gets an account at example.com, sends themselves one message, then immediately copies the signature into forged headers for their spam that is sent out through whatever open relays or compromised machines they are using. The only way that the mail can be trusted is if it is being received directly from the example.com SMTP server. If there is any relaying, there is nothing that remains true and constant to sign. But that is the situation we have today: My ISP's server can choose to refuse to accept connections from servers that are on a blacklist of open relays and spammers, and can, in theory, have a list of known good servers who authenticate their clients. If all the new header does is verify the sending mail server, that is done just as well by verifying the ip address at the time of connection. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Open Source Embedded SSL - Export Questions
As a separate issue from whether you want to implement AES, if you do decide to implement it look at Brian Gladman's code at http://fp.gladman.plus.com/cryptography_technology/rijndael/ It is the fastest free implementation of AES that I know of, and has a good history and credentials behind it as you can see from the background information linked from that web page. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Are there...one-way encryption algorithms
Enzo Michelangeli wrote: but the slight risk of collision, although practically negligible, is a bit irksome If you quantify the practically negligible risk, it might be less irksome: SHA-1 is a 160 bit hash. The birthday paradox says that you would need to hash 2^80 different credit card numbers before you had a 50% probability of having even one collision in your database keys. Very roughly that means you would need to have a trillion different credit card numbers in your database in order to get as much as a one in a trillion chance of a collision. You would probably find dealing with a trillion different credit card numbers more irksome than the negligible chance of a collision even that many would give you. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS (Updated news)
It turned out that the ISP, Charter, was not compromised. The user had some nasty spyware install itself on his computer. Here are the details: http://ask.slashdot.org/comments.pl?cid=6260281sid=68266tid=172 -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
