If I'm not mistaken (and haven't read up on this stuff in years, so probably), the majority of encryption modes rely on XORing the stream of bits from the cipher with your plain text.
In that way, both sender and receiver need only generate the same cipher bits and apply XOR to encrypt and decrypt (meaning encryption and decryption are actually identical operations!). A side effect of XOR is that a single bit flip in the ciphertext corresponds exactly to a single bit flip in the cleartext. An attacker with knowledge of your cleartext can therefore modify it without ever needing to know the cipher parameters.
Imagine a session cookie that contains a single 32bit integer, the user ID. Now attacker knows his user ID, so he merely needs to XOR the cookie with his ID, then XOR it again with his desired ID and voila admin privileges. Wrapping the cookie in a MAC prevents this kind of manipulation.
I'm not sure I totally follow this (you seem to be talking about an attack on CBC mode, but the mode you're describing sounds more like CTR mode), but a good rule of thumb is, without explicit authentication, attackers can alter and often rewrite messages even though all they can see is ciphertext.
But there are even more problems than that with unauthenticated encryption. If you don't authenticate there is a good chance attackers will be able to decrypt your messages wholesale.
If they can get your system to tell them if a message is valid somehow, perhaps by making thousands of attempts to pass a message and noting where it says 'login failed' or '404' instead of invalid message (for instance) then there are all sorts of things that can be done to recover messages and keys.
I highly recommend Dan Boneh's crypto 101 on coursera for anyone that has the time.
The CBC padding oracle is one such attack. There are a bunch of similar ones. They're "chosen ciphertext" attacks.
Again, even if you get this part right, there are other things that go wrong. TLS is authenticated, and it fell to two adaptive chosen plaintext attacks because of two different implementation details they messed up. And no public cryptosystem in the world has been as thoroughly tested and analyzed as TLS.
For some mind-boggling reason, the designers of the XML Encryption standard decided to make authentication optional, so an attacker can simply avoid sending an incorrect MAC.
I think it's quite simple, and we're all guilty of it at some time or other: it's much easier to reinvent and reshape already solved problems in our own image than it is to innovate in any useful manner.
This explains the abundance of languages that can all trace their conceptual heritage to the 60s, the abundance of basically identical Javascript frameworks, web frameworks, ORMs, and so on, the majority of which IMHO should never have left the spinning rust in the original developer's machine (highly applicable to many of my own projects).
It's also one reason why the 'code cleanup guy' on a team might not be doing anyone a favour – what hard work is he avoiding by endlessly obsessing over his preferred syntactical representation for a 5 line function? etc.
I think this also relates to a youthful rejection of 'good enough' – the desire that, this time around and if only everything was all beautiful and homogenous, it's all going to be perfect.
I'd pay $20/year if you build a reliable HN <-> e-mail comment gateway. I'd pay double if you convinced PG to let your app sync people's comment history. Use e.g. Gmail OAuth IMAP authentication, sync to a label, optionally sync bidirectionally (i.e. comment replies from Gmail), but that's only marginally more useful than getting e-mail archives of comments here.
Hell, if you write it in Python then I'll even donate the comments page parser I already have written (including a comment's original marked up plain text recovered from the HTML).
One of many tiny projects that just need a few concentrated days that I've never gotten around to. I suspect you might find quite a few here willing to pay that same $20/year.
Be careful about putting dollar figures on things like this and estimating demand. What if this guy spends a few hundred hours on this and then no-one buys it? Sure, it's his risk to take, and you carefully qualified your last statement, but overestimating demand is a deadly thing. So let me as - why do you think people will be willing to pay for this service, and what kind of numbers are you talking about? 100? 1000? 10000?
It's just an alternative for someone already offering to work for free – I'm certainly not about to write a business plan around it.
My use case is simply that I like my own comments/SMS/tweets/etc. archived and searchable, as it's an easy way of keeping track of stuff with zero effort. In the case of HN it would also serve to avoid the common situation where I miss a reply until hours after the replyer's lunch break ended.
I had a crude but working version of that written in Go. One goroutine for the scraper, another for the email sender, it's pretty easy. Writing the website and billing is probably more time consuming than the gateway itself.
Literally just poll this single page: http://news.ycombinator.com/threads?id=forgotusername once every 30 minutes, extract the thread structure, generate some message IDs, and keep a database of which message IDs have already been e-mailed.
The ability to reply is more complicated and probably less useful.
Everyone bumps into this at some time on their journey through Python, however personally it's not something I've contended with in years and there is good reason for that:
> Suppose you have a function which takes a person and allows you to update the person's name, age, both, or neither
The problem is not the lack of some fundamental feature, it is one of obviousness in interface design. A trixy interface as given by the example leads exactly to the kind of problems the library hopes to eliminate. Instead how about:
Not only is the problem avoided, but a problem of namespace pollution has been fixed too. Overusing keyword arguments in a hyper-generic manner forces extension of the code to require definition of a new function in order to avoid potential breakage.
For example, how does one add a 'use_html=True' parameter to update_with_email()? Perhaps by adding a 'use_html' kwarg that hopefully doesn't conflict with Person's attribute namespace, or perhaps by adding '_use_html', hoping to skirt the problem by introduction of ugliness. For a 'clean' backwards-compatible solution, we're forced into something like:
How can the caller dynamically form the attribute names if they need to?
# TODO: something seems terribly wrong here, I can't quite put my finger on it.
update(person, **{'previous_' + attr: value})
etc.
I realize abuse of \* \* is very much a religious issue, and at first sight, one of the superficial attractions to Python (at least for me, way back in time), however with experience it seems to regularly introduce more problems than it solves outside a few niche uses. The idea of adding an 'undefined' value has been discussed going back years (try grepping python-ideas and python-dev) and it's never made it in for good reason.
There is one place where an 'undefined' might seem useful at first, for example in the implementation of `dict.pop()` where a missing second argument signals the need to raise KeyError. The problem is that no published, public value including 'undefined' can be used as placeholder without introducing another ugly rule to the language: the ability to use `pop(..., default)` with any default value except 'undefined'! (net simplicity gain: zero)
As a general rule of thumb (standard disclaimers apply), I've found it better to have several functions than one function, if that one function is going to do different operations according to the parameters passed in. ("Operation" is a vague term, but I think setting something vs not setting something would count.) It's all too common for the operation to end up being fixed at the call point, for every call point, and therefore for the path through each call to be the same each time. The parameter/argument system is the wrong mechanism for that.
This line of thinking was inspired by C's `fopen' (no doubt now that I've said that it's going to turn out that I'm the only person ever to have ended up using a string literal for the mode parameter 100% of the time). But I suspect it would be the case for this function too.
Evil routing has been employed a whole bunch of times going back decades, most visibly a couple of years ago when IIRC Iran (?) started advertising bad routes for a bunch of big sites, including Google
Torvalds must be on drugs or also trolling hard to be talking about an absence of carrier lock-in and Android in the same sentence - an OS rendered practically unusable should you elect not to associate your device with a Google account, and all that such entails.
Cell-phone carriers have formed an oligopoly due to the extremely high cost of building nationwide service and the limited amount of mobile spectrum. This will naturally lead to a situation where the industry can stagnate and overcharge with there being very little pressure from new entrants to the market that try to exploit the market failure. Carrier-lockin makes this problem even worse because they make it even more expensive to use their services unless you lock yourself in longterm in exchange for a phone subsidy that amounts to a discount.
Sure, there are lots of concerns about Google having lots of information about you. But at least you have choices, and at least you don't have to pay Google $100/month and pay them more if you want to leave.
What? It's perfectly feasible to have an Android phone and never sign up for a Google account. There are third party app stores (Amazon, GetJar, etc). If you don't feel like using a third party app store you can just install apks directly from the web.
Your device becomes unsellable without the Google lock in. Lots of companies tried it early on in the Android ecosystem. Even those who hit great price points, provided a vanilla Android experience and provided their own app stores failed miserably.
It's just naiive to think you can be successful without Google.
Supporting Google access and requiring it are two very different things. Of course a phone that wasn't capable of integrating with gmail etc would never sell but that doesn't mean that I can't personally opt out if I buy that phone.
In what way is an Android device "rendered practically unusable" when not associated with a Google account? Having run an Android tablet without one for a while, it was pretty much exactly as usable as with a Google account.
If you're in the US, the Nexus 4 doesn't support CDMA, which rules out Sprint and Verizon. AT&T doesn't give a discount for bringing your own phone, so you'd be losing money if you don't take a device for them but buy a data plan. So you're effectively locked into Tmobile.
Postpaid plans are the problem here. They're something of a tax upon people who can't do math if you have a subsidized phone; they're terrible if you bring your own phone.
If you bring your own phone, you want to be looking at the prepaid arrangements. AT&T has considerably cheaper prepaid plans than their postpaid plans (I think it was like $40 cheaper when I looked?). T-Mobile's prepaid plans are even cheaper; I pay $30/month for 100 voice minutes ($0.10/minute overage, which I've hit a couple times), unlimited data (speed-throttled at 5GB), and unlimited texts.
I paid $350 for my Galaxy Nexus and ditched my $90/month AT&T postpaid plan for the $30/month T-Mobile prepaid plan, and the delta in plan costs paid off the cost of the phone (over a carrier subsidy) in about four months.
T-mobile's postpaid "value" plans can also be a good deal (no phone subsidy, but yes contract/ETF). We just moved from the prepaid $30/month/line plan to a family value plan, because we could get 5 lines for <$20/month/line (unlimited talk/text on all lines, 200mb data on two lines).
AT&T doesn't give me a discount for bringing my own phone and Sprint/Verizon went with CDMA instead of GSM, thus the phone is carrier locked in to T-Mobile. I don't know what to make of this. May be magic should've been real - we would get a truly unlocked phone that can be used for free at highest speeds on any network in any part of the world :)
There are pre-paid providers which operate on AT&T networks and offer services (including upto 5GB data) for about $50. If you are not on a family plan, buying an unlocked phone and going pre-paid is actually cheaper.
I've no doubt this presentation makes some interesting points, but I'm as inclined to finish reading it after noticing it's destroying my browser history as I would continue evaluating software after noticing it's randomly corrupting my home directory.
Please leave history alone or at least use window.history.replaceState().
Missed one (which I still consider valid): making it trivial for others to extend the firmware might endanger other products on sale. ATI learned this a few years ago, when it was discovered a software upgrade was all required to turn a sub-$150 graphics card into a far more expensive model.
From the user's perspective, all they see is hardware that can Do So Much More simply with a little firmware jiggery, but from the manufacturer's perspective, they've spent billions developing that firmware and if they choose to differentiate depending on its configuration, and they've paid the infrastructure costs to reach this position of privilege, then as far as I'm concerned that's their prerogative.
The cash market spread is usually something like 4-6 basis points for major pairs (i.e. 0.04%), even accounting for the fictitious mid rate, you still have orders of magnitude difference from the retail spreads. Thomas Cook, a major UK travel agent, is currently offering around 6% for GBPUSD going by their web site.
In that way, both sender and receiver need only generate the same cipher bits and apply XOR to encrypt and decrypt (meaning encryption and decryption are actually identical operations!). A side effect of XOR is that a single bit flip in the ciphertext corresponds exactly to a single bit flip in the cleartext. An attacker with knowledge of your cleartext can therefore modify it without ever needing to know the cipher parameters.
Imagine a session cookie that contains a single 32bit integer, the user ID. Now attacker knows his user ID, so he merely needs to XOR the cookie with his ID, then XOR it again with his desired ID and voila admin privileges. Wrapping the cookie in a MAC prevents this kind of manipulation.