Copy Offload [LWN.net]

Copy Offload

Posted Apr 18, 2012 7:01 UTC (Wed) by eternaleye (guest, #67051)
In reply to: Copy Offload by feknight8
Parent article: 2012 Linux Storage, Filesystem, and Memory Management Summit - Day 1

Brute-forcing 4096 bits is infeasible, true.

But you only need to use brute force if the algorithm is strong. If the algorithm is weak, or uses a predictable source where there should be a random one, breaking it can become orders of magnitude easier. Case in point, brute-forcing 128 bits is a hassle, even if it is feasible. THis doesn't prevent MD5, a 128-bit hash function, from being so broken that it is feasible to create collisions in ~10 seconds on a 2.6GHz Pentium 4 ( http://www.win.tue.nl/hashclash/On%20Collisions%20for%20M... [see conclusion])

to post comments

Copy Offload

Posted Apr 18, 2012 9:02 UTC (Wed) by ekj (guest, #1524) [Link]

That has to be the understatement of the year. There are on the order of 2^265 atoms in the universe. Even if every single one of them was a CPU, capable of testing tokens at a rate of 1Thz, thus giving you an aggregate rate of 2^300/s you'd still need the age of the universe times 2^3738 to check them all.

Hitting one by accident won't happen, for the same reason. Now, weaknesses in the algorithm is an entirely different kettle of fish.

Copy Offload - Security

Posted Apr 19, 2012 14:57 UTC (Thu) by feknight8 (guest, #84191) [Link]

The Token == the data. Applications must treat the token in the same way they treat data (if you wouldn't give someone the data, then don't give them the token).

As for devices that build these tokens, yes, dumb designs are possible, as are dumb implementations or buggy implementations. All the standard can do it describe how it is supposed to work, and the standard makes the following statement about the contents of the token:

"The EXTENDED ROD TOKEN DATA field shall contain at least 256 bits of secure random number material (see 4.5) generated when the ROD token was created..."

Those "at least 256 bits" are contained within the 4096 bit structure - which also contains other information.

Sub-clause 4.5 states: "Secure Random numbers should be generated as specified by RFC 4086 (e.g., see FIPS 140-2 Annex C: Approved Random Number Generators)."

Therefore, the token contents are intended to be as secure as FIPS 140 can make it.