Wouldn't different IV (or nonce in CTR mode) effectively stop that potential problem?
It would that particular problem, yes. As rsyncrypto is currently implemented, the IV is not embedded in the file at all (except as part of the encrypted key) - hence my confusion. My other points regarding why not one symmetric key for the entire archive do still stand, however.
Counter mode is horrible for this application, for two reasons:
First, any change to the file that adds or removes even a single byte causes the entire cypher text to change from that point on. This makes it quite rsync unfriendly indeed. This is not the case with rsyncrypto.
The more horrible reason, however, is that counter mode has zero resilience to key reuse. A simple XOR of the cypher texts from two encryption passes will cancel out the encryption, key and all, and leave you with a XOR of the plain texts.
A bit change in CTR mode shouldn't alter anything past it's block, from what I understand. There's no state that's moved on from one block to the other (well, except the counter, but that's not affected by the block data).
And again, wouldn't different IV / Nonce effectively stop that problem?
No. A bit change won't propagate a change beyond that bit, but an attacker watching the two stream (before and after the update) will have complete knowledge on precisely which bits have changed and which remained the same. Reusing the same keys for CTR is no more secure than using a one time pad twice (i.e. - not particularly).
You will note, however, that I did not say a bit change. I talked about adding or removing a bit. That will change the entire rest of the stream, as stated.
A different IV/Nonce will solve that problem, at the cost of completely eliminating the advantages. Now instead of the stream being different from the point of the stream onwards, it is completely different from start to finish. The whole point of changing anything from the standard was so that rsync can efficiently transfer the (changed) file to the backup server. That requires that changes to the plain text create localized changes to the cypher text. CTR simply does not have that property.
I forgot to add an important note. The test I ran was to encrypt the files using the public key. Since you are claiming that a symmetric key would have done just a swell, it would make more sense to run the test with the private key. If you know RSA as well as you claim to, you should know that using the private key is even faster.
> The more important question, however, is why did the alleged "needless use of > RSA" trigger such a huge red flag for you? What is the reason we should not > use RSA?
Because public-key cryptography, while being super awesome and very useful in many situations, is orders of magnitude slower than private-key cryptography
Wow. All of this over performance? I was prepared to hear some convoluted explanation about security, but performance got you so angry?
Unless you are backing up 10,000 files with an average length of 10 bytes, the time for performing 10,000 RSA decryptions is negligible compared to the time it will take to actually encrypt said 10,000 files (not to mention, store the to the disk and/or transmit them over the network). I will gladly accept counter arguments if they are backed up by actual data.
For the record, here are my own tests, from a few seconds ago. All tests on an SSD: Create 10,000 files with 10 bytes of zeros. Time output: real 0m12.213s user 0m0.396s sys 0m1.464s
Encrypt said 10,000 files with rsyncrypto (including symmetric encryption and compression) with a 1024 bit RSA certificate: real 0m12.817s user 0m1.288s sys 0m3.308s
Encrypt said 10,000 files with rsyncrypto with a 2048 bit RSA certificate: real 0m13.518s user 0m1.924s sys 0m3.312s
To me, spending the extra 1.7 seconds (CPU time, much less for wall time) for 10,000 files no one in his right mind will even want to back up is negligible.
When I hear about hard-disk I/O and synchronization
Who even brought it up? The only context in which I said "synchronization" was machine to machine synchronization: i.e. - rsync.
It seems to me like you are thinking of using rsyncrypto for purposes vastly different than the ones for which it was designed for. That's fine, of course, but complaining that it does a poor job there is off topic and redundant. Rsyncrypto is not built for full disk encryption. It is built for using untrusted storage for backup over a network. This is not everyone's need, but it is both the story poster's need and the original commenter.
Moreover, even if you do use different keys for each file, those keys can still be encrypted with symmetric crypto.
Yes (well, no, see later), but why WOULD you? Like I said above, the performance argument is bull, and you do lose capabilities.
As for the backup example, that does not make much sense.
I have no idea what you are talking about, which leads me to believe you did not understand what I said. What I said was that you might back up several machines to the same storage provider. Using public key allows you not to have your entire data compromised by having one of those machines compromised. Also, not needing your master decryption key in order to encrypt means the chances it gets compromised are, more or less, zero.
Do not get me wrong. This is not personal and I'm not attacking you, so stop being so defensive. I simply made an initial comment that the devs don't seem to know what they're doing in regards to crypto, and then you challenged me and I simply detailed why I made the claim. I appreciate and respect open-source work, but unless you can back up your design choices with pertinent arguments, try to swallow criticism more easily. There's a reason why "don't make your own crypto" is a rule of thumb for programmers. Unless you're working in the field, let the experts deal with this. Or go study. "I have some crypto knowledge" is not enough to justify modifying existent mode of operations such as CBC.
In order for you to be able to pass the above passage as likely, you should have done two things. You did neither. You needed to: 1. Show an actual design failure. At best, all you did was show a dislike to RSA due to performance rea
I should point out that this comment, beginning to end, is criticism over rsyncrypto for following industry best practices, while previous comments (including this one, from the same author) were criticism for not following best practices. I do wish you'd make up your mind:-)
a) You do not want to encrypt all files involved using the same symmetric key. Care to explain why? There is nothing wrong with using the same key for multiple files.
If two files are identical (or even start off identical), having them encrypted to different cypher texts is a nice bonus to have. This also makes an attacker's work more complicated, as there is no one jackpot to concentrate all effort into. Like I said above, this is just best practice. You'd be just as critical, if not more, had I used the same symmetric key for all files.
Anyway, if the main key is leaked then all the keys can be derived, so how is this different than using a single key?
See my answer below.
b) With this scheme, you only need to reliably and securely store one key And this is different from symmetric crypto how? Where does the need for asymmetry come from? Does the set of people capable of doing one direction of the operation differ from the set of people that can do it backwards?
People, maybe not, but machines - certainly. This way, the trust level you need to assign to a machine in order to allow it to back up data is lower than the trust level you need in order to restore. This mode allows you to have several machines back up to the same store, with one compromised not meaning they are all compromised.
Which means that there is no reason for the master key to be compromised, as there is no reason for it to be anywhere but in a vault, only to be retrieved if a restore is needed. This is not something you could do had the master key been symmetric.
And the bottom line is that all of the above just boils down to "industry best practices". It is the exact same thing PGP does when encrypting files and messages.
The more important question, however, is why did the alleged "needless use of RSA" trigger such a huge red flag for you? What is the reason we should not use RSA?
I have posted an answer to AC below (in this comment). On the off-chance that your use of Ad-Hominem was not a sign of the ordinary way you conduct discussions, I hope you will find the comment linked above provides an answer to why RSA is, in fact, needed.
As for inventing our own crypto - you are more than welcome to offer a standard way that resolves the core need. The AC below you offered counter mode, and I hope I showed why "we" didn't think it was a good idea to use it (thus also refuting your claim that "we" have no idea what "we're" doing).
I did not want to invent my own, but had no choice. With that, I did the next best thing - I did it the least secretive way I could. The implementation is documented in detail, and the implementation is open source.
I also consulted a few people who know more about cryptography than I do. I got one offer for an alternative implementation that was marginally more secure, but was not O(n) (and, therefor, also not suitable for one pass). I was offered zero (0) viable attacks against the algorithm (or the implementation), except the obvious one (i.e. - that the attacker can see approximately how much and where things changed between the versions). I should point out that at least the "how much" is also true for the "use rdiff" suggestion that started this thread.
Uhm, that property is exactly what you DON'T want in an encryption algorithm. There's a reason we don't use ECB mode. And if you rely on compression for security, you're doing something wrong. Anyway, if you just want to be able to diff encrypted files, what's wrong with counter mode? No need to invent a new mode, right?
I also don't understand why RSA is needed here. What's the point of asymmetric crypto when there's only one party involved?
1. Rsyncrypto is very very very far from ECB. I am hard pressed (but open to counter examples) to find a real life file that exhibits cypher text repetitions due to plain text repetitions. This is not the case with ECB, as clearly evident from the ECB wikipedia page. 2. Your statement about compression is strange. It is quite customary to compress before encrypting. Partly because compressing after encrypting makes no sense at all, but also because compression increases the bit entropy of the data, making known plain text attacks harder. It is true that rsyncrypto is more sensitive to such things than other algorithms. It is this little thing I like to call a "trade off". Anticipating your objection, ECB with compression is better than ECB without, but still pretty horrible. You will get repetitions the length of the compression blocks. Like I said above, this is not the case with rsyncrypto. 3. RSA is needed because you do not want to encrypt all files involved using the same symmetric key, but you also don't want the secret your backup depends on to need constant updating. With this scheme, you only need to reliably and securely store one key (the RSA key), but each file is encrypted with a different key.
Counter mode is horrible for this application, for two reasons:
First, any change to the file that adds or removes even a single byte causes the entire cypher text to change from that point on. This makes it quite rsync unfriendly indeed. This is not the case with rsyncrypto.
The more horrible reason, however, is that counter mode has zero resilience to key reuse. A simple XOR of the cypher texts from two encryption passes will cancel out the encryption, key and all, and leave you with a XOR of the plain texts.
The advantage is that the incremental diffs don't accumolate on your computer, making your entire archive volatile (lose one rdiff, lose everything after that point). You just sync like you always do.
Theoretically, rsyncrypto is less secure. I am, of course, far from being objective about this point, but I believe this is not a practical weakness for most people, even with the renewed (justified) paranoia. Then again, the tradeoffs are clearly discussed on the project's site, so you are free to draw your own conclusions on the matter.
Your OEM probably changed the signature on the APK they pre-installed.
You can upgrade a pre-installed APK from Google Play. This is not a problem. Unless, that is, the package name for the new and old APKs is the same, but the signing certificate is not. This is not a bad thing, except when %!@#(*# OEMs re-sign APKs they pre-install.
I made a living off localizing android systems for the local market, and I always had a bit of a hard time explaining to the clients why I couldn't localize none-core apps (which include the Google Play itself, for which the Hebrew translation seems to have been done by someone quite illiterate).
After the trial, in which Apple won $1bn, Samsung announced a price hike on chips it was selling Apple, estimated to cost Apple $8bn. In addition, Samsung announced it would not continue selling Apple chips altogether past a certain date.
Thing is, Samsung has Fab technology that's hard to replace. There is a reason Apple chose Samsung to begin with. It's not a simple case of "oh, we'll just buy from someone else".
At least where I live (Israel), most (but not all) criminal charges require a "criminal intent" component. You cannot be charged with murder if you did not intend anyone killed (but can be charged with man slauter, as that one doesn't require criminal intent).
As far as I know (IANAL), speeding requires criminal intent. If you show you had no reasonable way of knowing you were speeding, you cannot be charged. The reason that works is that certain types of negligence are enough to show criminal intent (so you cannot claim you had no way of knowing you were speeding because your speedometer is busted).
I should point out that driving with busted road lights is an offense that does not require criminal intent. Despite that, there was a case of a police car that drove after a driver for some time, and at one point stopped the driver for malfunctioning break light. The judge acquitted, because he said that policemen's own testimony was proof that the lights were functional at the beginning of the drive, and that the driver had, therefor, no way of knowing there was a problem. To the best of my understanding, this ruling is against the letter of the law, but it does come as a counter example. That particular judge has a number of surprisingly sane sentences, which might suggest that it is an exception.
According to international law the West Bank settlements are illegal, period. Nothing arguable about it.
So, essentially, you are saying "I am right, and how dare you say otherwise". Exemplary use of logic and facts to foster discussion. Even if we accept the "illegal" part, however, (and, like I said, claiming there is no argument over that point is easily proven wrong), to the best of my knowledge, the settelments have never been annexed, unlike what your claim says.
Other than fixing my quote, you appear to be saying that yes there are various types of Israel critics, but essentially they are all different shades of stupid.
I do not think I did. In fact, I don't think any of the synonyms of "stupid" even appeared in my comment. The middle groupd I clearly labeled as "human". The last one can best be referred to as "truth agnostic". The only reference to IQ I made was to claim that being a member of the middle group does not make you either stupid or moraly corrupt (my original phrase was "otherwise intelligent and moral").
In fact, confirmation bias is a well known trait in areas far removed from this particular conflict.
Thankfully you allow there might be a tiny minority that is reasonable but remains unheard.
Feel free to point out counter examples. Which one would draw your attention. Someone saying "Israel murders hundreds of children every year", or "Israel's decision to attack in Gaza is wrong, despite the missile attacks on it".
Well I can agree that it is hard to find reasonable discussion on the subject. That is on the reflexive supporters too, though.
With these last statements I do, in fact, agree. It is part of why I categorized the behavior as "human". All I can do about that, however, is do my very best not to be part of that particular problem.
Do you agree they are separate things though? Would you say it is possible to be opposed to Israel's treatment of the Palestinians and arguably illegal annexation of land, because of the facts rather than their Jewishness?
(Sorry for fixing your quote. Otherwise your establishing your views as fact, which I'm sure you're too interested in the truth to do).
As someone who often takes part in those highly informed discussions (aka mud slinging), almost always on the Pro-Israeli side, I've come to categorize the anti-Israel commenters into three groups:
Informed Dissenters Those are people who take an objective look at things, and decide they disagree with some of the decisions taken by the Israeli government.
You hardly ever hear them. The reason being - they are not extreme enough. Under the correct conditions, I can be considered a member of that group. When you criticize someone, you point to specific decisions and actions and voice your opinion about them. Over a background of people yelling "RACISM" and "MURDER", you are never heard.
Misinformed Dissenters These are often otherwise intelligent and moral individuals, who, for some reason, think that in this particular issue it is okay to: 1. Not bother to hear both sides of the story before strongly making up your mind, thereafter not bothering to listen to anything anyone tells them to the contrary and 2. Thinking it is okay to shout said misinformed mind in every possible forum, whether relevant or not.
My personal hobby is to politely make these people confornt their own holes in their logic until cognitive dissonance causes them to call me names. At least on Slashdot, they often see they went out of line (I did say they were otherwise intelligent and moral). I like to think that enough doubt seeps in for them to eventually drop either 1 or 2 from the list above.
Haters They are not misinformed (i.e. - believe facts that are incorrect). They don't care what the truth is. They want Israel down. They will carry signs in demonstrations saying things like "A child murdered every week".
Trying to bring context into discussions with these guys is often a game of whack a mole. Try to bring context into discussions about the blockage of Gaza, and they answer you about the separation wall. Talk about the context of that, and they answer you about occupation. Talk about that, and they shift to the 48 displacement. Talk about that, and they bring up the Balfur declaration. I once replied to that by providing the actual quote of the actual declaration (unabridged), and was accused of selectively quoting from wikipedia.
The bottom line of those is that the mere idea of a "Jewish state" is illegitimate in their eyes. The idea that the Jewish people deserve to govern their own affairs (the definition Zionism) is racism. Those, I am quite happy to call "Antisemists". They do not think that Italy being an Italian Catholic country has anything racist about it.
So, no, not every criticism of Israel is a result of bigotry. Some of it is, and a lot of it is just people being people, acting like people, and not making any sense at all. Very little of it is actually informed, and that last group tends to be the mildest of them all.
Not when you have to go through the "justice" system.
If you are a copyright holder, or acting on his/her/its behalf, and you seed a torrent for me to download, you have, in fact, given me the file. Since you are the copyright holder, that file was given lawfully. You cannot now turn around and sue me for taking from you what you have lawfully given. Your harm, such that there is, is entirely self inflicted.
Honeypots are a useful tool to learn techniques that the other side uses, but they are, by and large, useless as a technique to sue over copyright infringement.
What we have instead is a situation where cops actually get away with things that would send a civilian to prison, everything else being equal. Prosecutors tend to be really unhappy about pressing charges against police, so if they can write it off as "mistake" or "negligence", and just reprimand or demote them, they do so, even when injury or death is involved. The result is that police in US tends to be extremely trigger happy, with numerous cases of mistaken identity, wrong place, mistaking something for a weapon, or miscommunicating the order to drop a legally carried something that could be used for a weapon, ending in deaths of innocent people.
What I'm saying is that I agree with that statement, but believe this case is a poor example in support of it.
Could you, an untrained unpaid person with no body armor no partner and no backup on the way get away with killing a kid because he was holding something that looked like a gun?
The laws of self defense, at least in my area of the world (Israel), let you go if the damage you inflicted is no greater than the damage it was reasonable to assume you might sustain (i.e. - a subjective test). The answer, therefor, is "absolutely yes". IANAL, of course.
If so, why haven't you, do you like kids on your lawn?
My 3yo does not play with pretend weapons (yet?). Answering your real question, though, it all boils down to how reasonable it is to feel threatened. About a decade and a half ago, there was a big terrorist attack during Purim, a Jewish holiday in which it is customary to wear customs. The next year there were a few incidents where children dressed as terrorist were harassed by police (though, as far as I remember, no one was shot). Considering the threat, I consider it reasonable.
I have held and fired rifles. I do not recall any toy I've seen, in a kid's hand or in the store, that looks as realistic as the toy in the link OP gave. That one would have fooled me, as well.
Which is not to say police necessarily acted properly. It all boils down to whether the kid acted as if he was about to use the weapon, on how clearly (if at all) they asked him to put it down, and on whether they properly identified themselves as police. I do not, however, fault them for assuming that was a real weapon.
I think it is beyond dispute that the kid was carrying something that looked like a gun. If the policemen's story is to be believed (I know it's a stretch, but still), then the kid refused to drop it when told to. Under those circumstances, a policeman can justifiably say he felt threatened to the point of shooting.
I file that story under "tragic misunderstanding" rather than "homicidal police".
Sure, the parts are not part of a 3D printed gun, but of the 3D printer itself, but with these parts the printer can be used to print a gun, which is what makes them so dangerous.
The law already has this (IANAL). If you fudge evidence to support your case, and then ask and recveive the death penalty, you are already committing murder.
The probelm isn't so much that a prosecutor would be breaking the law, as the fact that prosecutors are completely and utterly immune to any misconduct perfromed while performing their duty. It is all but impossible to even sue the DA office for damages, even if you prove your case.
Technically, the sequence was a little more complicated.
They were ordered to insert a backdoor. They ignored the order. The government then asked to get the master key. At that point they consented to putting the backdoor in, but it was too late. When they were ordered to hand the master key, they quit.
As far as I can see, an Israeli company's chances of backdooring its own product to help the Israeli intelligence are much lower than an American's.
My source - I have been in charge of product security for Check Point between late 2000 and early 2003. Never once saw any sign of back door. Never saw any request to backdoor. Was never asked to ignore or bury a vulnerability. Was never dissuaded from conducting proactive audits to find vulnerabilities.
What's your source?
Shachar
P.S. Yes, I know that it is possible to read what I wrote as saying that American companies are backdooring their products to help Israeli intelligence. I made a conscious decision not to fix it. You are now free to make fun of this mistake. Enjoy.
Slashdot Mirror
Wouldn't different IV (or nonce in CTR mode) effectively stop that potential problem?
It would that particular problem, yes. As rsyncrypto is currently implemented, the IV is not embedded in the file at all (except as part of the encrypted key) - hence my confusion. My other points regarding why not one symmetric key for the entire archive do still stand, however.
Counter mode is horrible for this application, for two reasons:
First, any change to the file that adds or removes even a single byte causes the entire cypher text to change from that point on. This makes it quite rsync unfriendly indeed. This is not the case with rsyncrypto.
The more horrible reason, however, is that counter mode has zero resilience to key reuse. A simple XOR of the cypher texts from two encryption passes will cancel out the encryption, key and all, and leave you with a XOR of the plain texts.
A bit change in CTR mode shouldn't alter anything past it's block, from what I understand. There's no state that's moved on from one block to the other (well, except the counter, but that's not affected by the block data).
And again, wouldn't different IV / Nonce effectively stop that problem?
No. A bit change won't propagate a change beyond that bit, but an attacker watching the two stream (before and after the update) will have complete knowledge on precisely which bits have changed and which remained the same. Reusing the same keys for CTR is no more secure than using a one time pad twice (i.e. - not particularly).
You will note, however, that I did not say a bit change. I talked about adding or removing a bit. That will change the entire rest of the stream, as stated.
A different IV/Nonce will solve that problem, at the cost of completely eliminating the advantages. Now instead of the stream being different from the point of the stream onwards, it is completely different from start to finish. The whole point of changing anything from the standard was so that rsync can efficiently transfer the (changed) file to the backup server. That requires that changes to the plain text create localized changes to the cypher text. CTR simply does not have that property.
Shachar
Email me.
Shachar
I forgot to add an important note. The test I ran was to encrypt the files using the public key. Since you are claiming that a symmetric key would have done just a swell, it would make more sense to run the test with the private key. If you know RSA as well as you claim to, you should know that using the private key is even faster.
Shachar
> The more important question, however, is why did the alleged "needless use of
> RSA" trigger such a huge red flag for you? What is the reason we should not
> use RSA?
Because public-key cryptography, while being super awesome and very useful in
many situations, is orders of magnitude slower than private-key
cryptography
Wow. All of this over performance? I was prepared to hear some convoluted explanation about security, but performance got you so angry?
Unless you are backing up 10,000 files with an average length of 10 bytes, the time for performing 10,000 RSA decryptions is negligible compared to the time it will take to actually encrypt said 10,000 files (not to mention, store the to the disk and/or transmit them over the network). I will gladly accept counter arguments if they are backed up by actual data.
For the record, here are my own tests, from a few seconds ago. All tests on an SSD:
Create 10,000 files with 10 bytes of zeros. Time output:
real 0m12.213s
user 0m0.396s
sys 0m1.464s
Encrypt said 10,000 files with rsyncrypto (including symmetric encryption and compression) with a 1024 bit RSA certificate:
real 0m12.817s
user 0m1.288s
sys 0m3.308s
Encrypt said 10,000 files with rsyncrypto with a 2048 bit RSA certificate:
real 0m13.518s
user 0m1.924s
sys 0m3.312s
To me, spending the extra 1.7 seconds (CPU time, much less for wall time) for 10,000 files no one in his right mind will even want to back up is negligible.
When I hear about hard-disk I/O and synchronization
Who even brought it up? The only context in which I said "synchronization" was machine to machine synchronization: i.e. - rsync.
It seems to me like you are thinking of using rsyncrypto for purposes vastly different than the ones for which it was designed for. That's fine, of course, but complaining that it does a poor job there is off topic and redundant. Rsyncrypto is not built for full disk encryption. It is built for using untrusted storage for backup over a network. This is not everyone's need, but it is both the story poster's need and the original commenter.
Moreover, even if you do use different keys for each file,
those keys can still be encrypted with symmetric crypto.
Yes (well, no, see later), but why WOULD you? Like I said above, the performance argument is bull, and you do lose capabilities.
As for the backup example, that does not make much sense.
I have no idea what you are talking about, which leads me to believe you did not understand what I said. What I said was that you might back up several machines to the same storage provider. Using public key allows you not to have your entire data compromised by having one of those machines compromised. Also, not needing your master decryption key in order to encrypt means the chances it gets compromised are, more or less, zero.
Do not get me wrong. This is not personal and I'm not attacking you, so stop
being so defensive. I simply made an initial comment that the devs don't seem
to know what they're doing in regards to crypto, and then you challenged me and
I simply detailed why I made the claim. I appreciate and respect open-source work, but
unless you can back up your design choices with pertinent arguments, try to
swallow criticism more easily. There's a reason why "don't make your own
crypto" is a rule of thumb for programmers. Unless you're working in the
field, let the experts deal with this. Or go study. "I have some crypto
knowledge" is not enough to justify modifying existent mode of operations such
as CBC.
In order for you to be able to pass the above passage as likely, you should have done two things. You did neither. You needed to:
1. Show an actual design failure. At best, all you did was show a dislike to RSA due to performance rea
I should point out that this comment, beginning to end, is criticism over rsyncrypto for following industry best practices, while previous comments (including this one, from the same author) were criticism for not following best practices. I do wish you'd make up your mind :-)
a) You do not want to encrypt all files involved using the same symmetric key.
Care to explain why? There is nothing wrong with using the same key for multiple files.
If two files are identical (or even start off identical), having them encrypted to different cypher texts is a nice bonus to have. This also makes an attacker's work more complicated, as there is no one jackpot to concentrate all effort into. Like I said above, this is just best practice. You'd be just as critical, if not more, had I used the same symmetric key for all files.
Anyway, if the main key is leaked then all the keys can be derived, so how is this different than
using a single key?
See my answer below.
b) With this scheme, you only need to reliably and securely store one key
And this is different from symmetric crypto how? Where does the need for asymmetry come from? Does the
set of people capable of doing one direction of the operation differ from the set of people that can do it backwards?
People, maybe not, but machines - certainly. This way, the trust level you need to assign to a machine in order to allow it to back up data is lower than the trust level you need in order to restore. This mode allows you to have several machines back up to the same store, with one compromised not meaning they are all compromised.
Which means that there is no reason for the master key to be compromised, as there is no reason for it to be anywhere but in a vault, only to be retrieved if a restore is needed. This is not something you could do had the master key been symmetric.
And the bottom line is that all of the above just boils down to "industry best practices". It is the exact same thing PGP does when encrypting files and messages.
The more important question, however, is why did the alleged "needless use of RSA" trigger such a huge red flag for you? What is the reason we should not use RSA?
Shachar
I have posted an answer to AC below (in this comment). On the off-chance that your use of Ad-Hominem was not a sign of the ordinary way you conduct discussions, I hope you will find the comment linked above provides an answer to why RSA is, in fact, needed.
As for inventing our own crypto - you are more than welcome to offer a standard way that resolves the core need. The AC below you offered counter mode, and I hope I showed why "we" didn't think it was a good idea to use it (thus also refuting your claim that "we" have no idea what "we're" doing).
I did not want to invent my own, but had no choice. With that, I did the next best thing - I did it the least secretive way I could. The implementation is documented in detail, and the implementation is open source.
I also consulted a few people who know more about cryptography than I do. I got one offer for an alternative implementation that was marginally more secure, but was not O(n) (and, therefor, also not suitable for one pass). I was offered zero (0) viable attacks against the algorithm (or the implementation), except the obvious one (i.e. - that the attacker can see approximately how much and where things changed between the versions). I should point out that at least the "how much" is also true for the "use rdiff" suggestion that started this thread.
Shachar
Uhm, that property is exactly what you DON'T want in an encryption algorithm. There's a reason we don't use ECB mode. And if you rely on compression for security, you're doing something wrong. Anyway, if you just want to be able to diff encrypted files, what's wrong with counter mode? No need to invent a new mode, right?
I also don't understand why RSA is needed here. What's the point of asymmetric crypto when there's only one party involved?
1. Rsyncrypto is very very very far from ECB. I am hard pressed (but open to counter examples) to find a real life file that exhibits cypher text repetitions due to plain text repetitions. This is not the case with ECB, as clearly evident from the ECB wikipedia page.
2. Your statement about compression is strange. It is quite customary to compress before encrypting. Partly because compressing after encrypting makes no sense at all, but also because compression increases the bit entropy of the data, making known plain text attacks harder. It is true that rsyncrypto is more sensitive to such things than other algorithms. It is this little thing I like to call a "trade off". Anticipating your objection, ECB with compression is better than ECB without, but still pretty horrible. You will get repetitions the length of the compression blocks. Like I said above, this is not the case with rsyncrypto.
3. RSA is needed because you do not want to encrypt all files involved using the same symmetric key, but you also don't want the secret your backup depends on to need constant updating. With this scheme, you only need to reliably and securely store one key (the RSA key), but each file is encrypted with a different key.
Counter mode is horrible for this application, for two reasons:
First, any change to the file that adds or removes even a single byte causes the entire cypher text to change from that point on. This makes it quite rsync unfriendly indeed. This is not the case with rsyncrypto.
The more horrible reason, however, is that counter mode has zero resilience to key reuse. A simple XOR of the cypher texts from two encryption passes will cancel out the encryption, key and all, and leave you with a XOR of the plain texts.
Shachar
With any rootable device, you can just delete the old APK from the system folder and clear the package cache. Problem solved.
Shachar
<plug>Or, better yet, use rsyncrypto.</plug>
The advantage is that the incremental diffs don't accumolate on your computer, making your entire archive volatile (lose one rdiff, lose everything after that point). You just sync like you always do.
Theoretically, rsyncrypto is less secure. I am, of course, far from being objective about this point, but I believe this is not a practical weakness for most people, even with the renewed (justified) paranoia. Then again, the tradeoffs are clearly discussed on the project's site, so you are free to draw your own conclusions on the matter.
Shachar
Your OEM probably changed the signature on the APK they pre-installed.
You can upgrade a pre-installed APK from Google Play. This is not a problem. Unless, that is, the package name for the new and old APKs is the same, but the signing certificate is not. This is not a bad thing, except when %!@#(*# OEMs re-sign APKs they pre-install.
I made a living off localizing android systems for the local market, and I always had a bit of a hard time explaining to the clients why I couldn't localize none-core apps (which include the Google Play itself, for which the Hebrew translation seems to have been done by someone quite illiterate).
Shachar
After the trial, in which Apple won $1bn, Samsung announced a price hike on chips it was selling Apple, estimated to cost Apple $8bn. In addition, Samsung announced it would not continue selling Apple chips altogether past a certain date.
Thing is, Samsung has Fab technology that's hard to replace. There is a reason Apple chose Samsung to begin with. It's not a simple case of "oh, we'll just buy from someone else".
Shachar
The one comment thread I thought was safe from politics..... :-)
Shachar
At least where I live (Israel), most (but not all) criminal charges require a "criminal intent" component. You cannot be charged with murder if you did not intend anyone killed (but can be charged with man slauter, as that one doesn't require criminal intent).
As far as I know (IANAL), speeding requires criminal intent. If you show you had no reasonable way of knowing you were speeding, you cannot be charged. The reason that works is that certain types of negligence are enough to show criminal intent (so you cannot claim you had no way of knowing you were speeding because your speedometer is busted).
I should point out that driving with busted road lights is an offense that does not require criminal intent. Despite that, there was a case of a police car that drove after a driver for some time, and at one point stopped the driver for malfunctioning break light. The judge acquitted, because he said that policemen's own testimony was proof that the lights were functional at the beginning of the drive, and that the driver had, therefor, no way of knowing there was a problem. To the best of my understanding, this ruling is against the letter of the law, but it does come as a counter example. That particular judge has a number of surprisingly sane sentences, which might suggest that it is an exception.
Shachar
According to international law the West Bank settlements are illegal, period. Nothing arguable about it.
So, essentially, you are saying "I am right, and how dare you say otherwise". Exemplary use of logic and facts to foster discussion. Even if we accept the "illegal" part, however, (and, like I said, claiming there is no argument over that point is easily proven wrong), to the best of my knowledge, the settelments have never been annexed, unlike what your claim says.
Other than fixing my quote, you appear to be saying that yes there are various types of Israel critics, but essentially they are all different shades of stupid.
I do not think I did. In fact, I don't think any of the synonyms of "stupid" even appeared in my comment. The middle groupd I clearly labeled as "human". The last one can best be referred to as "truth agnostic". The only reference to IQ I made was to claim that being a member of the middle group does not make you either stupid or moraly corrupt (my original phrase was "otherwise intelligent and moral").
In fact, confirmation bias is a well known trait in areas far removed from this particular conflict.
Thankfully you allow there might be a tiny minority that is reasonable but remains unheard.
Feel free to point out counter examples. Which one would draw your attention. Someone saying "Israel murders hundreds of children every year", or "Israel's decision to attack in Gaza is wrong, despite the missile attacks on it".
Well I can agree that it is hard to find reasonable discussion on the subject. That is on the reflexive supporters too, though.
With these last statements I do, in fact, agree. It is part of why I categorized the behavior as "human". All I can do about that, however, is do my very best not to be part of that particular problem.
Can you say you are doing the same?
Shachar
Do you agree they are separate things though? Would you say it is possible to be opposed to Israel's treatment of the Palestinians and arguably illegal annexation of land, because of the facts rather than their Jewishness?
(Sorry for fixing your quote. Otherwise your establishing your views as fact, which I'm sure you're too interested in the truth to do).
As someone who often takes part in those highly informed discussions (aka mud slinging), almost always on the Pro-Israeli side, I've come to categorize the anti-Israel commenters into three groups:
Informed Dissenters
Those are people who take an objective look at things, and decide they disagree with some of the decisions taken by the Israeli government.
You hardly ever hear them. The reason being - they are not extreme enough. Under the correct conditions, I can be considered a member of that group. When you criticize someone, you point to specific decisions and actions and voice your opinion about them. Over a background of people yelling "RACISM" and "MURDER", you are never heard.
Misinformed Dissenters
These are often otherwise intelligent and moral individuals, who, for some reason, think that in this particular issue it is okay to:
1. Not bother to hear both sides of the story before strongly making up your mind, thereafter not bothering to listen to anything anyone tells them to the contrary
and
2. Thinking it is okay to shout said misinformed mind in every possible forum, whether relevant or not.
My personal hobby is to politely make these people confornt their own holes in their logic until cognitive dissonance causes them to call me names. At least on Slashdot, they often see they went out of line (I did say they were otherwise intelligent and moral). I like to think that enough doubt seeps in for them to eventually drop either 1 or 2 from the list above.
Haters
They are not misinformed (i.e. - believe facts that are incorrect). They don't care what the truth is. They want Israel down. They will carry signs in demonstrations saying things like "A child murdered every week".
Trying to bring context into discussions with these guys is often a game of whack a mole. Try to bring context into discussions about the blockage of Gaza, and they answer you about the separation wall. Talk about the context of that, and they answer you about occupation. Talk about that, and they shift to the 48 displacement. Talk about that, and they bring up the Balfur declaration. I once replied to that by providing the actual quote of the actual declaration (unabridged), and was accused of selectively quoting from wikipedia.
The bottom line of those is that the mere idea of a "Jewish state" is illegitimate in their eyes. The idea that the Jewish people deserve to govern their own affairs (the definition Zionism) is racism. Those, I am quite happy to call "Antisemists". They do not think that Italy being an Italian Catholic country has anything racist about it.
So, no, not every criticism of Israel is a result of bigotry. Some of it is, and a lot of it is just people being people, acting like people, and not making any sense at all. Very little of it is actually informed, and that last group tends to be the mildest of them all.
Shachar
The sting works by offering the geek a free movie or a link to a free movie under circumstances which can't possibly be legitimate.
Do elaborate, please.
Shachar
Not when you have to go through the "justice" system.
If you are a copyright holder, or acting on his/her/its behalf, and you seed a torrent for me to download, you have, in fact, given me the file. Since you are the copyright holder, that file was given lawfully. You cannot now turn around and sue me for taking from you what you have lawfully given. Your harm, such that there is, is entirely self inflicted.
Honeypots are a useful tool to learn techniques that the other side uses, but they are, by and large, useless as a technique to sue over copyright infringement.
IANAL
Shachar
What we have instead is a situation where cops actually get away with things that would send a civilian to prison, everything else being equal. Prosecutors tend to be really unhappy about pressing charges against police, so if they can write it off as "mistake" or "negligence", and just reprimand or demote them, they do so, even when injury or death is involved. The result is that police in US tends to be extremely trigger happy, with numerous cases of mistaken identity, wrong place, mistaking something for a weapon, or miscommunicating the order to drop a legally carried something that could be used for a weapon, ending in deaths of innocent people.
What I'm saying is that I agree with that statement, but believe this case is a poor example in support of it.
Shachar
Could you, an untrained unpaid person with no body armor no partner and no backup on the way get away with killing a kid because he was holding something that looked like a gun?
The laws of self defense, at least in my area of the world (Israel), let you go if the damage you inflicted is no greater than the damage it was reasonable to assume you might sustain (i.e. - a subjective test). The answer, therefor, is "absolutely yes". IANAL, of course.
If so, why haven't you, do you like kids on your lawn?
My 3yo does not play with pretend weapons (yet?). Answering your real question, though, it all boils down to how reasonable it is to feel threatened. About a decade and a half ago, there was a big terrorist attack during Purim, a Jewish holiday in which it is customary to wear customs. The next year there were a few incidents where children dressed as terrorist were harassed by police (though, as far as I remember, no one was shot). Considering the threat, I consider it reasonable.
I have held and fired rifles. I do not recall any toy I've seen, in a kid's hand or in the store, that looks as realistic as the toy in the link OP gave. That one would have fooled me, as well.
Which is not to say police necessarily acted properly. It all boils down to whether the kid acted as if he was about to use the weapon, on how clearly (if at all) they asked him to put it down, and on whether they properly identified themselves as police. I do not, however, fault them for assuming that was a real weapon.
Shachar
I think it is beyond dispute that the kid was carrying something that looked like a gun. If the policemen's story is to be believed (I know it's a stretch, but still), then the kid refused to drop it when told to. Under those circumstances, a policeman can justifiably say he felt threatened to the point of shooting.
I file that story under "tragic misunderstanding" rather than "homicidal police".
Shachar
Any chance they'll open source it? Might be better than the currently circulating CADs.
Shachar
Sure, the parts are not part of a 3D printed gun, but of the 3D printer itself, but with these parts the printer can be used to print a gun, which is what makes them so dangerous.
The law already has this (IANAL). If you fudge evidence to support your case, and then ask and recveive the death penalty, you are already committing murder.
The probelm isn't so much that a prosecutor would be breaking the law, as the fact that prosecutors are completely and utterly immune to any misconduct perfromed while performing their duty. It is all but impossible to even sue the DA office for damages, even if you prove your case.
Shachar
Technically, the sequence was a little more complicated.
They were ordered to insert a backdoor. They ignored the order. The government then asked to get the master key. At that point they consented to putting the backdoor in, but it was too late. When they were ordered to hand the master key, they quit.
Shachar
As far as I can see, an Israeli company's chances of backdooring its own product to help the Israeli intelligence are much lower than an American's.
My source - I have been in charge of product security for Check Point between late 2000 and early 2003. Never once saw any sign of back door. Never saw any request to backdoor. Was never asked to ignore or bury a vulnerability. Was never dissuaded from conducting proactive audits to find vulnerabilities.
What's your source?
Shachar
P.S.
Yes, I know that it is possible to read what I wrote as saying that American companies are backdooring their products to help Israeli intelligence. I made a conscious decision not to fix it. You are now free to make fun of this mistake. Enjoy.