Re: New Technology to Make Digital Data Disappear, on Purpose
d...@geer.org writes: The pieces of the key, small numbers, tend to =93erode=94 over time as they gradually fall out of use. To make keys erode, or timeout, Vanish takes advantage of the structure of a peer-to-peer file system. Such networks are based on millions of personal computers whose Internet addresses change as they come and go from the network. One would imagine that as IPv6 rolls out, the need for DHCP goes to zero excepting for mobile devices attaching to public (not carrier) nets. Yes? Off topic, but actually DHCP is still needed. A machine needs to configure a lot more than just its address and router in common cases (it wants things like DNS servers, NTP servers, etc.) and in large deployments, it is often far easier to let machines autoconfigure these things during boot using DHCP even on comparatively hard wired networks. And with that, lets return to crypto... Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fast MAC algorithms?
-- From: Nicolas Williams nicolas.willi...@sun.com Subject: Fast MAC algorithms? Which MAC algorithms would you recommend? I didn't see the primary requirement, you never give a speed requirement. OMAC-AES-128 should function around 100MB/sec, HMAC-SHA-512 about the same, HMAC-SHA1 about 150MB/sec, HMAC-MD5 250MB/sec. I wouldn't recommend MD5, but in many situations it can be acceptable, and none of these make use of parallelism to achieve the speeds. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fast MAC algorithms?
On Tue, Jul 21, 2009 at 07:15:02PM -0500, Nicolas Williams wrote: I've an application that is performance sensitive, which can re-key very often (say, every 15 minutes, or more often still), and where no MAC is accepted after 2 key changes. In one case the entity generating a MAC is also the only entity validating the MAC (but the MAC does go on the wire). I'm interested in any MAC algorithms which are fast, and it doesn't matter how strong they are, as long as they meet some reasonable lower bound on work factor to forge a MAC or recover the key, say 2^64, given current cryptanalysis, plus a comfort factor. [...] Which MAC algorithms would you recommend? I'm getting the impression that key agility is important here, so one MAC that comes to mind is CMAC with a block cipher with a fast key schedule like Serpent. (If for some reason you really wanted to do something to make secuity auditors squirm you could even cut Serpent down to 16 rounds which would increase the message processing rate by about 2x and also speed up the key schedule. This seems like asking for it to me, though.) Another plausible answer might be Skein - it directly supports keying and nonces (so you don't have to take the per-message overhead of the extra hash as with HMAC), and has very good bulk throughput on 64-bit CPUs. -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fast MAC algorithms?
On Wed, Jul 22, 2009 at 06:49:34AM +0200, Dan Kaminsky wrote: Operationally, HMAC-SHA-256 is the gold standard. There's wonky stuff all over the place -- Bernstein's polyaes work appeals to me -- but I wouldn't really ship anything but HMAC-SHA-256 at present time. Oh, I agree in general. As far as new apps and standards work I'd make HMAC-SHA-256 or AES, in an AEAD cipher mode, REQUIRED to implement and the default. But that's not what I'm looking for here. I'm looking for the fastest MACs, with extreme security considerations (e.g., warning, warning! must rekey every 10 minutes) being possibly OK, depending on just how extreme -- the sort of algorithm that one would not make REQUIRED to implement, but which nonetheless one might use in some environments simply because it's fast. For example, many people use arcfour in SSHv2 over AES because arcfour is faster than AES. The SSHv2 AES-based ciphers ought to be RTI and default choice, IMO, but that doesn't mean arcfour should not be available. In the crypto world one never designs weak-but-fast algorithms on purpose, only strong-and-preferably-fast ones. And when an algorithm is successfully attacked it's usually deprecated, put in the ash heap of history. But there is a place for weak-but-fast algos, as long as they're not too weak. Any weak-but-fast algos we might have now tend to be old algos that turned out to be weaker than designed to be, and new ones tend to be slower because resistance against new attacks tends to require more computation. I realized this would make my question seem a bit pointless, but hoped I might get a surprising answer :( Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Zooko's semi-private keys
On Jul 21, 2009, at 3:11 PM, Hal Finney wrote: The first is equivalent to: knowing g^(xy) is it impossible to deduce g^x, where y = H(g^x). Define Y = g^x, then y = H(Y) and g^(xy) = Y^H(Y). The question is then: Given Y^H(Y) can we deduce Y? To make a simple observation: H matters. If H(z)=0 for all z, then we discard all information and clearly no inversion is possible. If H(z)=1 for all z, then inversion is trivial. If H(z)=n for any fixed non-negative integer n, the problem is exactly discrete log - given (g^x)^n, find (g^x). Now, these are obviously uninteresting hashes. Let's take the simplest 1-1 onto hash, H(z)=z. Then we are asking if, given (g^x)^x, we can find g^x. This feels like the same kind of problem as discrete log, but the additional structure is disturbing. Other simple forms also seem like they might leak information. For example, H(z)=g^z asks the question of whether, given z^z, we can find z. If H(z) is random - i.e., if you use some real cryptographic hash - it's hard to see how you would get a proof, except maybe something of the form for almost all H drawn from some population, the problem is hard. But of course one always makes such arguments before one has a proof -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Fast MAC algorithms?
On Wed, Jul 22, 2009 at 1:43 AM, Nicolas Williamsnicolas.willi...@sun.com wrote: But that's not what I'm looking for here. I'm looking for the fastest MACs, with extreme security considerations...In the crypto world one never designs weak-but-fast algorithms on purpose, only strong-and-preferably-fast ones. And when an algorithm is successfully attacked it's usually deprecated, put in the ash heap of history. But there is a place for weak-but-fast algos, as long as they're not too weak. It just so happens that I worked on a DARPA funded project about 10 years ago looking at the effects of any possible strength vs speed trade off available for different MACing algorithms. We built the capability into FreeS/Wan's IPSec. Some of our MACs were so weak we called them Partial MACs (PMACs). PMACs authenticated only randomly selected pieces of the packet. We figured PMACs were good enough for video - who cares if Eve can feed you a frame or two of partially spoofed video as long as you can't get enough to notice. http://www.isso.sparta.com/documents/acsa_final_report.pdf The major take aways include: 1) HMAC-SHA1-96 can typically triple the amount of CPU required to move IP packets through the kernel over a no-crypto option. HMAC-MD5-96 can double it. 2) If you throw TCP processing in there, unless you are consistantly going to have packets on the order of at least 1000 bytes, your crypto algorithm is almost _irrelevant_. TCP costs up to ~1000 cycles per byte on 10 byte packets, 100 cycles per byte on 100 byte packets, and only gets down to ~15 cycles per byte at 1000 byte packets. For reference, HMAC-SHA1-96 takes about 25 cycles per byte for ~1000 byte packets. These are PentiumII numbers for a Linux 2.2.14 kernel, remember, this was 10 years ago. 3) If your host is actually going to do something with the data you receive, it is really really hard to find something that the crypto algorithm will affect. A coworker of mine struggled for to find a real world desktop application in which you could actually see a result (other then some numbers in a log file). Finally he found that viewing a video remotely in an X-window (thats uncompressed video) would have occasional drops that becomes noticeable if you pick your video well. Our video was of a circular radar screen with a rotating update line (I think it came from a screen saver). With this contrived application, we could change the MAC algorithm and see more or less disturbance in the video. I'd like to emphasize points 2 and 3. You need an application that either doesn't use TCP or that only uses TCP with MTU sized packets to even want to care about crypto performance. I don't think the paper points it out, but all are testing was done with two machines connected directly to each other. Any out of order processing TCP needs to do will only decrease the effect a MAC algorithm has. Also if you want to do _anything_ with the data other than ignore it, it will only further decrease the effect the MAC algorithm has. We tried timing FTP transfers, streaming an MPEG, and numerous other things that I don't remember but all these things had too much overhead to allow the choice of MAC algorithm to be noticed. 10 years of kernel network stack development and CPU improvements may have changed the numbers slightly but I believe you need a really specialized case, probably including real time requirements on marginal CPUs, before you need to look at faster MAC algorithms. Thanks for letting me reminisce about a really fun project (sprinkling rdtsc around the Linux kernel and getting Steve Kent upset (not really) at our attempted subversion of IPSec intent - we ended up doing it the way he wanted even though my way would have been cleaner grin/). -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
