Re: Tinc's response to Linux's answer to MS-PPTP
M Taylor [EMAIL PROTECTED] writes: On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote: Both SSL and SSH have had their security problems . . , as perfect as Peter Gutmann would let us believe. They may not be perfect but in neither case can Mallet do as much damage as easily, even the recent break in OpenSSH did not allow a compromise as big as even the smallest of the problems briefly explored in tinc. Oh, and they fixed their flaws. SSHv1 is not recommended for use at all, and most systems use SSHv2 now which is based upon a draft IETF standard. SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF standard. Nitpicking alert: Draft Standard is the technical term for the second tier of IETF standardization. (Proposed, Draft, Full). The term for something that has not yet been approved and given an RFC # is Internet Draft. SSHv2 and TLSv1.1 are Internet Drafts. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
Jeroen C.van Gelderen wrote: On Saturday, Sep 27, 2003, at 15:48 US/Eastern, [EMAIL PROTECTED] wrote: You have not met my users! Indeed, but I'm here to learn :) ... something is wrong. Why would she click YES? ... Because I'm an optimist I believe that Alice will read the dialog and err on the side of caution. Maybe that isn't realistic. ... I agree that such composition must be intuitive or we cannot expect it to work. I think that CapDesk is a nice publicly available prototype of a workable capability desktop. It would be very interesting to see your assessment on whether a CapDesk approach would be workable for your users. And if it isn't, why not. I hope you can lend your experience. OK, I'll lend mine. With my ISP hat on, the vast majority of support calls have to do with users ignoring the content of M$ dialog boxes, hitting YES or OK, then calling when things don't work. Admittedly, the text in those dialog boxes isn't particularly useful. But this costs us a lot of good old hard cash. Or with my personal hat, my 15-year-old niece had an infected machine. Actually a multiply infected machine. Took me several hours to clean up. And then I watched her check her yahoo mail, and click yes on the very next Norton/McAfee dialog box, reinfecting her Comcast connected machine before my very eyes. Why, I asked? I just spent a lot of time fixing your machine, and explained what had gone wrong. She says, That message came from my best friend at school. Of course it didn't. But it probably came from another friend with them both in the address book. And social engineering is a lot more powerful than any amount of training, no matter how very recent! The answer to a technical problem is _not_ depending on user caution! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
A quick question...
Hi, Apologies in advance for the vagueness of the question... Talking to a friend the other day, he was telling me about a potential loophole with SHA-1 hashes protected by an RSA signature. Basically, he seemed to think that with an SHA hash of a suitable length (say, 2^20), the hash could be cubed and still not 'fail', since it was below the key modulus. If you change the hash length, this problem doesn't occur. I'm unconvinced for a number of reasons - this sounds very strange to me. Not least because, even if cubing the hash does work (why cubing?), since it's infeasible to create a binary which produces a given hash it still doesn't help. Could someone help shed some light on this? Either pointing me at a paper documenting the hole, or confirming that it's gibberish (at which point I'll go back to work and ask him for more details :). Thanks, -- Paul The ability to quote is a serviceable substitute for wit. -- W. Somerset Maugham - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
On Saturday, Sep 27, 2003, at 20:31 US/Eastern, Zooko wrote: Jeroen C. van Gelderen [EMAIL PROTECTED] wrote: There is no way around asking the user because he is the ultimate authority when it comes to making trust decisions. (Side-stepping the issues in a (corporate) environment where the owner of the machine is entitled to restrict its users in any way he sees fit. The point is that the software agent cannot make trust decisions.) ... but you don't always have to *ask* the user, if instead you can infer from actions that the user already performs. Oops, I didn't mean to imply that you'd have to ask as much as happens at present! Automatically inferring is pretty much required if Alice is to be able to do a whole day's worth of work without seeing any popups in the steady case. You only ask Alice when you cannot otherwise reliably infer her intentions; That will be necessary at some point. The remaining questions that do get asked then are meaningful and do not condition towards a knee-jerk Click-Yes reaction. I used to think that a capability desktop would be severely hobbled by the requirement that the user state a plethora of privilege rules, until I saw Marc Stiegler's CapDesk demo at the second O'Reilly Emerging Technologies conference. In that demo, a perfectly familiar desktop with File - Open and File - Save As dialogs also serves as a Least-Privilege-enforcing access control system which protects even a naive and lazy user from a malicious text editor. And you can even download and try it for yourself as all of CapDesk is freely available. If that is too much, just download Marc's video demonstration [1]: http://www.erights.org/talks/skynet/index.html I truly don't know how much more helpful one can get in order to dispel the perpetuation of these security myths? See also Ping Yee's research in secure Human Interface. http://www.sims.berkeley.edu/~ping/sid/ -J [1] I don't know why the video is available in M$ proprietary format only though :( - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote: Perhaps a HMAC per chunk, rather than per the payload of a single UDP datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of payload may work. This will increase latency. That would not work either. It would have the same problems as a packet that has been split into 5 fragments: if one of the fragments gets lost, the whole packet will be discarded. Fragment reassembly is also something that is not completely trivial, in the past there have been some simple DoS attacks for various operating systems that did not implement IP fragment reassembly correctly. Each UDP packet must stand on its own, just like the network packet that has been encapsulated within it. This should be redone from scratch, I would look at either using Diffie Hellman Key Exchange combined with digital signatures or the updated Needham Schroeder Public Key Protocol. Exchange two symmetric keys, one used for bulk data encryption, the other used for the HMAC authentication. I think I prefer the Diffie-Hellman key exchange; the Needham Schroeder public key protocol needs more round trips and one more RSA encryption/decryption step. I expect this is a reference to Why TCP Over TCP Is A Bad Idea http://sites.inka.de/~bigred/devel/tcp-tcp.html Yes. If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their high tolerance for unncessary weakness, I think tinc 2.0 could end up being a secure piece of software. I hope Guus and Ivo circulate their version 2.0 protocol before they do any coding, so that any remaining flaws can be easily fixed in the paper design without changing a single line of code, saving time and effort. Those are the first encouraging words I've heard since Peter Gutmann's writeup was posted on Slashdot, thank you! We do plan to get rid of all the weaknesses, and once we know what we want and we have a draft, I'll post it in this mailing list. -- Met vriendelijke groet / with kind regards, Guus Sliepen [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: quantum hype
I promised some links about the 5/6 cloning figure. You've had a few experimental ones, here are some theory ones. Cloning machines: http://www.fi.muni.cz/usr/buzek/mypapers/96pra1844.pdf Theoretically optimal cloning machines: http://www.gap-optique.unige.ch/Publications/Pdf/PRL02153.pdf 1/6 disturbance is theoretically optimal, both as a QC interception strategy and it's an optimal cloning machine: http://www.gap-optique.unige.ch/Publications/Pdf/PRA04238.pdf A different approach to the 1/6 figure (2/3 cloned correctly, the 1/3 imperfectly cloned still has a 50% chance of being right): http://arxiv.org/PS_cache/quant-ph/pdf/0012/0012121.pdf That lot is pretty much indisputed... ...except for the optimal part; and that's a sideways argument anyway - the math and physics theory are right as far as they go, just that they didn't consider everything. It may be possible to clone better than those optimal solutions, especially in the classic QC case, or get more information like which photons were cloned correctly, and perhaps to as near perfection as you like, but that is in dispute. Actually it's a pretty friendly dispute, people mostly say I don't know*. I'll post some more links on that later. *unless someone mentions non-linear transformations. Which is a different dispute really. -- Peter Fairbrother - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
M Taylor wrote: Oh, and they fixed their flaws. SSHv1 is not recommended for use at all, and most systems use SSHv2 now which is based upon a draft IETF standard. SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF standard. It is curious, is it not, that there has been no well written protocol that became successful on its first attempt? And, contrariwise, all successful systems started out with crypto that slept shamefully with ROT13. If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their high tolerance for unncessary weakness, I think tinc 2.0 could end up being a secure piece of software. I hope Guus and Ivo circulate their version 2.0 protocol before they do any coding, so that any remaining flaws can be easily fixed in the paper design without changing a single line of code, saving time and effort. This is the best thing written so far. Even if Guus and Ivo were not to distribute their designs for 2.0, I would salute their efforts so far. It is clear that they have users. Hoorah! I say. It is clear that they have successfully enabled millions of VPN connections. There art we happy! It is fair to say that through their efforts, many hundreds or thousands of Linux boxen have escaped becoming part of the lamented and hacked 43,000. A pack of blessings light upon the backs of cryptographers! The notion that Guus and Ivo have done anything in the slightest sense, wrong, is mysterious to me. It defies explanation. They built a product. They protected users. Now, later on, after *proving* the product meets the needs of the market place, is the time to clean up the stopgap home-brewed crypto. It's not the most urgent thing. Only if the product is under sustained and unavoidable attack by the bad guys - like HTTPS - is it urgent to get in there and fix the security. And from the absence of any commentary on actual attacks, there seems all the time in Mantua to prepare a killer 2.0 crypto layer. Or am I missing something? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Reliance on Microsoft called risk to U.S. security
At 8:12 AM -0700 9/27/03, [EMAIL PROTECTED] wrote: On Fri, 26 Sep 2003, Bill Frantz wrote: The real problem is that the viewer software, whether it is an editor, PDF viewer, or a computer language interpreter, runs with ALL the user's privileges. If we ran these programs with a minimum of privilege, most of the problems would just go away. And what privileges should the Perl interpreter run with when I click on a .pl file? How would the graphical shell know what privileges to assign to each file? Given a strange program that has just arrived on my machine, my current policy is not to run it at all. I might be willing to adopt a policy of giving it a small amount of memory, CPU, and some space to render on the screen. That would allow people to exchange active amusements with a degree of safety. If the program required more privilege (for example, a new version of a utility from a co-worker), I would be happy to move it to an environment where it had the resources it needs to run. On the other hand a *trivial* privilege system: View (zero privs) vs. Run (full privs) is viable, and is one of the pre-requisites for a more secure UI, along with the previously discussed trusted path issues, non-spoofing of the security interface, ... Limiting the privilege of the View program would provide protection against flaws in the viewer. Given the number of flaws in very basic software, such protection seems of have real value. Cheers - Bill - Bill Frantz| There's nothing so clear as | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A quick question...
At 11:53 PM 9/27/2003 +0100, Paul Walker wrote: Talking to a friend the other day, he was telling me about a potential loophole with SHA-1 hashes protected by an RSA signature. Basically, he seemed to think that with an SHA hash of a suitable length (say, 2^20), the hash could be cubed and still not 'fail', since it was below the key modulus. If you change the hash length, this problem doesn't occur. I'm unconvinced for a number of reasons - this sounds very strange to me. Not least because, even if cubing the hash does work (why cubing?), since it's infeasible to create a binary which produces a given hash it still doesn't help. I think your friend has a very limited understanding of what's going on; he's right in some small sense, but wrong in practice. Cubing is coming from the assumption that the public exponent is 3, which is possible for RSA but rare in practice; 17 or 2^16+1 are much more common values. It also relies on using some rawly implemented RSA, so that all that is in the RSA payload is the hash, and nothing else. This violates all the standards that specify that the payload should be padded with stuff that, among other things, guarantees that even with an exponent of three, the answer will have exceeded the modulus and been subject to modular reduction. So he's talking through his hat. Could someone help shed some light on this? Either pointing me at a paper documenting the hole, or confirming that it's gibberish (at which point I'll go back to work and ask him for more details :). So, here's the attack. Suppose you have a 160-bit SHA-1 hash of some document, and it just happens to be a perfect cube (integer-speaking). Then the cube root of that hash is a valid signature independent of the modulus, so long as the public exponent is 3. Adding (and checking) correct padding (eg. OAEP or PSS, see the PKCS standards) makes it extremely unlikely that there will be a cube root for the attack to work on. Others may want to correct me or elaborate further, but I think that's correct. regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A quick question...
On Mon, Sep 29, 2003 at 08:33:59AM +1000, Greg Rose wrote: common values. It also relies on using some rawly implemented RSA, so that all that is in the RSA payload is the hash, and nothing else. This violates all the standards that specify that the payload should be padded The code which implements all of this has to run in 6KB of code space, so it's entirely possible that they hacked together their own routines to deal with it. Almost certain, in fact - I don't think there's a compiler available, so any library would have to be rewritten in assembler anyway. (Sorry I can't be more precise here, but I'm sure you can appreciate why.) [snip explanation] Others may want to correct me or elaborate further, but I think that's correct. It certainly makes much more sense than the scrambled version I had before, and fits with what cryptography I already knew. I still don't think it's a particularly *practical* attack, but I could easily be wrong there, and it only needs one. ;-) Many thanks for your time! Cheers, -- Paul I'm not sure if this is a good or a bad thing. Probably a bad thing; most things are bad things. -- Nile Evil Bastard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
