midas007

That's the whole point of OTP as an imaginary construction!

It's a way to take any block cipher and turn it into a stream cipher with the power of XOR.

(I'm only going to ask this nicely once: cease and desist stalking and harassment.)

What a flippant, uncivilized, unconstructive comment.

Defense in-depth, every little bit helps.

Don't need your "help," don't care.

"It's unreasonable to debate with an unreasonable person."

Bye.

Absolutely not, that would NOT SCALE.

Again, you're making accusations, shifting the conversation without providing evidence. Talking with you is pointless.

Yes it does, and it's still CTR.

Further, every solution is going to have other machinery solving specific concerns.

You don't call XTS something else because you've used scrypt or PBKDF2 as the PBKDF.

Work is work.

That's trivial to add on, outside of CTR.

You have a system of keys derived from a master key. Too many bytes encrypted with one key? Use a new key for subsequent writes.

(And for god's sake use a PBKDF to derive a master key from a password, don't memcpy() it directly.)

Indistinguishable from a PRF A good block cipher satisfied this property, otherwise it's not a PRF and insecure.

Hair-splitting, really. Actual OTP is an imaginary construction that requires an endless supply of truly random bits that have to be securely stored or somehow recreated during decryption. It shifts the hard part to that fn, and just XORs the result with the pt or ct block.

Fixed.

That's beyond the scope of which mode, but it's important. However the less code one has, the fewer places there are for things to hide.

Yes, it's a known weakness. You have to rekey every X blocks.

Pretty hilariously wrong, and you know it.

Supposed OTP constructions are defined as

e(i) == E(...) ^ m(i)

m(i) == D(...) ^ e(i)

where E(...) = D(...)

and where ... doesnt contain any of the following

e(j) for any j

m(k) for any k

j and k in same domain as i

Then, take a look at CTR...

CTR is E(i) = blockcipher(key, nonce . i) and D(i) = E(i)

e(i) == blockcipher(key, nonce . i) ^ m(i)

m(i) == blockcipher(key, nonce . i) ^ e(i)

(i == counter, since it's the same in this example where counter and blocks start at the same number)

Therefore CTR is an OTP.

? What's wrong with CTR? CTR is basically an OTP. Being OTP, encryption and decryption are basically the same construction (thank you XOR).

    cipherblockdata = blockcipher(key, nonce . block #) ^ plainblockdata
    plainblockdata = blockcipher(key, nonce . block #) ^ cipherblockdata

If MAC is needed, that can happen after encrypting, before decrypting. (Needed if bytes traverse network, but maybe not for local disk or file encryption unless.)

Edit fixed my maths:

TL;DR For random-seek block encryption, don't use XTS, use CTR.

It's simple. I like simple maths and code, it's less to screw up and less for implementations to screw up. For example, I don't trust EC or GCM, even if some people thinks they're the new hotness, because complexity creates more opportunities for obfuscation and puts the code further out of reach of the already few eyeballs actually (or not) looking at it.

Maybe 'cpervica explain why

"and the 'sploit can be mitigated before bringing it online to the outside world"

You should read more carefully.

Also, keeping people waiting without an ETA for a down service because you're learning isn't going to result in happy customers.

Furthermore, whomever is running these boxes needs to deploy NIDS and HIDS and properly secure their boxes, because clearly they don't understand what an attack surface is.