Re: WYTM?
Eric Rescorla wrote: Ian Grigg [EMAIL PROTECTED] writes: I'm sorry, but, yes, I do find great difficulty in not dismissing it. Indeed being other than dismissive about it! Cryptography is a special product, it may appear to be working, but that isn't really good enough. Coincidence would lead us to believe that clear text or ROT13 were good enough, in the absence of any attackers. For this reason, we have a process. If the process is not followed, then coincidence doesn't help to save our bacon. Disagree. Once again, SSL meets the consensus threat model. It was designed that way partly unconsciously, partly due to inertia, and partly due to bullying by people who did have the consensus threat model in mind. (If you mean that the ITM is consenus, I grant you that two less successful protocols follow it - S/MIME and IPSec (partly) but I don't think that makes it consensus. I know there are a lot of people who don't think in any other terms than this model, and that is the issue! There are also a lot of people who think in terms completely opposed to ITM. So to say that ITM is consensus is something that is going to have to be established. If that's not what you mean, can you please define?) That's not the design process I would have liked, but it's silly to say that a protocol that matches the threat model is somehow automatically the wrong thing just because the designers weren't as conscious as one would have liked. I'm not sure I ever said that the protocol doesn't match the threat model - did I? What I should have said and hoped to say was that the protocol doesn't match the application. I don't think I said automatically, either. I did hold out hope in that rant of mine that the designers could have accidentally got it right. But, they didn't. Now, SSL, by itself, within the bounds of the ITM is actually probably pretty good. By all reports, if you want ITM, then SSL is your best choice. But, we have to be very careful to understand that any protocol has a given set of characteristics, and its applicability to an application is an uncertain thing; hence the process of the threat model and the security model. In SSL's case, one needs to say use SSL, but only if your threat model is close to ITM. Or similar. Hence the title of this rant. The error of the past has been that too many people have said something like Use SSL, because we already got it right. Which, unfortunately, skips the whole issue of what threat model one is dealing with. Just like happened with secure browsing. In this case, the ITM was a) agreed upon after the fact to fill in the hole, and b) not the right one for the application. And on the client side the user can, of course, click ok to the do you want to accept this cert dialog. Really, Ian, I don't understand what it is you want to do. Is all you're asking for to have that dialog worded differently? There should be no dialogue at all. Going from HTTP to HTTPS/self signed is a mammoth increase in security. Why does the browser say it is less/not secure? Because it's giving you a chance to accept the certificate, and letting you know in case you expected a real cert that you're not getting one. My interpretation - which you won't like - is that it is telling me that this certificate is bad, and asking whether me if I am sure I want to do this. A popup is symonymous with bad news. It shouldn't be used for good news. As a general theme, that is, although this is the reason I cited that paper: others have done work on this and they are a long way ahead in their thinking, far beyond me. It's not THAT different from what SSH pops up. (Actually, I'm not sure what SSH pops up, it's never popped up anything to me? Are you talking about a windows version?) SSH in terminal mode says: The authenticity of host 'hacker.stanford.edu (171.64.78.90)' can't be established. RSA key fingerprint is d3:a8:90:6a:e8:ef:fa:43:18:47:4c:02:ab:06:04:7f. Are you sure you want to continue connecting (yes/no)? I actually find the Firebird popup vastly more understandable and helpful. I'm not sure I can make much of your point, as I've never heard of nor seen a Firebird? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: cryptographic ergodic sequence generators?
Perry E. Metzger wrote: I've noted to others on this before that for an application like the IP fragmentation id, it might be even better if no repeats occurred in any block of 2^31 (n being 32) but the sequence did not repeat itself (or at least could be harmlessly reseeded at very very long intervals). I assume the point of the reseeding is to make the ID-values more unpredictable. On 09/07/2003 11:18 AM, David Wagner wrote: Let E_k(.) be a secure block cipher on 31 bits with key k. Pick an unending sequence of keys k0, k1, k2, ... for E. Then your desired sequence can be constructed by E_k0(0), E_k0(1), E_k0(2), ..., E_k0(2^31 - 1), 2^31 + E_k1(0), 2^31 + E_k1(1), ..., 2^31 + E_k1(2^31 - 1), E_k2(0), E_k2(1), E_k2(2), ..., E_k2(2^31 - 1), 2^31 + E_k3(0), 2^31 + E_k3(1), ..., 2^31 + E_k3(2^31 - 1), Again if we assume the point is to make the values unpredictable (not just ergodic), then there is room for improvement. To see what I mean, divide the values into generations G=0,1,2,3... where each row in the tableau above is one generation. The problem is that at the end of each generation, the values become highly predictable, à la Blackjack. David's proposal can be improved by the method used by Blackjack dealers: shuffle early. In each generation, let the argument of E_kG(.) max out at some fraction (f) of 2^(n-1). A limit of f=1/2 is the obvious choice, although other f values e.g. f=2/3 work nicely too. The domain and range of E_kG(.) are still unrestricted (n-1)-bit numbers. This gives us the following properties -- Guaranteed no repeats within the last f*2^(n-1) IDs. -- Probably no repeats in an even longer time. -- Even if the opponent is a hard-working Blackjack player, he has only one chance in (1-f)*2^(n-1) of guessing the next value. To put this number in context, note that the opposition has one chance in 2^(n-1) of guessing the next value without any work at all, just by random guessing. Setting f too near zero degrades the no-repeat guarantee. Setting f too near unity leads to the Blackjack problem. Setting f somewhere in the middle should be just fine. = Discussion of conceivable refinements: A proposal that keeps coming up is to take the values generated above and run them through an additional encryption stage, with a key that is randomly chosen at start-up time (then held fixed for all generations). The domain and range of this post-processing stage are n-bit numbers. This makes the output seem more elegant, in that we have unpredictability spread over the whole n-bit word, rather than having n-1 hard-to-predict bits plus one almost-constant bit. Define the phase to be P := (G mod 2). The opponent will have to collect roughly 2^n data points before being able to figure out which values belong to which phase, so initially his guess rate will be closer to one in 2^n, which is a twofold improvement ... temporarily. This temporary improvement is not permanent, if we allow the opponent to have on the order of 2^n memory. He will in the long run learn which values belong to which phase. I see no way to prevent this. So as far as I can tell, the proposed post-processing is more in the nature of a temporary annoyance to the opposition, and should not be considered industrial-strength cryptography. Perhaps more to the point, if we are going to allow the opposition to have 2^n memory, it would be only fair to allow the good guys to have 2^n memory. In that case, all the schemes discussed above pale in comparison to something I suggested previously, namely generating an ID absolutely randomly, but using a look-up table to check if it has been used recently, in which case we veto it and generate another. If you can afford the look-up table, these randomly generated IDs have the maximum possible unpredictability. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Internal format of RSA private keys in microsoft keystore.
- Original Message - From: R.Sriram [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, October 10, 2003 1:20 AM Subject: Internal format of RSA private keys in microsoft keystore. Greetings, In the process of trying to work around some of the limitations of the m$-CAPI API, I'm trying to decipher the internal representation of private keys in the default m$ key store, in order to extract the private key out. If you could acquire a context, you could export the private key into a blob and then read it from that, but you can't acquire a context. As Tom mentioned, the keys are encrypted in the container. The FIPS 140 security policies for M$'s CSPs say that the task of protecting the keys in the system is delegated to Data Protection API (DPAPI). There is a brief explanation in the security policies, see for example http://csrc.nist.gov/cryptval/140-1/140sp/140sp241.pdf section Key Storage. You might be able to find more detailed information somewhere else... Good luck! --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Indian National Workshop on Cryptography
http://www.ciol.com/cgi-bin/printer.asp?id=50186 ? Tuesday, October 14, 2003 Cyber India Online National workshop on cryptography PUNE: Cryptography was until recently an exclusive domain of the defense and security agencies. However, with the explosive growth of computerization, networking and the Internet coupled with the increasing importance of electronic commerce, cryptography has become an essential component of all electronic data exchange and economic activity. The AU-KBC Research Center has organized its annual workshop, which is an annual event of the Cryptology Research Society of India (CRSI) to focus on this subject. This year's workshop, which would be from October 16, 2003 - October 18, 2003 at Hyderabad is based on the theme Applications of cryptology to Information Security. Satyakam Mishra (certified ethical hacker) and Dr. SA Vetha Manickam of Network Security Solutions, Pune will present a paper on Software implementation of attack on A5/1 with possible improvements at the workshop. As part of the effort, Satyakam and Dr. Manickam have implemented an attack against A5/1, the strong over the air voice privacy algorithm for GSM networks, on an IBM PC. Eli Biham and Orr Dunkelmann described the attack in a recent paper. With their effort, in a simulated environment, they were able to recover the 64 bit secret key. They were also able to find errors in the Bihams attack and the effect was increase in proposed complexity from 240.97 to 241.29. The paper describes the attack techniques, the implementation, and some optimizations to make the attack more efficient from the earlier work. Network Security Solutions has developed an esoteric expertise and capability in consulting, research and development in PKI Infrastructure, Cryptography that includes development of pseudo- random generator, development of a new stream cipher, implementations on secret sharing schemes and various Cryptanalysis techniques, WEP cracking and key clustering. -- - 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]