Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On 10/6/13 at 8:26 AM, crypto@gmail.com (John Kelsey) wrote: If we can't select ciphersuites that we are sure we will always be comfortable with (for at least some forseeable lifetime) then we urgently need the ability to *stop* using them at some point. The examples of MD5 and RC4 make that pretty clear. Ceasing to use one particular encryption algorithm in something like SSL/TLS should be the easiest case--we don't have to worry about old signatures/certificates using the outdated algorithm or anything. And yet we can't reliably do even that. We seriously need to consider what the design lifespan of our crypto suites is in real life. That data should be communicated to hardware and software designers so they know what kind of update schedule needs to be supported. Users of the resulting systems need to know that the crypto standards have a limited life so they can include update in their installation planning. Cheers - Bill --- Bill Frantz| If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product.| 16345 Englewood Ave www.pwpconsult.com | | Los Gatos, CA 95032 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
On Oct 4, 2013, at 12:20 PM, Ray Dillinger wrote: > So, it seems that instead of AES256(key) the cipher in practice should be > AES256(SHA256(key)). > Is it not the case that (assuming SHA256 is not broken) this defines a cipher > effectively immune to the related-key attack? So you're essentially saying that AES would be stronger if it had a different key schedule? At 08:59 AM 10/5/2013, Jerry Leichter wrote: - If this is the primitive black box that does a single block encryption, you've about doubled the cost and you've got this messy combined thing you probably won't want to call a "primitive". You've doubled the cost of key scheduling, but usually that's more like one-time than per-packet. If the hash is complex, you might have also doubled the cost of silicon for embedded apps, which is more of a problem. - If you say "well, I'll take the overall key and replace it by its hash", you're defining a (probably good) protocol. But once you're defining a protocol, you might as well just specify random keys and forget about the hash. I'd expect that the point of related-key attacks is to find weaknesses in key scheduling that are exposed by deliberately NOT using random keys when the protocol's authors wanted you to use them. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] AES-256- More NIST-y? paranoia
Le 7 oct. 2013 à 17:45, Arnold Reinhold a écrit : > other cipher algorithms are unlikely to catch up in performance in the > foreseeable future You should take a look a this algorithm : http://eprint.iacr.org/2013/551.pdf - The block size is variable and unknown from an attacker. - The size of the key has no limit and is unknown from an attacker. - The key size does not affect the algorithm speed (using a 256 bit key is the same as using a 1024 bit key). - The algorithm is much faster than the average cryptographic function. Experimental test showed 600 Mo/s - 4 cycles/byte on an Intel Core 2 Duo P8600 2.40GHz and 1,2 Go/s - 2 cycles/byte on an Intel i5-3210M 2.50GHz. Both CPU had only 2 cores. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
On Oct 8, 2013, at 1:11 AM, Bill Frantz wrote: >> If we can't select ciphersuites that we are sure we will always be >> comfortable with (for at least some forseeable lifetime) then we urgently >> need the ability to *stop* using them at some point. The examples of MD5 >> and RC4 make that pretty clear. >> Ceasing to use one particular encryption algorithm in something like SSL/TLS >> should be the easiest case--we don't have to worry about old >> signatures/certificates using the outdated algorithm or anything. And yet >> we can't reliably do even that. > > We seriously need to consider what the design lifespan of our crypto suites > is in real life. That data should be communicated to hardware and software > designers so they know what kind of update schedule needs to be supported. > Users of the resulting systems need to know that the crypto standards have a > limited life so they can include update in their installation planning. This would make a great April Fool's RFC, to go along with the classic "evil bit". :-( There are embedded systems that are impractical to update and have expected lifetimes measured in decades. RFID chips include cryptography, are completely un-updatable, and have no real limit on their lifetimes - the percentage of the population represented by any given "vintage" of chips will drop continuously, but it will never go to zero. We are rapidly entering a world in which devices with similar characteristics will, in sheer numbers, dominate the ecosystem - see the remote-controllable Phillips Hue light bulbs (http://www.amazon.com/dp/B00BSN8DLG/?tag=googhydr-20&hvadid=27479755997&hvpos=1t1&hvexid=&hvnetw=g&hvrand=1430995233802883962&hvpone=&hvptwo=&hvqmt=b&hvdev=c&ref=pd_sl_5exklwv4ax_b) as an early example. (Oh, and there's been an attack against them: http://www.engadget.com/2013/08/14/philips-hue-smart-light-security-issues/. The response from Phillips to that article says "In developing Hue we have used industry standard encryption and authentication techni ques [O]ur main advice to customers is that they take steps to ensure they are secured from malicious attacks at a network level." Even in the PC world, where updates are a part of life, makers eventually stop producing them for older products. Windows XP, as of about 10 months ago, was running on 1/4 of all PC's - many 100's of millions of PC's. About 9 months from now, Microsoft will ship its final security update for XP. Many perfectly good PC's will stay on XP forever because even if there was the will and staff to upgrade, recent versions of Windows won't run on their hardware. In the Mac world, hardware in general tends to live longer, and there's plenty of hardware still running that can't run recent OS's. Apple pretty much only does patches for at most 3 versions of the OS (with a new version roughly every year). The Linux world isn't really much different except that it's less likely to drop support for old hardware, and because it tends to be used by a more techie audience who are more likely to upgrade, the percentages probably look better, at least for PC's. (But there are antique versions of Linux hidden away in all kinds of "appliances" that no one ever upgrades.) I'm afraid the reality is that we have to design for a world in which some devices will be running very old versions of code, speaking only very old versions of protocols, pretty much forever. In such a world, newer devices either need to shield their older brethren from the sad realities or relegate them to low-risk activities by refusing to engage in high-risk transactions with them. It's by no means clear how one would do this, but there really aren't any other realistic alternatives. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Elliptic curve question
On Mon, 7 Oct 2013 10:54:50 +0200 Lay András wrote: > I made a simple elliptic curve utility in command line PHP: > > https://github.com/LaySoft/ecc_phgp > > I know in the RSA, the sign is inverse operation of encrypt, so two > different keypairs needs for encrypt and sign. In elliptic curve > cryptography, the sign is not the inverse operation of encrypt, so my > application use same keypair for encrypt and sign. > > Is this correct? The very general answer: If it's not a big problem, it's always better to separate encryption and signing keys - because you never know if there are yet unknown interactions if you use the same key material in different use cases. You can even say this more general: It's always better to use one key for one usage case. It doesn't hurt and it may prevent security issues. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Always a weakest link
The article is about security in the large, not cryptography specifically, but http://www.eweek.com/security/enterprises-apply-wrong-policies-when-blocking-cloud-sites-says-study.html points out that many companies think that they are increasing their security by blocking access to sites they consider risky - only to have their users migrate to less well known sites doing the same thing - and those less well known sites are often considerably riskier. My favorite quote: "One customer found a user who sent out a million tweets in a day, but in reality, its compromised systems were exporting data 140 characters at a time via the tweets." -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
