Copy Offload [LWN.net]

Copy Offload

Posted Apr 17, 2012 21:50 UTC (Tue) by feknight8 (guest, #84191)
Parent article: 2012 Linux Storage, Filesystem, and Memory Management Summit - Day 1

> certainly anyone breaking a token effectively has access to all of your data

Tokens are a minimum of 512 bytes in length (4,096 bits). Tokens are typically short lived (typically seconds to a small number of minutes). To guess all possible combinations of a 4096 bit value (2^4096 possible values) within even 300 seconds (which would typically be a long lived token) isn't computationally possible.

Next, even if you did happen to randomly hit one during its valid life time, you do not gain access to "all of your data", you only get access to the subset of data that is represented by the token during that valid window.

Web browsers today typically use 128 or 256 bit public key exchange, and they live for much longer time periods. For tokens, there is no plain text associated with the secure portion, and only private keys are used to create the secure portion of the token (only the creator of the token ever has to perform a decode operation; therefore public keys are not needed).

to post comments

Copy Offload

Posted Apr 18, 2012 7:01 UTC (Wed) by eternaleye (guest, #67051) [Link] (2 responses)

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])

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.