Your average Muhammed simply wants, to quote GWB, to put food on his family. For the higher-ups, it varies. Some want political power, some really believe in the supremacy of the Islam, some want Israeli annihilated. Hamas has a large chunk of people who want all three, in no particular order.
Good for the West Bank, but you won't convince too many Gazans that way. Stiff blockades breed a lot of resentment, and it is always easier to blame the guys imposing the blockade than to blame your own people. And nobody likes to be called a traitor.
Actually, my original idea had one more element. Allow people to immigrate between the two area, with the condition that the local government be allowed to "deport" anyone who moves under said treaty back to the part he came from. Hopefully, this will draw the cool-heads to where life is better, leave the fanatics to brew in their own juice. I am sure of neither how well this will work, nor of how wise/moral it is to bank on people leaving their homes.
I have to say I'm not particularly optimistic. I've had a chance to talk to several people from the Arab world (usually not Palestinian) through blogs and such. The inherent distrust for all things Jewish and Israeli is embedded in their bringing up. I was taught in school many things that were biased, but I was also taught about things Israel (and, earlier, the Jewish settlement) did that were less than favorable, and in some cases downright atrocious. The Arab mistakes/immoralities are NEVER taught in schools in the Arab world.
As a rule, Arabs grow up to being taught that Israel is the ultimate evil, more racist than the Nazis and South Africa in their worst times, and cannot be trusted. Even the the bright and liberal ones, those that understand that Israel has the right to exist and that a peaceful solution must be found, cannot (as a rule) bring themselves to acknowledge that it may not be racist, or that the terrible things that happen in Gaza are not done due to an honest wish for self defense and nothing more.
It is easier with free software activists (I dabbled my hands into BiDi support). There was an initial distrust, but things got down and technical pretty quickly. Then again, I deliberately avoided bringing the subject up, and I believe that so did they.
First of all, congratulations. No sarcasm here. You rose to the challenge of offering a solution where you picked a side based on objective considerations (i.e. - Israel's greater ability to impose a consistent policy), and that plan only relates to one side.
I am sad to tell you, however, that I don't think this plan will work.
There are two problems with it. The first is that Israel's resilience is not infinite. What you suggest was tried before by various governments, and it invariably failed. It failed for two reasons.
First, the extremists on the Palestinian side saw their political power dwindle, and as a result started producing ever more deadly attacks. In other words, many of the attacks on Israel are meant SO that Israel can respond, and thus gain political power to the extremists. Right before the time Binyamin Netanyahu was elected prime minister we have had weeks where we would have several suicide bombers on buses, with tens killed, every WEEK. It was wrecking havoc on any presumption of normality of life in Israel, affecting the economy and was really unbearable.
The second reason this failed is that the more Israeli civilians get killed while the government does not retaliate, the more the Israeli citizens view, with a great amount of justice, that their own government is failing to protect them for some obscure hope that things will be better along the road. A TV satire from the time I talked about earlier showed Shimon Peres, then prime minister, with VR goggles on talking about "a new middle east, peace in our times", while the background showed burning buses. No country should be asked to withstand that, and no politician in any democracy can afford to.
Personally, I think the key to ending the conflict is not by agreeing to tolerate terror, but by raising the standard of living for the Palestinians. Give them hope. The problem is that so long as the government there is not only tolerating but actively advocating terror, letting any resources flow there is an act of suicide.
The real problem is that while not many people are actively fighting against Israel, the great majority of the population views these activity as not only legitimate, but actually desirable. As such, calling it "the acts of a few" is a little naive.
Another part of the problem is that the Palestinians have lost sight of what their objectives are. Analyzing their actions show that "having their own state", "living in safety" and "economical prosperity" cannot conceivably be their goals, as their actions do not further and of them.
Maybe the solution is to continue doing what we are doing with Gaza, while doing everything we can to make life in the west bank better. Let the Gaza residents see that their fellows in the west bank are living several levels of income, personal safety and other quality of life above them, and then hope they come to their senses and change their own goals. Maybe there simply is no solution.
First of all, while indeed only a minority of the Gaza population practices warfare, this practice is considered legitimate and desirable by a great majority of the population. This includes the government. It would have been impossible to maintain the labs and manufacturing required to shoot these missiles otherwise.
Had Gaza been a sovereign state, things would be relatively simple. Israel could address the government and say "you are shooting missiles at us. This is an act of war. Stop it (or, at the very least, take steps to) or we will retaliate". I think even you would agree that one state has the right to do that to another, even if the majority of the citizens in the other state are not participating in actual war activities. The problem here is that the Palestinian government keeps claiming that it is not possible for it to stop it, because they are not organized enough as a sovereign state.
On the other hand, if this were an area of no-sovereignty at all, this would still be (relatively) simple. Israel could simply step in with military force and try to take over the place, and then police it like that government should have. Of course, at this point in time, this is a political impossibility
Which leaves us with only bad courses of action. Israel cannot take responsibility over the area, and Hamas will not. The result is that the residents suffer. Yes, this is a very sad situation. However, at the moment, it is somewhat unavoidable.
If you have a solution, go ahead and offer it. Please bear in mind that Israeli residents of nearby cities have every bit as much right to live their lives without being bombed, however. Also, any solution that asks both sides to do something simultaneously is bound to fail as soon as it is being suggested.
Four Palestinians are killed for every dead Israeli. If this isn't systematic genocide and Gaza isn't a ghetto for Arabs then please enlighten me.
I'll bite. If you start a war against a foe that is better equipped and better trained than you are, then you are going to get out-killed. This is still a war, intentionally fought. That is not what genocide is.
Genocide is when a group is killed, not because of their actions (they were holding a weapon or planning an attack), but because of affiliation (specifically, racial or people affiliation). In order to show genocide you have to show that Israel is deliberately killing civilians that do not participate in the war effort against Israel. Merely pointing out kill ratio is not enough.
But even merely looking at kill ratio is enough to disprove your point, or at the very least call it into question. The kill ratio you mention is not unheard of in combat situation, but it is fairly unheard of in undisputed genocide cases. I doubt the Nazis lost more than a hundred soldiers in their Jew killing operation (even assuming a thousand, this is a 6000:1 ratio, a far cry from your quoted 4:1 ratio). I do believe you will find similar ratios in other genocide cases.
Hating to nitpick and all, but they also seem to lack the "peaceful resistance" part.
Say that the Palestinian are much more likely to achieve their goals if they opt for a peaceful resistance + good PR strategy, and I'll gladly agree. At this point in time, I think peaceful resistance + someone willing to acknowledge Israel's right to exist (and no PR at all) would also work.
What the Palestinians really lack these days are leaders that (a) care what the Palestinian goals are and (b) are capable of actually carrying their weight to impose their will (i.e. - lead). Hamas (arguably) has (b), while Abu Mazen has (a).
While I agree with every factual statement you made (not over the "resistance" platform, corruption etc.), I fail to see how it has any practical bearing on the situation at hand. A vote cast, even assuming a democracy (which Hamas is consistently showing they have no interests in being, say, by killing political opponents from the Fatah), is a vote for an entire platform. Any mitigating factors you can think of (lack of democratic teachings, lack of legitimacy for criticizing the government to name two) does not change the fact that a party, once elected, is not bound to carry out just the reasons that got it elected.
In other words, whether the Hamas platform is what got them elected or not, it is a mandate to their platform.
And it wouldn't have become a precedent even had it gone to court, because it was a small claims court.
Still, as far as the impact on the VENDORS, it is a precedent, which is, arguably, the important bit.
Shachar
IANAL. I'm using common sense here, which may be the wrong tool for the job, but reading the request to appeal, it makes sense to me UNLESS granting it means that the RIAA can appeal this decision twice.
What the RIAA is saying is that it is a question of law that canceled the the previous trial (whether merely making available constitutes copyright violation), and the result of this appeal may result in significant cost savings (if it turns out it is, then no error in the jury instructions, and therefor no need for a new trial). They say this point will be appealed one way or the other, and so they ask to make things simpler and faster by appealing this point now.
This, to me, makes sense, provided the following scenario is not possible:
RIAA get their permission to appeal
RIAA appeals
Higher court agrees with latest finding - making available is not a copyright violation
The entire case goes back to court and gets retried
RIAA loses
RIAA appeals the question of law again
If the above scenario is not made impossible, then the RIAA are actually asking here for an extra, unwarranted, appeal venue, and I see no sense in granting the request.
I find it hard to believe that businesses such as ours are unusual.
Owning such a business myself, I agree with this statement. I also think it is irrelevant.
While you and I know that your company can give a service which is as good, and probably is better, than what RedHat can give (for simple people/client ratio reasons), the PHBs have not had that lesson learned yet. They are looking for "big names" support, and in the case of Linux, the obvious place to search is RedHat. The second RedHat do not provide the service one would expect them to, the general atmosphere in the business world becomes "you cannot get enterprise support for Linux".
Which is, really, the only reason Debian isn't doing better in the corporate market. Its QA level is at least on the same level as RedHat's, the long upgrade cycles are not, generally, a problem for corporations, and it certainly offers many more packages out of the box. The only problem is that the corporations, and even more specifically, the 3rd party ISVs, don't think of it as a "company supported Linux distribution", and don't account for it. This is despite the fact that it is not, generally, difficult to get paid support for it.
oops, Eight encryptions of the same plaintext shifted by one with the same key would be worrying too. Even if there's direct no release of the ciphertexts.
That I don't see. Even if that were somehow true, don't forget that 7 of the 8 are discarded. As an attacker, you never get to see either them or their effect. The only thing you do know is that they did not trigger a change.
I suspect you're left with just whitening the plaintext with a minor substitution cipher (independent key) as that's the only thing that preserves the inter-character patterns that you need.
So far, I have failed to see the advantage of doing that. I did consider switching to a more random (but still not cryptographic) hash function (say - CRC). Another idea was to re-encrypt the buffer with OFB, change the ratio between the minimal buffer before trigger and the trigger average length, and other ideas.
Considering it's often suggested that the first few bytes of an encrypted stream should be completely random (and discarded on decryption) to hide similar files created with the same key,
As far as I know, it's often recommended to never encrypt with the same key twice:-)
I do see your dilemma; you both want to hide the data from the remote and have the remote tell you about tiny pieces of the plaintext of the encrypted blob. With a perfect encryption algorithm it would be impossible for the remote to even tell where in the blob any specific bits of the plaintext reside. With modern compression before the encryption you get very close to this.
At least we do that.
This is starting to sound like DRM, ie something that's impossible because Bob and Eve are the same person.
Well, I think that, unlike DRM, you can get close enough. Especially if the only alternative is not to encrypt at all.
Rsyncrypto lives on a three points trade off triangle. We want to achieve great rsyncability with excellent security, requiring little CPU in order to encrypt.
Standard AES with CBC has to trade off just two factors - security and CPU. We all realize that using a 512 bit key will give better security, but we are not interested in investing the CPU in doing that. Any solution that thinks of merely these two factors is uninteresting to me, because I don't have the hubris to think I can improve on the current industry standard.
I do believe that rsyncrypto gives a reasonable trade off of all three. There is always room for improvement, but I think the current position is around the center of the triangle, which means a reasonable trade off between all three.
Oh well, good luck.
The best summary for this thread I could think of:-)
It is, in fact, not the decision function inside rsyncrypto that is the problem here. It is the one inside gzip that is really problematic.
The decision function inside rsyncrypto is, indeed, a mere sum of a few byte of plain text, but it is compressed plain text, that has high entropy. The same decision function is being employed by gzip as well, however, and there it sums over actual plain text.
Both decision function points can be inferred from the cipher text, by looking where the change begins (gzip decision function) and where it ends (rsyncrypto decision function).
I should just point out that while I agree it is a problem, I am yet to think of an actual attack against this weakness. At the moment, although I am trying to figure out a solution, I am a bit of at a loss as to how severe to rate it. All that is leaked is the fact that the past 8192 bytes of plain text divide by 8192. I referred to it as "leaking 20 bits of aggregate for about every ~12KB (compressed) plain text".
The problem with replacing the decision function with a cryptographic function is the cryptographic function block size. Take, for example, a XOR+AES encrypt of a block, asking that the result divide by 8192. Since you want byte alignment, and since each AES encryption block is 64 bit, you will need to keep 8 such blocks in memory, and update each in turn. Each update requires an AES operation (assuming you remembered the old AES encryption). This means that a single block, which today gets one AES operation, will now require 9. You have just made rsyncrypto 9 times slower.
Is this an acceptable price to pay? Maybe it is. Without understanding how serious the current leak is, it's really hard to answer that one.
We can improve this number by stating that we only detect changes of the delete/add kind if they change an even number of bytes, and reduce the slow down to 5 times. Again, is this a reasonable price to pay? I'm not sure.
After a quick look at it, your decision function worries me.
I'm with you. I talked about it elsewhere, but this is, indeed, a not secure enough aggregate of the last few bytes of the file.
There are several plans for fixing this, but the problem is that fixing this while still being able to generate a reset on a one byte boundary incurs a HUGE performance penalty. I'm still trying to figure out how to handle that one.
the CBC chain is almost the same as using ECB mode to start with.
See discussion elsewhere in this thread for why I think this is not a problem for real-life scenarios.
I'll tell you what - you take it to the mailing list, and we can try to figure the answer out.
Like I said before - this scheme is definitely not as secure as CBC. It's just the "how much less" that I am not worried about, assuming you encrypt real files and not files you generated to be worst case.
picrypt, by Eran Trommer. I doubt it was ever published. Google returns lots of results for picrypt, none of them seem relevant.
Basic idea - prepare slots. Divide the file into sections using a decision function. Place the encrypted section in a slot based on its content (hash function). Keep a list of which sections go where in the actual file. If you are trying to encrypt a section that already exists, merely point to it twice. When you have processed the entire file, dump the memory in the order of the sections, followed by the list of sections.
Advantages - no matter what the file looks like, you will never get a repeat. That is the part that was attacked by my other friend - details further on.
Disadvantages - not one pass. Not even close. More computationally heavy, to the point of not being O(n) (arguable) - Does not solve any of the other attacks on rsyncrypto.
As you can see, I thought the disadvantages outweigh the advantages.
The counter claim to the advantages: The sections list have to be placed in the file somehow. As files can get quite large, it is important that the sections list also be, somehow, rsyncable. This means that instead of repeats in the actual data, you now get repeats in the sections list, and the precise same information can be gleaned from there.
Like I said before - as I have failed to see a file one would actually like to encrypt where the repeat effect is witnessed, I call that attack "theoretical". When someone on the mailing list asked about running rsyncrypto without compression, I made it clear that what he'll get is a significantly reduced strength to the encryption.
So long as all I hear is attacks I've been aware of when the algorithm was designed, I'm good:-)
I did "dd if=/dev/zero of=/tmp/test" for a 200MB file. Encrypting it with rsyncrypto resulted in zero repeats that I could find. In 200MB of zeros, not one ciphertext repeat was generated. This was due to non-alignment between the decision function triggers for the compression and the encryption, which meant that the same IV block for the encryption part started on different places in the compression block, resulting in no repeats over the entire 6.3MB of encrypted file.
The source is out there. Feel free to run your own test.
Re the analysis on slashdot - I posted an answer to the commenter there.
Regarding the other article you pointed to - it has no diff based attack mentioned (that I could find). All the criticism I found there seems mostly done by people who either did not understand what rsyncrypto is meant to do, how it works, or (typically) both. Nothing useful there.
To make it clear, the criticizing comments on linux.com were clueless, while the criticizing comment here was clueful and basically correct, though I disagree with its severity.
In any case, if you want 100% secure, use the industry standard. Rsyncrypto is about performing a compromise. I believe you compromise extremely little security (if measurable), and gain a huge benefit in performance, but I will not claim this is not a compromise.
For the record, I had a claim (even with sample implementation in python) by a friend who is a cryptologist that he has an algorithm that is not vulnerable to the "repeating cipher text" attack. Two problems. One is that the core claim was disputed by another friend who is also a cryptologist. The more serious one is that this algorithm is not O(n), and is definitely not one pass. Rsyncrypto is both, and performance is an important factor. There are people using rsyncrypto to encrypt files larger than 4GB, and you would want such encryptions to end in a reasonable time.
It would be true, except rsyncrypto compresses before encryption. Compression has the great side effect of reducing the repeats in the plain text, which means that you are much less likely to see the effects you describe. The Tux image at wikipedia, for example, will have to be several GB in size, possibly even TB, before you will notice any such effect (and by "notice", I do mean "a program can detect them", not "see with the naked eye").
Using the default rsyncrypto parameters, the repeats will be about 12KB long, which means that your compressed plain text need to have 12KB repeating at least three times for this effect to even show up. Depending on how compressible your data is, this means anything from 36KB to several megabytes (if not more).
The size mentioned is tweakable through the --roll-win, --roll-min and --roll-sensitivity command line options, so you can have a more paranoid setting, if you want. It goes without saying that the more paranoid your setting, the less traffic rsyncrypto will save you when used through rsync.
Note - I'm the one who designed and wrote rsyncrypto.
The only obvious leakage is that an attacker can tell if two files are substantially identical.
Well, no. Two files will likely be encrypted using different session (read - AES) keys, and therefor will not be even remotely similar. One file having two significantly similar areas will show up, however. This case was deemed somewhat remote in my analysis. You are free to perform your own, of course. If you do, please feel free to email me.
The only place where actual data leakage may happen are due to the fact that a persistent attacker can compare cipher texts, and know where the decision function triggered. This is a good point to ask "how much information is gleaned about the file".
I think current rsyncrypto is ok on that front, and future plans include improvements. These improvements, alas, will cost in performance.
I've looked at it a while back (I'm the one who wrote rsyncrypto). When compared with rsyncrypto, the main thing I didn't like (aside from the fact there appears to be no implementation... ) is the amount of state stored. Esync actually needs access to the old plain text file in order to work (or a substantially similar state). Rsyncrypto, on the other hand, needs just a few pieces of state per file, that once created never change. These include the symmetric session key and such stuff, and are about 68 bytes in length.
I really don't remember the details any more, but I think that there were also performance implications to the above.
If want, there is also a program called "murk" http://murk.sourceforge.net/, which implements the same principle as rsyncrypto. As far as I can tell, it is much less mature, and no longer maintained.
IANAL etc, but as far as I can see it, yes you can refuse.
Find prior art. Like other posters said, that is likely.
In order to file the patent, you need to sign a statement, under penalty of perjury, that states that you are not aware of prior art. Claim that you cannot, in good conscious, sign that statement.
If you get fired for this, you have a cause of action - you were requested to do something which is illegal (perjure yourself), and when you refused, you got fired.
Shachar
P.s. If you really try to find prior art, not necessarily from the patent pool, and can't, then maybe this invention deserves to be patented?
As far as I can tell, Debian is not vulnerable in its default install mode.
a - Debian will never automatically downgrade a package. b - Security problems (as opposed to mere changes) get published in the Debian security repository. c - The Debian installer automatically adds the debian security mirror to the end of your sources file.
So, you can create a mirror, easily inject it into the list of official Debian mirrors, and freeze the packages offered on it. You can do all that easily. It won't help you. If you take the CERT example, of the vulnerable openssl package, the fix was pushed through the security repository, and that is added by default to all new Debian installations. The attack would fail.
Furthermore, even if your mirror offered a security mirror as well, I, personally, always keep the Debian source as well, lower in the list. This way, if the local security mirror is up to date, I take stuff from there. If it's not, I take it from the Debian server. This means that even if you deviate from the default behavior, you can still be not vulnerable.
It is amazing how you managed to misunderstand every single one of the points I tried to raise.
Well done!
Just a pointer:
I did not claim that the universe is symmetrical. I claimed that the laws of physics are symmetrical.
The rings do not transfer current, they transfer matter. It's a portable worm hole, if you like. As such, their charge is irrelevant.
I did not claim it is not necessary to dissect something in order to prove it works. I claimed it was sometimes not necessary to dissect something in order to prove it does not work.
Slashdot Mirror
So what would their goals be?
Your average Muhammed simply wants, to quote GWB, to put food on his family. For the higher-ups, it varies. Some want political power, some really believe in the supremacy of the Islam, some want Israeli annihilated. Hamas has a large chunk of people who want all three, in no particular order.
Good for the West Bank, but you won't convince too many Gazans that way. Stiff blockades breed a lot of resentment, and it is always easier to blame the guys imposing the blockade than to blame your own people. And nobody likes to be called a traitor.
Actually, my original idea had one more element. Allow people to immigrate between the two area, with the condition that the local government be allowed to "deport" anyone who moves under said treaty back to the part he came from. Hopefully, this will draw the cool-heads to where life is better, leave the fanatics to brew in their own juice. I am sure of neither how well this will work, nor of how wise/moral it is to bank on people leaving their homes.
I have to say I'm not particularly optimistic. I've had a chance to talk to several people from the Arab world (usually not Palestinian) through blogs and such. The inherent distrust for all things Jewish and Israeli is embedded in their bringing up. I was taught in school many things that were biased, but I was also taught about things Israel (and, earlier, the Jewish settlement) did that were less than favorable, and in some cases downright atrocious. The Arab mistakes/immoralities are NEVER taught in schools in the Arab world.
As a rule, Arabs grow up to being taught that Israel is the ultimate evil, more racist than the Nazis and South Africa in their worst times, and cannot be trusted. Even the the bright and liberal ones, those that understand that Israel has the right to exist and that a peaceful solution must be found, cannot (as a rule) bring themselves to acknowledge that it may not be racist, or that the terrible things that happen in Gaza are not done due to an honest wish for self defense and nothing more.
It is easier with free software activists (I dabbled my hands into BiDi support). There was an initial distrust, but things got down and technical pretty quickly. Then again, I deliberately avoided bringing the subject up, and I believe that so did they.
Shachar
First of all, congratulations. No sarcasm here. You rose to the challenge of offering a solution where you picked a side based on objective considerations (i.e. - Israel's greater ability to impose a consistent policy), and that plan only relates to one side.
I am sad to tell you, however, that I don't think this plan will work.
There are two problems with it. The first is that Israel's resilience is not infinite. What you suggest was tried before by various governments, and it invariably failed. It failed for two reasons.
First, the extremists on the Palestinian side saw their political power dwindle, and as a result started producing ever more deadly attacks. In other words, many of the attacks on Israel are meant SO that Israel can respond, and thus gain political power to the extremists. Right before the time Binyamin Netanyahu was elected prime minister we have had weeks where we would have several suicide bombers on buses, with tens killed, every WEEK. It was wrecking havoc on any presumption of normality of life in Israel, affecting the economy and was really unbearable.
The second reason this failed is that the more Israeli civilians get killed while the government does not retaliate, the more the Israeli citizens view, with a great amount of justice, that their own government is failing to protect them for some obscure hope that things will be better along the road. A TV satire from the time I talked about earlier showed Shimon Peres, then prime minister, with VR goggles on talking about "a new middle east, peace in our times", while the background showed burning buses. No country should be asked to withstand that, and no politician in any democracy can afford to.
Personally, I think the key to ending the conflict is not by agreeing to tolerate terror, but by raising the standard of living for the Palestinians. Give them hope. The problem is that so long as the government there is not only tolerating but actively advocating terror, letting any resources flow there is an act of suicide.
The real problem is that while not many people are actively fighting against Israel, the great majority of the population views these activity as not only legitimate, but actually desirable. As such, calling it "the acts of a few" is a little naive.
Another part of the problem is that the Palestinians have lost sight of what their objectives are. Analyzing their actions show that "having their own state", "living in safety" and "economical prosperity" cannot conceivably be their goals, as their actions do not further and of them.
Maybe the solution is to continue doing what we are doing with Gaza, while doing everything we can to make life in the west bank better. Let the Gaza residents see that their fellows in the west bank are living several levels of income, personal safety and other quality of life above them, and then hope they come to their senses and change their own goals. Maybe there simply is no solution.
Shachar
The problem is that there is no easy solution.
First of all, while indeed only a minority of the Gaza population practices warfare, this practice is considered legitimate and desirable by a great majority of the population. This includes the government. It would have been impossible to maintain the labs and manufacturing required to shoot these missiles otherwise.
Had Gaza been a sovereign state, things would be relatively simple. Israel could address the government and say "you are shooting missiles at us. This is an act of war. Stop it (or, at the very least, take steps to) or we will retaliate". I think even you would agree that one state has the right to do that to another, even if the majority of the citizens in the other state are not participating in actual war activities. The problem here is that the Palestinian government keeps claiming that it is not possible for it to stop it, because they are not organized enough as a sovereign state.
On the other hand, if this were an area of no-sovereignty at all, this would still be (relatively) simple. Israel could simply step in with military force and try to take over the place, and then police it like that government should have. Of course, at this point in time, this is a political impossibility
Which leaves us with only bad courses of action. Israel cannot take responsibility over the area, and Hamas will not. The result is that the residents suffer. Yes, this is a very sad situation. However, at the moment, it is somewhat unavoidable.
If you have a solution, go ahead and offer it. Please bear in mind that Israeli residents of nearby cities have every bit as much right to live their lives without being bombed, however. Also, any solution that asks both sides to do something simultaneously is bound to fail as soon as it is being suggested.
Shachar
Four Palestinians are killed for every dead Israeli. If this isn't systematic genocide and Gaza isn't a ghetto for Arabs then please enlighten me.
I'll bite. If you start a war against a foe that is better equipped and better trained than you are, then you are going to get out-killed. This is still a war, intentionally fought. That is not what genocide is.
Genocide is when a group is killed, not because of their actions (they were holding a weapon or planning an attack), but because of affiliation (specifically, racial or people affiliation). In order to show genocide you have to show that Israel is deliberately killing civilians that do not participate in the war effort against Israel. Merely pointing out kill ratio is not enough.
But even merely looking at kill ratio is enough to disprove your point, or at the very least call it into question. The kill ratio you mention is not unheard of in combat situation, but it is fairly unheard of in undisputed genocide cases. I doubt the Nazis lost more than a hundred soldiers in their Jew killing operation (even assuming a thousand, this is a 6000:1 ratio, a far cry from your quoted 4:1 ratio). I do believe you will find similar ratios in other genocide cases.
Shachar
Hating to nitpick and all, but they also seem to lack the "peaceful resistance" part.
Say that the Palestinian are much more likely to achieve their goals if they opt for a peaceful resistance + good PR strategy, and I'll gladly agree. At this point in time, I think peaceful resistance + someone willing to acknowledge Israel's right to exist (and no PR at all) would also work.
What the Palestinians really lack these days are leaders that (a) care what the Palestinian goals are and (b) are capable of actually carrying their weight to impose their will (i.e. - lead). Hamas (arguably) has (b), while Abu Mazen has (a).
Shachar
While I agree with every factual statement you made (not over the "resistance" platform, corruption etc.), I fail to see how it has any practical bearing on the situation at hand. A vote cast, even assuming a democracy (which Hamas is consistently showing they have no interests in being, say, by killing political opponents from the Fatah), is a vote for an entire platform. Any mitigating factors you can think of (lack of democratic teachings, lack of legitimacy for criticizing the government to name two) does not change the fact that a party, once elected, is not bound to carry out just the reasons that got it elected.
In other words, whether the Hamas platform is what got them elected or not, it is a mandate to their platform.
Shachar
And it wouldn't have become a precedent even had it gone to court, because it was a small claims court. Still, as far as the impact on the VENDORS, it is a precedent, which is, arguably, the important bit. Shachar
IANAL. I'm using common sense here, which may be the wrong tool for the job, but reading the request to appeal, it makes sense to me UNLESS granting it means that the RIAA can appeal this decision twice.
What the RIAA is saying is that it is a question of law that canceled the the previous trial (whether merely making available constitutes copyright violation), and the result of this appeal may result in significant cost savings (if it turns out it is, then no error in the jury instructions, and therefor no need for a new trial). They say this point will be appealed one way or the other, and so they ask to make things simpler and faster by appealing this point now.
This, to me, makes sense, provided the following scenario is not possible:
If the above scenario is not made impossible, then the RIAA are actually asking here for an extra, unwarranted, appeal venue, and I see no sense in granting the request.
Shachar
Owning such a business myself, I agree with this statement. I also think it is irrelevant.
While you and I know that your company can give a service which is as good, and probably is better, than what RedHat can give (for simple people/client ratio reasons), the PHBs have not had that lesson learned yet. They are looking for "big names" support, and in the case of Linux, the obvious place to search is RedHat. The second RedHat do not provide the service one would expect them to, the general atmosphere in the business world becomes "you cannot get enterprise support for Linux".
Which is, really, the only reason Debian isn't doing better in the corporate market. Its QA level is at least on the same level as RedHat's, the long upgrade cycles are not, generally, a problem for corporations, and it certainly offers many more packages out of the box. The only problem is that the corporations, and even more specifically, the 3rd party ISVs, don't think of it as a "company supported Linux distribution", and don't account for it. This is despite the fact that it is not, generally, difficult to get paid support for it.
Shachar
Full disclosure: I am a Debian Developer.
oops, Eight encryptions of the same plaintext shifted by one with the same key would be worrying too. Even if there's direct no release of the ciphertexts.
That I don't see. Even if that were somehow true, don't forget that 7 of the 8 are discarded. As an attacker, you never get to see either them or their effect. The only thing you do know is that they did not trigger a change.
I suspect you're left with just whitening the plaintext with a minor substitution cipher (independent key) as that's the only thing that preserves the inter-character patterns that you need.
So far, I have failed to see the advantage of doing that. I did consider switching to a more random (but still not cryptographic) hash function (say - CRC). Another idea was to re-encrypt the buffer with OFB, change the ratio between the minimal buffer before trigger and the trigger average length, and other ideas.
Considering it's often suggested that the first few bytes of an encrypted stream should be completely random (and discarded on decryption) to hide similar files created with the same key,
As far as I know, it's often recommended to never encrypt with the same key twice :-)
I do see your dilemma; you both want to hide the data from the remote and have the remote tell you about tiny pieces of the plaintext of the encrypted blob. With a perfect encryption algorithm it would be impossible for the remote to even tell where in the blob any specific bits of the plaintext reside. With modern compression before the encryption you get very close to this.
At least we do that.
This is starting to sound like DRM, ie something that's impossible because Bob and Eve are the same person.
Well, I think that, unlike DRM, you can get close enough. Especially if the only alternative is not to encrypt at all.
Rsyncrypto lives on a three points trade off triangle. We want to achieve great rsyncability with excellent security, requiring little CPU in order to encrypt.
Standard AES with CBC has to trade off just two factors - security and CPU. We all realize that using a 512 bit key will give better security, but we are not interested in investing the CPU in doing that. Any solution that thinks of merely these two factors is uninteresting to me, because I don't have the hubris to think I can improve on the current industry standard.
I do believe that rsyncrypto gives a reasonable trade off of all three. There is always room for improvement, but I think the current position is around the center of the triangle, which means a reasonable trade off between all three.
Oh well, good luck.
The best summary for this thread I could think of :-)
Shachar
A quick note.
It is, in fact, not the decision function inside rsyncrypto that is the problem here. It is the one inside gzip that is really problematic.
The decision function inside rsyncrypto is, indeed, a mere sum of a few byte of plain text, but it is compressed plain text, that has high entropy. The same decision function is being employed by gzip as well, however, and there it sums over actual plain text.
Both decision function points can be inferred from the cipher text, by looking where the change begins (gzip decision function) and where it ends (rsyncrypto decision function).
I should just point out that while I agree it is a problem, I am yet to think of an actual attack against this weakness. At the moment, although I am trying to figure out a solution, I am a bit of at a loss as to how severe to rate it. All that is leaked is the fact that the past 8192 bytes of plain text divide by 8192. I referred to it as "leaking 20 bits of aggregate for about every ~12KB (compressed) plain text".
The problem with replacing the decision function with a cryptographic function is the cryptographic function block size. Take, for example, a XOR+AES encrypt of a block, asking that the result divide by 8192. Since you want byte alignment, and since each AES encryption block is 64 bit, you will need to keep 8 such blocks in memory, and update each in turn. Each update requires an AES operation (assuming you remembered the old AES encryption). This means that a single block, which today gets one AES operation, will now require 9. You have just made rsyncrypto 9 times slower.
Is this an acceptable price to pay? Maybe it is. Without understanding how serious the current leak is, it's really hard to answer that one.
We can improve this number by stating that we only detect changes of the delete/add kind if they change an even number of bytes, and reduce the slow down to 5 times. Again, is this a reasonable price to pay? I'm not sure.
I hope this explains some of the dilemma.
Shachar
I'm with you. I talked about it elsewhere, but this is, indeed, a not secure enough aggregate of the last few bytes of the file.
There are several plans for fixing this, but the problem is that fixing this while still being able to generate a reset on a one byte boundary incurs a HUGE performance penalty. I'm still trying to figure out how to handle that one.
See discussion elsewhere in this thread for why I think this is not a problem for real-life scenarios.
Shachar
I'll tell you what - you take it to the mailing list, and we can try to figure the answer out.
Like I said before - this scheme is definitely not as secure as CBC. It's just the "how much less" that I am not worried about, assuming you encrypt real files and not files you generated to be worst case.
Shachar
picrypt, by Eran Trommer. I doubt it was ever published. Google returns lots of results for picrypt, none of them seem relevant.
Basic idea - prepare slots. Divide the file into sections using a decision function. Place the encrypted section in a slot based on its content (hash function). Keep a list of which sections go where in the actual file. If you are trying to encrypt a section that already exists, merely point to it twice. When you have processed the entire file, dump the memory in the order of the sections, followed by the list of sections.
Advantages - no matter what the file looks like, you will never get a repeat. That is the part that was attacked by my other friend - details further on.
Disadvantages - not one pass. Not even close. More computationally heavy, to the point of not being O(n) (arguable)
- Does not solve any of the other attacks on rsyncrypto.
As you can see, I thought the disadvantages outweigh the advantages.
The counter claim to the advantages:
The sections list have to be placed in the file somehow. As files can get quite large, it is important that the sections list also be, somehow, rsyncable. This means that instead of repeats in the actual data, you now get repeats in the sections list, and the precise same information can be gleaned from there.
Like I said before - as I have failed to see a file one would actually like to encrypt where the repeat effect is witnessed, I call that attack "theoretical". When someone on the mailing list asked about running rsyncrypto without compression, I made it clear that what he'll get is a significantly reduced strength to the encryption.
So long as all I hear is attacks I've been aware of when the algorithm was designed, I'm good :-)
Shachar
I did "dd if=/dev/zero of=/tmp/test" for a 200MB file. Encrypting it with rsyncrypto resulted in zero repeats that I could find. In 200MB of zeros, not one ciphertext repeat was generated. This was due to non-alignment between the decision function triggers for the compression and the encryption, which meant that the same IV block for the encryption part started on different places in the compression block, resulting in no repeats over the entire 6.3MB of encrypted file.
The source is out there. Feel free to run your own test.
Shachar
Re the analysis on slashdot - I posted an answer to the commenter there.
Regarding the other article you pointed to - it has no diff based attack mentioned (that I could find). All the criticism I found there seems mostly done by people who either did not understand what rsyncrypto is meant to do, how it works, or (typically) both. Nothing useful there.
To make it clear, the criticizing comments on linux.com were clueless, while the criticizing comment here was clueful and basically correct, though I disagree with its severity.
In any case, if you want 100% secure, use the industry standard. Rsyncrypto is about performing a compromise. I believe you compromise extremely little security (if measurable), and gain a huge benefit in performance, but I will not claim this is not a compromise.
For the record, I had a claim (even with sample implementation in python) by a friend who is a cryptologist that he has an algorithm that is not vulnerable to the "repeating cipher text" attack. Two problems. One is that the core claim was disputed by another friend who is also a cryptologist. The more serious one is that this algorithm is not O(n), and is definitely not one pass. Rsyncrypto is both, and performance is an important factor. There are people using rsyncrypto to encrypt files larger than 4GB, and you would want such encryptions to end in a reasonable time.
Shachar
Wellllll.....
It would be true, except rsyncrypto compresses before encryption. Compression has the great side effect of reducing the repeats in the plain text, which means that you are much less likely to see the effects you describe. The Tux image at wikipedia, for example, will have to be several GB in size, possibly even TB, before you will notice any such effect (and by "notice", I do mean "a program can detect them", not "see with the naked eye").
Using the default rsyncrypto parameters, the repeats will be about 12KB long, which means that your compressed plain text need to have 12KB repeating at least three times for this effect to even show up. Depending on how compressible your data is, this means anything from 36KB to several megabytes (if not more).
The size mentioned is tweakable through the --roll-win, --roll-min and --roll-sensitivity command line options, so you can have a more paranoid setting, if you want. It goes without saying that the more paranoid your setting, the less traffic rsyncrypto will save you when used through rsync.
Shachar
Note - I'm the one who designed and wrote rsyncrypto.
Well, no. Two files will likely be encrypted using different session (read - AES) keys, and therefor will not be even remotely similar. One file having two significantly similar areas will show up, however. This case was deemed somewhat remote in my analysis. You are free to perform your own, of course. If you do, please feel free to email me.
The only place where actual data leakage may happen are due to the fact that a persistent attacker can compare cipher texts, and know where the decision function triggered. This is a good point to ask "how much information is gleaned about the file".
I think current rsyncrypto is ok on that front, and future plans include improvements. These improvements, alas, will cost in performance.
Shachar
I've looked at it a while back (I'm the one who wrote rsyncrypto). When compared with rsyncrypto, the main thing I didn't like (aside from the fact there appears to be no implementation... ) is the amount of state stored. Esync actually needs access to the old plain text file in order to work (or a substantially similar state). Rsyncrypto, on the other hand, needs just a few pieces of state per file, that once created never change. These include the symmetric session key and such stuff, and are about 68 bytes in length.
I really don't remember the details any more, but I think that there were also performance implications to the above.
If want, there is also a program called "murk" http://murk.sourceforge.net/, which implements the same principle as rsyncrypto. As far as I can tell, it is much less mature, and no longer maintained.
Shachar
Rsyncrypto
http://rsyncrypto.lingnu.com/
Encrypts while making the above sentence untrue - a small change in the file results in a (relatively) small change in the cypher text.
It's stable, been around a while, and is written by me :-)
Shachar
P.s.
It is, in fact, written by me for the purpose of a commercial backup service. The software itself, however, is free.
IANAL etc, but as far as I can see it, yes you can refuse.
Find prior art. Like other posters said, that is likely.
In order to file the patent, you need to sign a statement, under penalty of perjury, that states that you are not aware of prior art. Claim that you cannot, in good conscious, sign that statement.
If you get fired for this, you have a cause of action - you were requested to do something which is illegal (perjure yourself), and when you refused, you got fired.
Shachar
P.s.
If you really try to find prior art, not necessarily from the patent pool, and can't, then maybe this invention deserves to be patented?
As far as I can tell, Debian is not vulnerable in its default install mode.
a - Debian will never automatically downgrade a package.
b - Security problems (as opposed to mere changes) get published in the Debian security repository.
c - The Debian installer automatically adds the debian security mirror to the end of your sources file.
So, you can create a mirror, easily inject it into the list of official Debian mirrors, and freeze the packages offered on it. You can do all that easily. It won't help you. If you take the CERT example, of the vulnerable openssl package, the fix was pushed through the security repository, and that is added by default to all new Debian installations. The attack would fail.
Furthermore, even if your mirror offered a security mirror as well, I, personally, always keep the Debian source as well, lower in the list. This way, if the local security mirror is up to date, I take stuff from there. If it's not, I take it from the Debian server. This means that even if you deviate from the default behavior, you can still be not vulnerable.
Shachar
I doubt the robots would have had anything left to beat after the grizzly was done. Or do you claim the robot would be faster?
I think the real question is whether a robot can beat a grizzly at beating a human.
Shachar
Wouldn't you say dieing is a survival trait? That we, as a race, need individuals to die, or we risk extinction because of in-adaptability?
Shachar
It is amazing how you managed to misunderstand every single one of the points I tried to raise.
Well done!
Just a pointer:
Hope this helps.
Shachar