Secure64 Develops First Automated DNSSEC Signing Application to Help Secure the Internet Worldwide
Secure64 Develops First Automated DNSSEC Signing Application to Help Secure the Internet Worldwide http://www.businesswire.com/news/google/20080730005428/en from above: Secure64 Software Corporation has developed a product that dramatically simplifies the implementation and management of DNSSEC. Secure64 DNS Signer™ is the first and only product that addresses each of the obstacles that have slowed the widespread deployment of DNSSEC zone signing, including the need for simplicity, security, auditability and scalability. While recent patching efforts have mitigated the impact of the cache poisoning vulnerability identified by Dan Kaminsky and widely reported by the media, deployment of DNSSEC is widely regarded as the only viable long-term solution to securing the Domain Name System (DNS). ... snip ... One of the people behind Itanium design ... was one of the Secure64 founders ... somewhat as part of demonstrating what could be done with features that had been included in Itanium chip architecture. I've noted before that they had been heavily involved in earlier RISC chip efforts ... including original 801 risc chip. misc. past posts mentioning 801, risc, romp, rios, somerset, fort knox, power/pc, etc http://www.garlic.com/~lynn/subtopic.html#801 -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Fw: FIPS 198-1 announcement
Begin forwarded message: Date: Wed, 30 Jul 2008 12:36:36 -0400 From: Sara Caswell [EMAIL PROTECTED] To: undisclosed-recipients:; Subject: FIPS 198-1 announcement The National Institute of Standards and Technology (NIST) is pleased to announce approval of Federal Information Processing Standard(FIPS) Publication 198-1, The Keyed-Hash Message Authentication Code (HMAC), a revision of FIPS 198. The Federal Register Notice (FRN) of the approval is available here. The FIPS specifies a mechanism for message authentication using cryptographic hash functions in Federal information systems. URL to the Federal Register Notice: http://csrc.nist.gov/publications/fips/fips198-1/FIPS198-1_FRN.pdf URL to the FIPS Publication 198-1: http://csrc.nist.gov/publications/PubsFIPS.html#FIPS%20198-1 --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
On the randomness of DNS
I thought this list might be interested in a mini-rant about DNS source port randomness on my blog: http://www.links.org/?p=352. Ever since the recent DNS alert people have been testing their DNS servers with various cute things that measure how many source ports you use, and how random they are. Not forgetting the command line versions, of course dig +short porttest.dns-oarc.net TXT dig +short txidtest.dns-oarc.net TXT which yield output along the lines of aaa.bbb.ccc.ddd is GREAT: 27 queries in 12.7 seconds from 27 ports with std dev 15253 But just how GREAT is that, really? Well, we don' t know. Why? Because there isn't actually a way test for randomness. Your DNS resolver could be using some easily predicted random number generator like, say, a linear congruential one, as is common in the rand() library function, but DNS-OARC would still say it was GREAT. Believe them when they say it isn't GREAT, though! Non-randomness we can test for. So, how do you tell? The only way to know for sure is to review the code (or the silicon, see below). If someone tells you don't worry, we did statistical checks and it's random then make sure you're holding on to your wallet - he'll be selling you a bridge next. But, you may say, we already know all the major caching resolvers have been patched and use decent randomness, so why is this an issue? It is an issue because of NAT. If your resolver lives behind NAT (which is probably way more common since this alert, as many people's reactions [mine included] was to stop using their ISP's nameservers and stand up their own to resolve directly for them) and the NAT is doing source port translation (quite likely), then you are relying on the NAT gateway to provide your randomness. But random ports are not the best strategy for NAT. They want to avoid re-using ports too soon, so they tend to use an LRU queue instead. Pretty clearly an LRU queue can be probed and manipulated into predictability. So, if your NAT vendor is telling you not to worry, because the statistics say they are random, then I would start worrying a lot: your NAT vendor doesn't understand the problem. It's also pretty unhelpful for the various testers out there not to mention this issue, I must say. Incidentally, I'm curious how much this has impacted the DNS infrastructure in terms of traffic - anyone out there got some statistics? Oh, and I should say that number of ports and standard deviation are not a GREAT way to test for randomness. For example, the sequence 1000, 2000, ..., 27000 has 27 ports and a standard deviation of over 7500, which looks pretty GREAT to me. But not very random. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
On Jul 30, 2008, at 1:56 PM, Ben Laurie wrote: Oh, and I should say that number of ports and standard deviation are not a GREAT way to test for randomness. For example, the sequence 1000, 2000, ..., 27000 has 27 ports and a standard deviation of over 7500, which looks pretty GREAT to me. But not very random. I boggled a bit at the abuse of simple descriptive statistics, too. For those interested in actual statistical tests of randomness, there's a good literature survey at http://www.ciphersbyritter.com/RES/RANDTEST.HTM . -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
But just how GREAT is that, really? Well, we don' t know. Why? Because there isn't actually a way test for randomness. Your DNS resolver could be using some easily predicted random number generator like, say, a linear congruential one, as is common in the rand() library function, but DNS-OARC would still say it was GREAT. Believe them when they say it isn't GREAT, though! Well, they are some tests to judge the quality of a random number generator. The best known being the Diehard tests: http://en.wikipedia.org/wiki/Diehard_tests http://stat.fsu.edu/pub/diehard/ For sure, these tests might be an overkill here. Also, there must be some tests in the Art of Computer Programming too but I don't have it at hand right now (shame on me). I don't see the point of evaluating the quality of a random number generator by statistical tests. But I might be wrong, though. Regards, -- Pierre-Evariste DAGAND - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
Pierre-Evariste Dagand wrote: But just how GREAT is that, really? Well, we don' t know. Why? Because there isn't actually a way test for randomness. Your DNS resolver could be using some easily predicted random number generator like, say, a linear congruential one, as is common in the rand() library function, but DNS-OARC would still say it was GREAT. Believe them when they say it isn't GREAT, though! Well, they are some tests to judge the quality of a random number generator. The best known being the Diehard tests: http://en.wikipedia.org/wiki/Diehard_tests http://stat.fsu.edu/pub/diehard/ For sure, these tests might be an overkill here. Also, there must be some tests in the Art of Computer Programming too but I don't have it at hand right now (shame on me). I doubt you can get a large enough sample in any reasonable time. I don't see the point of evaluating the quality of a random number generator by statistical tests. Which is entirely my point. But I might be wrong, though. Regards, -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
I doubt you can get a large enough sample in any reasonable time. Indeed. I don't see the point of evaluating the quality of a random number generator by statistical tests. Which is entirely my point. I fear I was not clear: I don't see what is wrong in evaluating the quality of a random number generator with (an extensive set of) statistical tests. For sure, it would be better if we could check the source code and match the implemented RNG against an already known RNG. But, then, there is a the chicken or the egg problem: how would you ensure that a *new* RNG is a good source of randomness ? (it's not a rhetorical questions, I'm curious about other approaches). Regards, -- Pierre-Evariste DAGAND - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
Pierre-Evariste Dagand wrote: I doubt you can get a large enough sample in any reasonable time. Indeed. I don't see the point of evaluating the quality of a random number generator by statistical tests. Which is entirely my point. I fear I was not clear: I don't see what is wrong in evaluating the quality of a random number generator with (an extensive set of) statistical tests. SHA-1(1), SHA-1(2), SHA-1(3), ... SHA-1(N) will look random, but clearly is not. For sure, it would be better if we could check the source code and match the implemented RNG against an already known RNG. But, then, there is a the chicken or the egg problem: how would you ensure that a *new* RNG is a good source of randomness ? (it's not a rhetorical questions, I'm curious about other approaches). By reviewing the algorithm and thinking hard. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
Ben Laurie writes: Oh, and I should say that number of ports and standard deviation are not a GREAT way to test for randomness. For example, the sequence 1000, 2000, ..., 27000 has 27 ports and a standard deviation of over 7500, which looks pretty GREAT to me. But not very random. That's a good point, Ben. Dan Kaminsky's DNS tester at http://www.doxpara.com/ does include output like this: Your name server, at 1.2.3.4, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :3, :30020, :30100...). Requests seen for dae687514c50.doxdns5.com: 1.2.3.4:34023 TXID=64660 1.2.3.4:50662 TXID=51678 1.2.3.4:55984 TXID=49711 1.2.3.4:17745 TXID=12263 1.2.3.4:26318 TXID=59610 This shows only the last 5 ports so it won't detect an LCG, but at least it can detect some of the more obvious patterns. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
Date: Wed, 30 Jul 2008 21:22:59 +0200 From: Pierre-Evariste Dagand [EMAIL PROTECTED] To: Ben Laurie [EMAIL PROTECTED], cryptography@metzdowd.com Subject: Re: On the randomness of DNS [...] For sure, it would be better if we could check the source code and match the implemented RNG against an already known RNG. [...] So... Download BIND and check. URL is http://www.isc.org/index.pl and select bind 9.5.0-P1 and then select BIND-9.5.0-P1 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
On 30 Jul 2008, at 19:57, Pierre-Evariste Dagand wrote: But just how GREAT is that, really? Well, we don' t know. Why? Because there isn't actually a way test for randomness. Your DNS resolver could be using some easily predicted random number generator like, say, a linear congruential one, as is common in the rand() library function, but DNS-OARC would still say it was GREAT. Believe them when they say it isn't GREAT, though! Well, they are some tests to judge the quality of a random number generator. The best known being the Diehard tests: http://en.wikipedia.org/wiki/Diehard_tests http://stat.fsu.edu/pub/diehard/ For sure, these tests might be an overkill here. Also, there must be some tests in the Art of Computer Programming too but I don't have it at hand right now (shame on me). I don't see the point of evaluating the quality of a random number generator by statistical tests. But I might be wrong, though. Sorry - but something like AES(static-key) encrypt of i++ or SHA1(i++) will pass each and everyone of those test very nicely - but with a bit of code or silicon peeking - one can probably 'break' this with relative ease. I fail to see how you could evaluate this without seeing the code (and even then - I doubt that one can properly do this -- the ?old? NSA habit of tweaking your random generated rather than your protocol/ algorithm when they wanted your produced upgraded to export quality - is terribly effective and very hard to spot). Or am I missing something ? Dw - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: On the randomness of DNS
On 30 Jul 2008, at 21:33, Ben Laurie wrote: For sure, it would be better if we could check the source code and match the implemented RNG against an already known RNG. But, then, there is a the chicken or the egg problem: how would you ensure that a *new* RNG is a good source of randomness ? (it's not a rhetorical questions, I'm curious about other approaches). By reviewing the algorithm and thinking hard. But even then - is that really 'possible' - or is this fundamentally a black art ? Dw - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
