Re: OpenSparc -- the open source chip (except for the crypto parts)
Marcos el Ruptor <[EMAIL PROTECTED]> writes: >> To be sure that implementation does not contain back-doors, one needs >> not only some source code but also a proof that the source code one >> has is the source of the implementation. > > Nonsense. Total nonsense. A half-decent reverse engineer does not > need the source code and can easily determine the exact operation of > all the security-related components from the compiled executables, > extracted ROM/EPROM code or reversed FPGA/ASIC layout I'm glad to know that you have managed to disprove Rice's Theorem. Could you explain to us how you did it? I suspect there's an ACM Turing Award awaiting you. Being slightly less sarcastic for the moment, I'm sure that a good reverse engineer can figure out approximately what a program does by looking at the binaries and approximately what an ASIC does given good equipment to get the layout. What you can't do, full stop, is know that there are no unexpected security related behaviors in the hardware or software. That's just not possible. > All this open-source promotion is a huge waste of time. Us crackers > know exactly how all the executables we care about (especially all > the crypto and security related programs) work. With respect, no, you don't. If you did, then all the flaws in Windows would have been found at once, instead of trickling out over the course of decades as people slowly figure out new unintended behaviors. Anything sufficiently complicated to be interesting simply cannot be fully understood by inspection, end of story. Now, the original poster was speaking about knowing that a piece of hardware does exactly what it was originally spec'ed to do. Some of that involves (among other things) knowing that the validation information (which a reverse engineer has no access to) applies to the resulting chip by virtue of knowing that what was compiled was precisely what was originally validated. There is a valid concern there. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: User interface, security, and "simplicity"
Thor Lancelot Simon <[EMAIL PROTECTED]> writes: > On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote: >> I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't >> do, and yet is is fairly easy to configure. > > And yet there's no underlying technical reason why it is any easier to > configure than IPsec is; Absolutely. There is no reason one couldn't build an easy to configure IPSec. Indeed, OpenVPN could simply use IPSec if its authors wanted to. No one has created the easy to configure IPSec, however, so I don't use IPSec for my own needs. > I find it amusing (but somewhat sad) that in fact one can find basically > the same set of flaws in each, but they're considered damning in IPsec > while they're handwaved away or overlooked in SSL VPNs. Myself, I don't handwave away said flaws. I don't recommend that clients use OpenVPN, for example. On the other hand, most of my clients can afford to pay admins to spend lots of time on this, and I couldn't afford to spend the time myself. > And, in fact, most VPN software of any type fails this test. My concern > is that an excessive focus on "how hard is it to set this thing up?" can > seriously obscure the important second half of the question "and if you > set it up in the easiest possible way, is it safe?" Well, it is pretty easy to configure SSH safely. Set it to only use public keys, copy your private key to the remote host in the authorized_keys file, and you're more or less done. There is no reason all the defaults can't be set up for a nice easy to use IPSec based package in such a way that it requires a deliberate effort to make the thing unsafe and it is more or less that easy to use. Unfortunately, people just don't spend nearly the amount of time on the UI for their IPSec systems that they do on the crypto, so they spoil all the hard work they've done making the implementation sound by making it impossible for ordinary people to understand. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSparc -- the open source chip (except for the crypto parts)
To be sure that implementation does not contain back-doors, one needs not only some source code but also a proof that the source code one has is the source of the implementation. Nonsense. Total nonsense. A half-decent reverse engineer does not need the source code and can easily determine the exact operation of all the security-related components from the compiled executables, extracted ROM/EPROM code or reversed FPGA/ASIC layout (see the recent Karsten Nohl's extraction of Crypto-1 code for example). All this open-source promotion is a huge waste of time. Us crackers know exactly how all the executables we care about (especially all the crypto and security related programs) work. We do not always publish our results, but look, somehow RC4, SecurID, DST40, KeeLoq, Crypto1, Hitag2, etc. all got reverse engineered and published when people actually cared to do it. A lot more other closed-code ciphers, random number generators and other components have been reverse- engineered and thoroughly analysed without publishing the results just because those results were not interesting, could do more harm than good if published or if keeping them secret could benefit the cracker. As a reverse engineer with over 20 years of experience, I can guarantee everyone on this list who is not familiar with this process that from the security evaluation point of view there is ABSOLUTELY NO BENEFIT in the open-source concept. It is actually much much easier to hide a backdoor in the C or especially C++ code from anyone reading it than it is in the compiled assembly code from a reverse engineer, even if it is highly obfuscated like Skype. High-level languages offer enough opportunities to hide and cover up some sneaky behind-the-scenes magic that no one will notice for years or ever at all unless they know exactly what to look for and where. I always compile the open-source code, then reverse engineer it and see what it is actually doing. If you want a guarantee or a proof, better ask all the reverse engineers you know to take a closer look at the program and tell you if there is a backdoor, anything malicious or anything sneaky or suspicious. Don't trust your own eyes. I've seen too many open-source applications with well-concealed backdoors or unnoticeable security holes. Linux's endless exploitable vulnerabilities should be enough of a proof of that. Best regards, Marcos el Ruptor http://www.enrupt.com/ - Raising the bar. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: User interface, security, and "simplicity"
Perry E. Metzger wrote: It is obvious to anyone using modern IPSec implementations that their configuration files are a major source of pain. In spite of this, the designers don't seem to see any problem. The result has been that people see IPSec as unpleasant and write things like OpenVPN when the underlying IPSec protocol is just fine and it is the implementations that are unpleasant. Kerckhoffs' 6th, providing great entertainment for the security world, since 1883. = 6. Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe. = iang PS: Although his 6th is arguably the most important, his others are well worth considering: https://www.financialcryptography.com/mt/archives/000195.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: User interface, security, and "simplicity"
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote: > > "Steven M. Bellovin" <[EMAIL PROTECTED]> writes: > > There's a technical/philosophical issue lurking here. We tried to > > solve it in IPsec; not only do I think we didn't succeed, I'm not at > > all clear we could or should have succeeded. > > > > IPsec operates at layer 3, where there are (generally) no user > > contexts. This makes it difficult to bind IPsec credentials to a user, > > which means that it inherently can't be as simple to configure as ssh. > > I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't > do, and yet is is fairly easy to configure. And yet there's no underlying technical reason why it is any easier to configure than IPsec is; it is all a matter of the configuration interface provided by your chosen SSL VPN (in this case, OpenVPN) or IPsec implementation. I find it amusing (but somewhat sad) that in fact one can find basically the same set of flaws in each, but they're considered damning in IPsec while they're handwaved away or overlooked in SSL VPNs. Of course you (Perry) or I can configure either IPsec or OpenVPN in a safe and sane way; and, of course, there are some VPN packages of either type (IPsec or SSL VPN) which have configuration interfaces so bad that we _couldn't_, in fact, set them up safely -- because they prevent safe, sane configuration. The problem is that whether you or I _can_ set software X up safely isn't the question that matters. The question that matters is "_will_ a naive user who does not understand the underlying security questions set software X up securely". And, in fact, most VPN software of any type fails this test. My concern is that an excessive focus on "how hard is it to set this thing up?" can seriously obscure the important second half of the question "and if you set it up in the easiest possible way, is it safe?" Thor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: New result in predicate encryption: disjunction support
On Sun, 4 May 2008, Scott Guthery wrote: One useful application of the Katz/Sahai/Waters work is a counter to traffic analysis. One can send the same message to everyone but ensure that only a defined subset can read the message by proper key management. What is less clear is how to ensure that decrytion with the wrong key doesn't yield an understandable (and actionable) message. This is actually pretty easy to do by, e.g., padding all valid messages with sufficiently-many 0s. Decryption with an incorrect key will result in something "random" that is unlikely to end with the requisite number of 0s (and so will be discarded). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: New result in predicate encryption: disjunction support
A group member asked me to elaborate on: > - No knowledge of which groups can be successfully authenticated is > known to the verifier What this tries to say is that the verifier doesn't need to have a list of all authenticable groups nor can the verifier draw any conclusions about other authenticable groups based on authenticating one group. One useful application of the Katz/Sahai/Waters work is a counter to traffic analysis. One can send the same message to everyone but ensure that only a defined subset can read the message by proper key management. What is less clear is how to ensure that decrytion with the wrong key doesn't yield an understandable (and actionable) message. Cheers, Scott - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: User interface, security, and "simplicity"
Jacob Appelbaum <[EMAIL PROTECTED]> writes: > Perry E. Metzger wrote: >> Until then, OpenVPN let me get started in about five minutes, and the >> fact that it is less than completely secure doesn't matter much to me >> as I'm running SSH under it anyway. [...] > I'm always curious to hear what designers of protocols actually use on a > daily basis. I'm also really curious how said designers evaluate their > choices. > > I really like OpenVPN. It's really smooth to setup, it's very easy to > use on the Big Three Platforms. > > Have you read the source to OpenVPN? Do you think that it's > cryptographically sound? Is it properly implemented? > > I've found some stuff I wonder about and I'm curious if anyone else has? I can't claim to like the innards, and it seems bizarre to me that the designers didn't simply use IPSec encapsulated in UDP as the underlying protocol. (Were I writing such a thing today, I might use DTLS.) That said, in my usage pattern, I don't care much about the possible security flaws. I would not recommend the package to clients, however. It is obvious to anyone using modern IPSec implementations that their configuration files are a major source of pain. In spite of this, the designers don't seem to see any problem. The result has been that people see IPSec as unpleasant and write things like OpenVPN when the underlying IPSec protocol is just fine and it is the implementations that are unpleasant. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: User interface, security, and "simplicity"
On Sat, 2008-05-03 at 23:35 +, Steven M. Bellovin wrote: > There's a technical/philosophical issue lurking here. We tried to > solve it in IPsec; not only do I think we didn't succeed, I'm not at > all clear we could or should have succeeded. > > IPsec operates at layer 3, where there are (generally) no user > contexts. This makes it difficult to bind IPsec credentials to a user, > which means that it inherently can't be as simple to configure as ssh. Let me restate things just to make sure I understand the problem. You're talking about "binding IPsec credentials to a user," but I want to look at it from the point of view of exactly what problems this causes, so is the following an accurate position? The problem is that we're trying to have entities with different security needs share a common set of authentications. When user 'pat' and user 'sandy' have different security needs (different authorized or trustable communication partners, to start with) we can't give them IPSEC because IPSEC operates on channels between machines rather than on channels between trusting/trusted entities. Even if 'pat' and 'sandy' both have a trusted/trusting entity on a given remote machine from theirs, IPSEC fails them because it cannot differentiate between the various entities (users, agents, services) using that remote machine, when 'pat' and 'sandy' need it to. Similarly, it fails the entities on that remote machine because it cannot differentiate between 'pat', 'sandy' and any other entities using the local machine, when trust relationships might exist only for some subset of those entities. Bear - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: User interface, security, and "simplicity"
Steven M. Bellovin wrote: On Sat, 03 May 2008 17:00:48 -0400 "Perry E. Metzger" <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: I am left with the strong suspicion that SSL VPNs are "easier to configure and use" because a large percentage of their user population simply is not very sensitive to how much security is actually provided. They're "easier to configure and use" because most users don't want to have to rebuild their entire world around PKI just to set up a tunnel from A to B. I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one of the people who helped create IPSEC. Right now, to use SSH to remotely connect to a machine using public keys, all I have to do is type "ssh-keygen" and copy the locally generated public key to a remote machine's authorized keys file. When there is an IPSEC system that is equally easy to use I'll switch to it. Until then, OpenVPN let me get started in about five minutes, and the fact that it is less than completely secure doesn't matter much to me as I'm running SSH under it anyway. There's a technical/philosophical issue lurking here. We tried to solve it in IPsec; not only do I think we didn't succeed, I'm not at all clear we could or should have succeeded. IPsec operates at layer 3, where there are (generally) no user contexts. This makes it difficult to bind IPsec credentials to a user, which means that it inherently can't be as simple to configure as ssh. Put another way, when you tell an sshd whom you wish to log in as, it consults that user's home directory and finds an authorized_keys file. How can IPsec -- or rather, any key management daemon for IPsec -- do that? Per-user SPDs? Is this packet for port 80 for user pat or user chris? I can envision ways around this (especially if we have an IP address per user of a system -- I've been writing about fine-grained IP address assignment for years), but they're inherently a lot more complex than ssh. I don't see why. The ssh server determines who the packets are for from information sent to it by the ssh client. The ssh client knows on whose behalf it is acting by virtue of being invoked by that user (I'll admit this is a simplification of the most general case, but I assert my argument is unaffected), and thus is able to include the information when it talks to the server. Similarly, the client end of an IPSEC connection knows who opened the connection and could, similarly, convey that information. That data may not be available in some OSes by the time it gets to the IPSEC stack, but that's a deficiency of the OS, not a fundamental problem. It seems to me there's no real difference between the two cases. Cheers, Ben. -- 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: New result in predicate encryption: disjunction support
Scott Guthery wrote: Those interested in predicate encryption might also enjoy Group Authentication Using The Naccache-Stern Public-Key Cryptosystem http://arxiv.org/abs/cs/0307059 which takes a different approach and handles negation. A group authentication protocol authenticates pre-defined groups of individuals such that: - No individual is identified - No knowledge of which groups can be successfully authenticated is known to the verifier I don't understand this one, could you say it again with more words? - No sensitive data is exposed The paper presents a group authentication protocol based on splitting the private keys of the Naccache-Stern public-key cryptosystem in such a way that the Boolean expression defining the authenticable groups is implicit in the split Shamelessly, Scott - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] -- 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: User interface, security, and "simplicity"
Perry E. Metzger wrote: > [EMAIL PROTECTED] (Peter Gutmann) writes: >>> I am left with the strong suspicion that SSL VPNs are "easier to configure >>> and use" because a large percentage of their user population simply is not >>> very sensitive to how much security is actually provided. >> They're "easier to configure and use" because most users don't want to have >> to >> rebuild their entire world around PKI just to set up a tunnel from A to B. > > I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one > of the people who helped create IPSEC. > > Right now, to use SSH to remotely connect to a machine using public > keys, all I have to do is type "ssh-keygen" and copy the locally > generated public key to a remote machine's authorized keys file. > When there is an IPSEC system that is equally easy to use I'll switch > to it. > > Until then, OpenVPN let me get started in about five minutes, and the > fact that it is less than completely secure doesn't matter much to me > as I'm running SSH under it anyway. > (As a disclaimer, I've hacked a little on Tunnelblick (the mac os x GUI) and I've talked at length with the creator of OpenVPN.) I'm always curious to hear what designers of protocols actually use on a daily basis. I'm also really curious how said designers evaluate their choices. I really like OpenVPN. It's really smooth to setup, it's very easy to use on the Big Three Platforms. Have you read the source to OpenVPN? Do you think that it's cryptographically sound? Is it properly implemented? I've found some stuff I wonder about and I'm curious if anyone else has? Regards, Jacob Appelbaum - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: OpenSparc -- the open source chip (except for the crypto parts)
On Thu, 1 May 2008, zooko wrote: > I would think that it also helps if a company publishes the source > code and complete verification tools for their chips, such as Sun has > done with the Ultrasparc T2 under the GPL. To be sure that implementation does not contain back-doors, one needs not only some source code but also a proof that the source code one has is the source of the implementation. With open-source software one can get such a proof by compiling the source themself (as far as they trust their compiler toolchain), but I don't see any way to get such a proof for non-FPGA hardware. -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
