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.)
HN user
I wanted to see what HN was like starting fresh with no karma in 2013.
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.
Unsafe for what, how? You're making all sorts of claims and now an accusation without backing them up with a shred of evidence.
XTS is only useful for FDE, everything else should look for simpler constructions.
Maybe you need to read:
http://cactus.eas.asu.edu/partha/Teaching/539-CommonFiles/Cr...
Would really appreciated if you would know you're talking about and provide evidence before saying "it's wrong" or "it's bad advice."
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.
Outbound leads (investment, jobs, customers) are way, way harder than inbound. Even for YC alums, inbound is your friend.
[0] http://techcrunch.com/2014/02/15/was-y-combinator-worth-it/
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.
Edge cases. The big picture is that it's not happening fast enough, which is why the government will need to step in and will need to assume a leadership role to push hard on this.
Yes. \o/
Anything less is control-freak, incumbent cronyism with a mafia protection fee.
No problem, I wrote a script to fetch it for those uncomfortable with CVS.
https://github.com/LibreSSL-Portable/libressl-portable/blob/...
Mountain View (for obvious reasons I guess): Google Express.
But really, what difference is there over just extracting the functionality of local courier into a stand-alone global service with an web presence, API, support, backoffice fleet management/dispatching and so forth? All FedEx and UPS have to do to compete with this is send drivers into stores.
Nope. It is what it is: capital-intensive research that is hard and it takes a long time to come up with a molecule that will stop an infection without killing or disabling the patient. That can't be done last minute like in the movies.
FYI: One of the last-ditch antibiotics (I forget the name) has a side-effect of permanently damaging hearing. I have to basically yell at 95 yo grandmother for her to hear me. :)
That's part of it, but this is something governments have to take leadership on right now. That will only happen with direct pressure. Waiting until it's the leading cause of death will be too late, because of drug development pipeline timeframes.
It doesn't have to be that way, and waiting around for "someone else to handle it" will likely lead to a Tragedy of the Commons.
Call your representatives [US: 0,1] or regional government representative (I just called my senator, and on hold for house rep now), tell them we need an emergency crash program to develop new, tightly-regulated antibiotics so that infection doesn't become the leading cause of deaths in 2025. Because it takes years and billions to develop new antibiotics, this is something companies will not pursue on their own initiative. If not, it'll be a return to the 19th century. Good luck with that.
[0] http://www.house.gov/representatives/find/
[1] http://www.senate.gov/general/contact_information/senators_c...
Exactly. But because of the difficulty, time and capital requirements, this is something that can't be left to the market economics. It will be too late by the time we need them because of the years it takes to develop a single new drug. This is a "going to the moon" type thing that needs to happen if we intend to survive. Because that's what's at stake.
That's one side, the other side would be a crash program to develop a spectrum of closely-guarded, last-resort antibiotics.
I don't eat meat or consume animal-derived products for this reason. This is where the next pandemic is mostly likely to originate, and it's completely preventable.
On a personal note, my mom is still under the weather, having stuck to three different courses of antibiotics for a simple nasal infection.
It's frightening when this becomes the norm, not the exception because we're basically running out of options by natural selection moving faster than research.
We need a crash program to develop antibiotics before it's too late.
TL;DR: If owned, start from a fresh base system.
I think you meant "someone gets privileged code execution," which is a sensible assumption. Even still, app-permission (less than privileged) code execution can still do damage like host malware, IRC dumpsites/bot control, diodes, tor relays, vandalize web properties, etc.
The only way to know that a system is no longer owned for certain is to reimage it to a known good state. Doing anything less is tons of work, and unlikely to catch everything (rootkits, backdoors, hidden services, replaced system files, etc.). Even when running HIDS, HIDS cant be trusted because rootkits can hide things from it because it's running from the system with a possibly infected kernel. So, it turns out reimaging is less work and more trustworthy if the box is rebuilt and the 'sploit can be mitigated before bringing it online to the outside world (build and patch offline to avoid getting re-owned).
Popularity stats/maths is easy to explain:
it's like a differential equation, dsuccess/dt ~ success
Just the same as new stories on HN, where a single upvote makes it much more likely to take off.
The reason is that (almost) no one wants to take the risk of being "first": whether at an empty restaurant, liking, kickstarter, comments, etc. But then as more people pile on, it increases faster.
So Thomas, it's not a tautology... it's human behavior. :-)
Parking structures might become high-security, automated bldgs that people don't enter. Further, local parking spaces may be unnecessary as your car (or the car you rent) will pick you up.
The interesting problems are:
- tracking thousands of objects' trajectories to avoid as many threat-weighted collisions as possible. (think NYC times square)
- not going too fast when visibility is blocked
FYI: When I was at Trimble Nav, there were self-driving farm equipment demonstrated c. 2000.