cryptography and security-related papers from North Korea
I stumbled on the following link:http://cryptome.org/dprk/dprk-papers.htm --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FW: How broad is the SPEKE patent.
At 14:47 11/10/2005 -0800, Charlie Kaufman wrote: [... Radia Perlman and I] were approached by David Jablon, the inventor of SPEKE but no longer the patent holder, who suggested that we should not assume that PDM did not infringe SPEKE and should not make such claims to others. This was based on claims in a patent filed many years before but which through various techniques had been prevented from issuing (a practice known as 'submarining'). The submarine Conspiracy Theory (and I love a good CT as much as anyone) just doesn't fit here. The five year delay between filing and issuance of 6,226,383 was due to a practice known as bureacracy. My suggestion, that people should avoid making assertions regarding other parties' intellectual property, was based on prudence. In the case of PDM vs. the SPEKE pending patent, the authors of PDM were not in a position to know what claims would be granted. Short of disclosing pending claims, which was ill-advised for several reasons, there was nearly full disclosure. The patent's existence, and details for all the methods that I had considered to be potentially useful, were publicly disclosed in 1996 and 1997. This includes posts to sci.crypt and this cryptography mailing on using a password- selected modulus [1][2]. I told one of the authors about these posts after learning about PDM. No submariner worth his salt would pursue such a course of disclosure. -- David [1] http://marc.theaimsgroup.com/?l=cryptographym=96472454824691 [2] http://groups.google.com/group/sci.crypt/msg/b14f1c24f3153e5f __ David Jablon www.jablon.org __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Pseudorandom Number Generator in Ansi X9.17
In Practical Cryptography, Schneier discusses a new PRNG design called Fortuna. It has some neat features. He also discusses problems with the ANSI PRNG here: http://www.schneier.com/paper-prngs.html -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
timing attack countermeasures (nonrandom but unpredictable delays)
The naive countermeasure to timing attacks is to add a random delay, but of course that can be averaged out by repeating the computation. I have never heard anyone propose a delay that is based on the input, and maybe some per-machine secret, so that it is unpredictable but constant. Of course this wouldn't solve averaging across different inputs from some subset, but it would prevent averaging on the same value. Perhaps something more clever could be done to prevent averaging across subsets -- for example, the timing of the actual computation could be used as an input to the delay function. -- http://www.lightconsulting.com/~travis/ -- We already have enough fast, insecure systems. -- Schneier Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ISAKMP flaws?
Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.html I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Perry E. Metzger writes: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.ht ml I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? Broadly speaking, they're implementation bugs. The folks at University of Oulu are doing what developers around the world and across the industry should have been doing: they're writing test case generators that stress parsers. So far, they've been extremely successful against IKEv1, ASN.1, SNMP, and more. This should surprise no one and depress everyone. http://www.ee.oulu.fi/research/ouspg/protos/index.html is the home page for this project. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.html I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? The advisory itself is at http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en. Note that the abstract is Multiple Vulnerability Issues in Implementation of ISAKMP Protocol, with emphasis on Implementation of. It appears that this is *not* a problem with ISAKMP or IKE, but instead only a problem with some implementations. A summary would be when some IKEv1 implementations are sent certain malformed messages, they stop, reboot, or possibly do other bad things. Given that they started this research with sending malformed SNMP packets to SNMP-aware systems (with similar results), it is safe to extrapolate the results to implementations of nearly any protocol to varying extents. It is likely that this applies to IKEv2 as well, but using differently-malformed packets. It is also likely that it applies to some SSL/TLS implementations, of course using very different malformed packets. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
In message [EMAIL PROTECTED], Paul Hoffman writes: At 10:14 AM -0500 11/15/05, Perry E. Metzger wrote: Some articles have been appearing in various web sites about flaws in IPSec key negotiation protocols, such as this one: http://news.com.com/VPN+flaw+threatens+Internet+traffic/2100-1002_3-5951916.h tml I haven't been following the IPSec mailing lists of late -- can anyone who knows details explain what the issue is? The advisory itself is at http://www.uniras.gov.uk/niscc/docs/br-20051114-01013.html?lang=en. Note that the abstract is Multiple Vulnerability Issues in Implementation of ISAKMP Protocol, with emphasis on Implementation of. It appears that this is *not* a problem with ISAKMP or IKE, but instead only a problem with some implementations. A summary would be when some IKEv1 implementations are sent certain malformed messages, they stop, reboot, or possibly do other bad things. Given that they started this research with sending malformed SNMP packets to SNMP-aware systems (with similar results), it is safe to extrapolate the results to implementations of nearly any protocol to varying extents. It is likely that this applies to IKEv2 as well, but using differently-malformed packets. It is also likely that it applies to some SSL/TLS implementations, of course using very different malformed packets. I mostly agree with you, with one caveat: the complexity of a spec can lead to buggier implementations. Sure, even relatively simple protocols can be implemented poorly, but complex ones have more places to go wrong. (It's instructive, I might add, to read RFC 1025, especially the part about dirty blows.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fermat's primality test vs. Miller-Rabin
Ron Rivest reported on some theoretical and practical experimental work in Crypto 90, Finding Four Million Large Random Primes, http://theory.lcs.mit.edu/~rivest/Rivest-FindingFourMillionLargeRandomPrimes.ps A number n is a (base two) pseudoprime if it is composite and satisfies the identity 2^(n-1) = 1 mod n How rare are pseudoprimes? We performed an experiment that attempts to provide an answer... They tested 718 million random 256-bit values. First they performed a small divisor test using divisors up to 10^4. 43,741,404 numbers passed. These were then tested using the equation above (the Fermat test with base 2). 4,058,000 passed that further test. These were then subjected to 8 iterations of Miller-Rabin to see which were pseudoprimes. None of them were pseudoprimes. All of the numbers in this sample which passed the small divisor and base-2 Fermat test passed all subsequent MR tests and were presumably all prime. Rivest goes on and uses a conjecture of Pomerance to argue that the number of pseudoprimes 2^256 is at most 4 x 10^52, while the number of true primes is 6.5 x 10^74. Hence your chance of running into a pseudoprime is less than 1 in 10^22. I'm not sure the role of the small-divisor tests but I think that may make the odds even better. The larger primes in use today should also have improved odds. Based on this kind of result, RSAREF, the free library available from RSA back in the 90s, did not use MR and did not do multiple tests. It performed a small divisor test (only testing 3, 5, 7 and 11 as divisors!) and a single base 2 Fermat test, for its RSA keygen. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ISAKMP flaws?
At 2:29 PM -0500 11/15/05, Steven M. Bellovin wrote: I mostly agree with you, with one caveat: the complexity of a spec can lead to buggier implementations. Well, then we fully agree with each other. Look at the message formats used in the protocols they have attacked successfully so far. Humorously, security folks seem to have ignored this when designing our protocols. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
the effects of a spy
Bruce Schneier's newsletter Cryptogram has the following fascinating link: http://www.fas.org/irp/eprint/heath.pdf It's the story of effects of a single spy who betrayed keys and encryptor designs. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: the effects of a spy
Steven M. Bellovin [EMAIL PROTECTED] writes: Bruce Schneier's newsletter Cryptogram has the following fascinating link: http://www.fas.org/irp/eprint/heath.pdf It's the story of effects of a single spy who betrayed keys and encryptor designs. Very interesting indeed. I was unaware that the military had such astonishingly bad key management practices. One wonders if things have actually improved. One thing one hopes has changed is that one hopes that it is no longer necessary for everyone to share the same keying material among so many different endpoints. Public key cryptography and key negotiation could (in theory) make it unnecessary to store shared secrets for long periods of time before use, where they are rendered vulnerable to espionage. One hopes that, over the last thirty years, this or something analogous has been implemented. One intriguing question that I was left with after reading the whole thing was not mentioned in the document at all. One portion of the NSA's role is to break other people's codes. However, we also have to assume that equipment would fall into the wrong people's hands at intervals, as happened with the Pueblo incident. If properly designed, the compromise of such equipment won't reveal communications, but there is no way to prevent it from revealing methods, which could then be exploited by an opponent to secure their own communications. Does the tension between securing one's own communications and breaking an opponents communications sometimes drive the use of COMSEC gear that may be too close to the edge for comfort, for fear of revealing too much about more secure methods? If so, does the public revelation of Suite B mean that the NSA has decided it prefers to keep communications secure to breaking opposition communications? Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
