Re: Fast MAC algorithms?
I recommend Poly1305 by DJB or VMAC by Ted Krovetz and Wei Dai. Both are much faster than HMAC and have security proven in terms of an underlying block cipher. VMAC is implemented in the nice Crypto++ library by Wei Dai, Poly1305 is implemented by DJB and is also in the new nacl library by DJB. http://cryptopp.com/benchmarks-amd64.html Says that VMAC(AES)-64 takes 0.6 cycles per byte (although watch out for that 3971 cycles to set up key and IV), compared to HMAC-SHA1 taking 11.2 cycles per byte (after 1218 cycles to set up key and IV). If you do any measurement comparing Poly1305 to VMAC, please report your measurement, at least to me privately if not to the list. I can use that sort of feedback to contribute improvements to the Crypto++ library. Thanks! Regards, Zooko Wilcox-O'Hearn --- Tahoe, the Least-Authority Filesystem -- http://allmydata.org store your data: $10/month -- http://allmydata.com/?tracking=zsig I am available for work -- http://zooko.com/résumé.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: The clouds are not random enough
Why Cloud Computing Needs More Chaos: http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html [Moderator's note: ... the article is about a growing problem -- the lack of good quality random numbers in VMs provided by services like EC2 and the effect this has on security. --Perry] The problem is broader than this. A while back, I evaluated a technology that did it best to solve a basically insoluble problem: How does a server, built on stock technology, keep secrets that it can use to authenticate with other servers after an unattended reboot? Without tamper-resistant hardware that controls access to keys, anything the software can get at at boot, an attacker who steals a copy of a backup, say - can also get at. So, the trick is to use a variety of measurements of the hardware - amount of memory, disk sizes, disk serial numbers, whatever you can think of that varies from machine to machine and is not stored in a backup - and combines them to produce a key that encrypts the important secrets. Since hardware does need to be fixed or upgraded at times, a good implementation will use some kind of m unchanged out of n measurements algorithm. Basically, this is the kind of thing Microsoft uses to lock license keys to particular instances of hardware. Yes, it can be broken - but you can make breaking it a great deal of work. Virtualization changes all of this. Every copy of a virtual machine is will be identical as far as most of these measurements are concerned. Conversely, if you try to let the physical level show through - e.g., use the disk serial number of the real disk on which a virtual disk lives - you disrupt some of the things VM's are trying to provide, lie easy transportability of instances from one hardware home to another. The last I heard about the technology I looked at, they didn't have any good solution for VM's (though I haven't kept up and don't know the current status). Ultimately, the only solution is for hypervisors to take on some security roles - passing along unforgeable ID's and random numbers from hardware and other resources that they have access to but do not export to the guest OS's. That doesn't *solve* the problem. It puts us back where we were before the virtualization craze: Needing to write a secure OS and various secure services. However, since hypervisors are much smaller and *much* more limited in operation than full OS's, so the problems may be correspondingly easier to solve. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
AES, RC4
Referring to your note of August 1: I haven't found anything about breaking RC4 if used with a newly randomly generated key (unrelated to any others) for every communication session. I would appreciate being enlightened! (Of course one should throw away initial parts of the stream. I suggested doing this to Ron Rivest RSA in the early 1980s, legitimately knowing about the still-secret RC4 cipher-logic from a client, to whom I made the same suggestion. But even if one doesn't, the result isn't what I would call breaking RC4.) I should say that I was appalled when I first learned of people using RC4 with related keys; its structure certainly suggested to me that there would be vulnerabilities. Is your partly negative recommendation for AES' ...for most new protocol purposes to do with the recent related-key attack? Which I would certainly agree is very disquieting, even though, as you say, it has no current negative consequences. I may speculate elsewhere about who knew what why before the recent publication. Thank you! P. (Peter Schweitzer) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fast MAC algorithms?
Joseph Ashwood wrote: RC-4 is broken when used as intended. ... If you take these into consideration, can it be used correctly? James A. Donald: Hence tricky Joseph Ashwood wrote: By the same argument a Viginere cipher is tricky to use securely, same with monoalphabetic and even Ceasar. Not that RC4 is anywhere near the brokenness of Viginere, etc, but the same argument can be applied, so the argument is flawed. You cannot use a Viginere cipher securely. You can use an RC4 cipher securely: To use RC4 securely discard the first hundred bytes of output, and renegotiate the key every gigabyte. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
ANNOUNCING Tahoe, the Lofty-Atmospheric Filesystem, v1.5
Dear people of Perry's cryptography mailing list: Please check out the new release of Tahoe-LAFS. We claim that it is the first cloud storage technology which offers real security. If you can find a weakness in the cryptographic structure (or any security hole whatsoever), then you will be added to the Hall Of Fame at http://hacktahoe.org . :-) Regards, Zooko --- The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.5 of Tahoe, the Lofty Atmospheric File System. Tahoe-LAFS is the first cloud storage technology which offers security and privacy in the sense that the cloud storage service provider itself can't read or alter your data. Here is the one-page explanation of its unique security and fault-tolerance properties: http://allmydata.org/source/tahoe/trunk/docs/about.html This release is the successor to v1.4.1, which was released April 13, 2009 [1]. This is a major new release, improving the user interface and performance and fixing a few bugs, and adding ports to OpenBSD, NetBSD, ArchLinux, NixOS, and embedded systems built on ARM CPUs. See the NEWS file [2] for more information. In addition to the functionality of Tahoe-LAFS itself, a crop of related projects have sprung up to extend it and to integrate it into operating systems and applications. These include frontends for Windows, Macintosh, JavaScript, and iPhone, and plugins for duplicity, bzr, Hadoop, and TiddlyWiki, and more. See the Related Projects page on the wiki [3]. COMPATIBILITY Version 1.5 is fully compatible with the version 1 series of Tahoe-LAFS. Files written by v1.5 clients can be read by clients of all versions back to v1.0. v1.5 clients can read files produced by clients of all versions since v1.0. v1.5 servers can serve clients of all versions back to v1.0 and v1.5 clients can use servers of all versions back to v1.0. This is the sixth release in the version 1 series. The version 1 series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with Tahoe-LAFS v1. The version 1 series of Tahoe-LAFS is the basis of the consumer backup product from Allmydata, Inc. -- http://allmydata.com . WHAT IS IT GOOD FOR? With Tahoe-LAFS, you can distribute your filesystem across a set of servers, such that if some of them fail or even turn out to be malicious, the entire filesystem continues to be available. You can share your files with other users, using a simple and flexible access control scheme. We believe that the combination of erasure coding, strong encryption, Free/Open Source Software and careful engineering make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or other Cloud storage systems. This software comes with extensive tests, and there are no known security flaws which would compromise confidentiality or data integrity in typical use. (For all currently known issues please see the known_issues.txt file [4].) LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file COPYING.GPL [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to wait for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file COPYING.TGPPL.html [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with docs/install.html [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed thanks to the sponsorship of Allmydata, Inc. [12], a provider of commercial backup services. Allmydata, Inc. created the Tahoe-LAFS project and contributed hardware, software, ideas, bug reports, suggestions, demands, and money (employing several Tahoe-LAFS hackers and instructing them to spend part of their work time on this Free Software project). Also they awarded customized t-shirts to hackers who found security flaws in Tahoe-LAFS (see http://hacktahoe.org ). After discontinuing funding of Tahoe-LAFS RD in early 2009, Allmydata, Inc. has continued to provide servers, co-lo space and bandwidth to the open source project. Thank you to Allmydata, Inc. for their generous and
Re: AES, RC4
- From: PETER SCHWEITZER pe...@infosecsys.com Subject: AES, RC4 Referring to your note of August 1: I haven't found anything about breaking RC4 if used with a newly randomly generated key (unrelated to any others) for every communication session. I would appreciate being enlightened! If a completely unrelated new key is used, and the key has sufficient entropy, and it isn't used for too long, and the entropy of the key is fairly smoothly distributed, and the first several bytes are discarded, and I'm probably missing a couple of requirements, then RC4 is reasonably secure. On the other hand using AES-128 in CTR mode, the key requires sufficient entropy. That is the difference, particularly attempting to make sure there the RC4 kys are truly unrelated is continually difficult. Is your partly negative recommendation for AES' ...for most new protocol purposes to do with the recent related-key attack? Which I would certainly agree is very disquieting, even though, as you say, it has no current negative consequences. The last few weeks have not been kind to AES-256, a couple new attacks, the related key on the full structure, and the more recent significant erosion in other areas. Like I said, not enough to force an immediate retirement, AES-256 remains functionally secure, but the argument for usage is getting more difficult, AES-256 seems to be no more secure than AES-128, and is slower. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fast MAC algorithms?
-- From: James A. Donald jam...@echeque.com Subject: Re: Fast MAC algorithms? Joseph Ashwood wrote: RC-4 is broken when used as intended. ... If you take these into consideration, can it be used correctly? James A. Donald: Hence tricky Joseph Ashwood wrote: By the same argument a Viginere cipher is tricky to use securely, same with monoalphabetic and even Ceasar. Not that RC4 is anywhere near the brokenness of Viginere, etc, but the same argument can be applied, so the argument is flawed. You cannot use a Viginere cipher securely. You can use an RC4 cipher securely: To use RC4 securely discard the first hundred bytes of output, and renegotiate the key every gigabyte. The way to use a Viginere securely is to apply an All-Or-Nothing-Transform to the plaintext, then encrypt, this results in the attacker entropy of the system that is in excess of the size, and therefore a OTP. There are other ways, but this method is not significantly more complex than the efforts necessary to secure RC4 and results in provable secrecy. It is just tricky to use a Vigenere securely. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Protocol Construction WAS Re: Fast MAC algorithms?
-- From: Ray Dillinger b...@sonic.net Subject: Re: Fast MAC algorithms? I mean, I get it that crypto is rarely the weakest link in a secured application. Still, why are folk always designing and adopting cryptographic tools for the next decade or so instead of for the next few centuries? Because we have no idea how to do that. If you were to ask 6 months ago we would've said AES-256 will last at least a decade, probably 50 years. A few years before that we were saying that SHA-1 is a great cryptographic hash. Running the math a few years ago I determined that with the trajectory of cryptographic research it would've been necessary to create a well over 1024-bit hash with behaviors that are perfect by todays knowledge just to last a human lifetime, since then the trajectory has changed significantly and the same exercise today would probably result in 2000+ bits, extrapolating the trajectory of the trajectory, the size would be entirely unacceptable. So, in short, collectively we have no idea how to make something secure for that long. So far, evidence supports the idea that the stereotypical Soviet tendency to overdesign might have been a better plan after all, because the paranoia about future discoveries and breaks that motivated that overdesign is being regularly proven out. And that is why Kelsey found an attack on GOST, and why there is a class of weak keys. That is the problem, all future attacks are rather by definition a surprise. This is fundamental infrastructure now! Crypto decisions now support the very roots of the world's data, and the cost of altering and reversing them grows ever larger. By scheduling likely times for upgrades the prices can be assessed better, scheduled better, and works far better for business than the OH . OUR IS BROKEN experience that always results from trying to plan for longer than a few years at a time. It is far cheaper to build within the available knowledge, and design for a few years. If you can deploy something once, even something that uses three times as many rounds or key bits as you think now that you need, Neither of those is a strong indicator of security. AES makes a great example, AES-256 has more rounds than AES-128, AES-256 has twice as many key bits as AES-128, and AES-256 has more attacks against it than AES-128. An increasing number of attack types are immune to the number of rounds, and key bits has rarely been a real issue. There is no way predicting the far future of cryptography, it is hard enough to predict the reasonably near future. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
GPGPU MD5 collision search shown at Black Hat
An implementation of MD5 collision searching done on GPUs instead of ordinary CPUs -- substantially faster searches with fewer processors. http://www.blackhat.com/presentations/bh-usa-09/BEVAND/BHUSA09-Bevand-MD5-PAPER.pdf I imagine that if anyone really cared to generate such things really quickly, custom hardware would be fastest of all. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: The clouds are not random enough
On Sat, Aug 1, 2009 at 10:06 PM, Jerry Leichterleich...@lrw.com wrote: Why Cloud Computing Needs More Chaos: http://www.forbes.com/2009/07/30/cloud-computing-security-technology-cio-network-cloud-computing.html [Moderator's note: ... the article is about a growing problem -- the lack of good quality random numbers in VMs provided by services like EC2 and the effect this has on security. --Perry] The problem is broader than this. A while back, I evaluated a technology that did it best to solve a basically insoluble problem: How does a server, built on stock technology, keep secrets that it can use to authenticate with other servers after an unattended reboot? Without tamper-resistant hardware that controls access to keys, anything the software can get at at boot, an attacker who steals a copy of a backup, say - can also get at. So, the trick is to use a variety of measurements of the hardware - amount of memory, disk sizes, disk serial numbers, whatever you can think of that varies from machine to machine and is not stored in a backup - and combines them to produce a key that encrypts the important secrets. Since hardware does need to be fixed or upgraded at times, a good implementation will use some kind of m unchanged out of n measurements algorithm. Basically, this is the kind of thing Microsoft uses to lock license keys to particular instances of hardware. Yes, it can be broken - but you can make breaking it a great deal of work. Virtualization changes all of this. Every copy of a virtual machine is will be identical as far as most of these measurements are concerned. I'd imagine (I'm not particularly interested in licence enforcement, so I really am imagining), that the opposite was the problem: i.e. that the host could run you on any VM which might have wildly varying characteristics, depending on what the real machine underneath was, and what else you were sharing with. So, every time you see the measurements, they'll be different. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Unattended reboots (was Re: The clouds are not random enough)
Jerry Leichter wrote: How does a server, built on stock technology, keep secrets that it can use to authenticate with other servers after an unattended reboot? Without tamper-resistant hardware that controls access to keys, anything the software can get at at boot, an attacker who steals a copy of a backup, say - can also get at. I would be very interested in learning what conclusions you came to, Jerry. It is my experience that even *with* tamper-resistant hardware (TPM, HSM, smartcard), the threat of breach is very high if the server is configured for unattended reboots. Almost every e-commerce site (that needs to be PCI-DSS compliant) I've worked with in the last few years, insists on having unattended reboots. Even when the server is configured with a FIPS-certified HSM and the cryptographic keys are in secure storage with M of N controls for access to the keys, in order for the application to have access to the keys in the crypto hardware upon an unattended reboot, the PINs to the hardware must be accessible to the application. If the application has automatic access to the PINs, then so does an attacker who manages to gain entry to the machine. If you (or anyone on this forum) know of technology that allows the application to gain access to the crypto-hardware after an unattended reboot - but can prevent an attacker from gaining access to those keys after compromising a legitimate ID on the machine - I'd welcome hearing about it. TIA. Arshad Noor StrongAuth, Inc. P.S. As an aside, the solution we have settled on is to have the key- custodians enter their PINs to the crypto-hardware (even from remote locations, if needed, through secure channels). While it does not provide for unattended reboots, it does minimize the latency between reboots while ensuring that there is nothing persistent on the machine with PINs to the crypto-hardware. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
