Re: Status of attacks on AES?
On Sun, 4 Jun 2006 16:52:38 -0500, Marcos el Ruptor [EMAIL PROTECTED] wrote: http://defectoscopy.com/forum/viewtopic.php?t=3 http://defectoscopy.com/results.html and http://defectoscopy.com/background.html Are there any peer-reviewed descriptions of your technique? Right now, all that site seems to have -- and forgive me if I've missed a link -- is a set of simple assertions about various ciphers, plus a fairly vague background page. Put another way, and I hate to be this blunt, is there any reason to think your results are correct and/or meaningful? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Status of attacks on AES?
Isn't what you are referring to called secure number of rounds? In other words the number of rounds after which no known attack exists that can break the cipher faster than brute-forcing the key? It looks like I have no choice but to invent a new term, PRF rounds - the number of rounds after which each function that defines the value of each bit of the block/state/output is a pseudo-random function (PRF) of all the bits of the block/state/key/input, in other words a function indistinguishable from random by any existing general purpose randomness tests. Of course dedicate randomness tests exploiting the cipher structure and utilising a significant amount of computational resources could be effective in distinguishing a larger number of rounds from random, but that's in the area of the secure number of rounds research. Can you briefly explain how you determine the PRF rounds value? William - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Trusted path (was: status of SRP)
| ...This is the trusted-path problem. Some examples of proposed | solutions to trusted-path are: | | - Dim the entire screen. | - Use special window borders. | - Use flashing window borders. | - Use specially shaped windows. | - Attach a warning label to all untrusted windows. | - Display a customized word or name. | - Display a customized image. | - Overlay a semitransparent customized image. | - Require the user to press a secure attention key. | - Require the user to click a customized button. | | I'm interested in people's thoughts on what works better or | might work better. (Feel free to add to the list.) I'm going to give a pessimistic answer here: None of the above. You're fighting the entire direction of development of display technologies on end-user machines. There are no fixed standards - everything is subject to change and (we hope) improvement. Applications regularly improve on the standards, or imitate what others have done. Use a specially shaped window? Soon, other applications will start imitating that as a flag for important data. Customized images? How many people will set one. And how hard will it be to fool them with a nice-looking new app that tells you it has a whole library of images you can use for your customized image? There is simply no precedent for people making trust distinctions based on user elements on the screen. They see the screen as similar to a piece of paper, and draw distinctions using the same kinds of rules we've traditionally applied to paper: Does it look professionally done? Is it well written? Does it have all the right logos on it? *None* of these are helpful on the Web, but that doesn't change how people react. The only trusted path most people ever see is the Windows Ctrl/Alt/Delete to enter a password. That's not a good example: The *dialog* it produces is indistinguishable from other Windows dialogs. You should only trust it to the degree that you know you typed Ctrl/Alt/Delete, and haven't yet hit enter. There's no way to generalize this. This is a human factors issue. You have to look at what people actually use to make trust distinctions. As far as I can see, the only thing that will really work is specialized hardware. Vendors are already moving in this kind of direction. Some are adding fingerprint scanners, for example. However, any *generally accessible* device is useless - an attacker can get at them, too. What's needed is some physically separate device, with a trusted path between it and something controlled. A physical button, with a small LCD near it, with enough room for a simple prompt, and you are probably fine. Make *that* part of the browser chrome and you have something. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
Thomas Harold: I do suspect at some point that the lightweight nature of DNS will give way to a heavier, encrypted or signed protocol. Economic factors will probably be the driving force (online banking). Thierry Moreau wrote: E.g. RFC4033, RFC4034, RFC4035. Well I wish it was going to happen, but right now measures that are already deployed are not being used. Except for e-gold, businesses under phishing attack are not signing their email. Since the proposed DNS signing relies on trusted root keys transmitted out of band, it is not going to be deployed either, for much the same reasons. We need a one click solution like SSH, or a zero click solution like Skype. And the proposed solution involves too many connections. Any solution has to fit in a UDP datagram. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of attacks on AES?
Can you briefly explain how you determine the PRF rounds value? William Your question belongs in our forums - http://defectoscopy.com/forum/viewforum.php?f=3 where it's already being discussed. Ruptor [Moderator's note: no, actually, if you're going to mention it here, you had better be prepared to explain and defend it here, too. --Perry] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
kent crispin [EMAIL PROTECTED] writes: On Thu, Jun 01, 2006 at 01:47:06PM +1200, Peter Gutmann wrote: Grab OpenVPN (which is what OpenSWAN should be), install, point it at the target system, and you have opportunistic encryption. Forgive my doltishness, but could you expand on that just a bit, please (or point at the right place in the docs)? I've used openvpn to set up dedicated tunnels, but it isn't immediately obvious to me how it would be configured to do opportunistic encryption. OK, it looks like there are several different views of what opportunistic encryption actually is. My definition was I'd like to talk to X, with encryption if available, which is what the STARTTLS/STLS/AUTH TLS upgrade mechanisms do for POP/IMAP/SMTP/FTP. In that sense no tunnel mechanism (at least that I know of) can really do that, you'd need something like a STARTTLS mechanism for L2TP (the non-opportunistic way of doing this is to run L2TP over IPsec). I don't know why anyone'd want to implement that, since it's easier to just drop in your VPN app or device of choice. The opportunistic encryption that OpenVPN gives you is manual rather than automatic, since there's no way to upgrade any protocol at all to any protocol at all, but with encryption. The reason it's opportunistic is because it allows you to use the equivalent of unauthenticated DH (self- signed/arbitrary-CA certificates) rather than putting you through the torture test of obtaining and configuring a cert from a recognised CA (that's non- opportunistic, and because it's so difficult, frequently just non-encryption). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
* Anne Lynn Wheeler: Florian Weimer wrote: FINREAD is really interesting. I've finally managed to browse the specs, and it looks as if this platform can be used to build something that is secure against compromised hosts. However, I fear that the support costs are too high, and that's why it hasn't caught on in retail online banking. if they can build a $100 PC ... you think that they could build a finread terminal for a couple bucks. sometimes there are issues with volume pricing ... you price high because there isn't a volume and there isn't a volume because you price high. The problem is not hardware costs, but support costs. You really don't want to outsource this to the cheapest call center in the world. Even relatively simple changes like the indexed TAN rollout are rather expensive as a result. there is one issue missing from the actual FINREAD specification. when we were doing X9.59 financial standard ... we allowed for a digital signature for authentication as well as for a digital signature from the environment that the transaction was performed in. the issue from a relying party standpoint ... is what assurances do they have as to the actual environment that a transaction was executed in. consumers could claim they were using a FINREAD terminal when they weren't. counterfeit FINREAD terminals could be out in the wild. You mean something like remote attestation? I find it hard to believe that this capability is available today in a relatively open environment, on a platform supporting multiple applications developed by different applications. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
U. Washington Crypto Course Available Online For Free
http://it.slashdot.org/article.pl?sid=06/06/04/1311243 -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
Florian Weimer wrote: You mean something like remote attestation? I find it hard to believe that this capability is available today in a relatively open environment, on a platform supporting multiple applications developed by different applications. re: http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP i got involved in tracking down a virus/trojan like problem in the 70s on the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet basically if you are going to allow loading of stuff that can do its own execution w/o many safeguards ... you are going to be extremely vulnerable to numerous kinds of attacks. either you have to very tightly control what applications are loaded or possibly do a fixed function deployment that can support multiple different applications ... possibly based on some form of data driven architecture (i.e. the data specification possibly adapts the functional operation to different applications w/o requiring loading of executable code). we had done the AADS chip strawman was done this way ... basically single function operation w/o any ability to load executable code ... that was adaptable to a large number of different applications http://www.garlic.com/~lynn/x959.html#aads another possible solution is very strong partitioning of any loadable executable content that is allowed extremely limited/controlled capability. in the 60s as an undergraduate, i had done a lot with extremely controlled partitioning ... which i learned much later got used in various environments that had extremely high integrity requirements ... random drift http://www.nsa.gov/selinux/list-archive/0409/8362.cfm i had this discussion with the general manager of the business unit that included java and java virtual machine (when it was in its very early infancy) ... turns out that I had done some work with the person (general manager) nearly 20 years earlier in a different life. many of the modern generation of POS terminals are trying to cope with this problem ... getting all sorts of frequent application downloads of various kinds ... and still attempting to operate within constraints of their trusted security module implementation. basically if finread http://www.garlic.com/~lynn/subpubkey.html#finread is countermeasure to widely acceptable PC vulnerabilities (many that arise because of the ease and common practice of loading executable content) ... then if you deploy such a finread terminal that is operated using similar conventions ... then it will acquire similar vulnerability characteristics (as the environment that it is suppose to be a countermeasure for). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: U. Washington Crypto Course Available Online For Free
I do not understand why this course got so much attention. What is special about it (besides available video lectures)? I have a whole collection of links to similar courses. Please take a look at http://www-cse.ucsd.edu/users/maxal/e-books.html Just as an example, I can mention UCSD based course Introduction to Modern Cryptography by Mihir Bellare and Phillip Rogaway available at http://www-cse.ucsd.edu/users/mihir/cse207/classnotes.html Talking about video lectures, I was impressed by Workshop in Algorithmic Number Theory and Workshop in Number-Theoretic Cryptography at Clay Mathematics Institute: http://www.msri.org/publications/video/index01.html Max P.S. If you know other good courses/lectures on the topic missing in the collection, please share. On 6/6/06, Udhay Shankar N [EMAIL PROTECTED] wrote: http://it.slashdot.org/article.pl?sid=06/06/04/1311243 -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: U. Washington Crypto Course Available Online For Free
On Tue, Jun 06, 2006 at 01:57:25AM -0700, Udhay Shankar N wrote: http://it.slashdot.org/article.pl?sid=06/06/04/1311243 It is taught by good people, but I find it a bit strange they are all Microsoft employees. This is perhaps because U. Wash doesn't have any cryptographers. That changes in the fall: they hired an excellent young cryptographer named Yoshi Kohno. == Prof. John R. Black www.cs.colorado.edu/~jrblack Computer Science 430 UCB [EMAIL PROTECTED] University of Colorado Office: +1-303-492-0573 Boulder, CO 80309 USA Fax: +1-303-492-2844 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
