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.
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.
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, the idea of creating patterns in the encrypted data looks like a bad idea from the start. I suppose I'd be left with just sending deltas and resending the whole file when they get too big.
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.
This is starting to sound like DRM, ie something that's impossible because Bob and Eve are the same person.
Lines per day is frequently proposed and sometimes implemented. But it's also easy to kill, just do that little refactoring job you've been putting off and put in a report of minus two thousand lines.
After a quick look at it, your decision function worries me. You are placing information about the plaintext into the encrypted rsync stream. This info is only processed by a simple sum function before it is given to the untrusted server.
My immediate feeling is that the decision function should be based on an ECB transform of the plaintext not the plaintext itself.
But you should be aware that, even without the above problem, you are downgrading the security a little because this restarting of the CBC chain is almost the same as using ECB mode to start with. The 'almost' being that the block size is much larger than ECB mode so you will need a much larger image than the wikipedia one to show the non-randomness.
IPv4 addresses are aliased as::ffff:216.239.59.99 in IPv6 so as long as there's an address translator in the IPv4 space an IPv6 machine can talk to any IPv4 machine as if the IPv6 machine is inside a nat. (a VERY large nat!) The IPv4 cannot connect to the IPv6 machine though because it sees the connection coming from a proxy.
The public key of the self signed certificate should already exist in the browser's certificate store. If it doesn't the link is not secure until it is possible to prove that the certificate came from the entity you want to communicate with.
If the certificate is not already known the browser should say the link is insecure and probably switch back to using http.
A self signed certificate can and should be installed into the browser but only after you've manually validated it.
Once validated it may be more secure than a global CA issued certificate because there no certificate chain that may have been compromised. However, most users wouldn't know how to validate the certificate or even that they should.
Firstly I think for infringment to be sure you have to have pushed out the whole (or most of) the file to one person. Giving a bit here and a bit there muddies the waters
In this way a leecher can only forward (to one other person) as much as they have downloaded. Even the first seeder doesn't give the whole file to one person; but in this case there's the chain of events that says the data must have come from seeder one originally.
Second there's details of the bittorrent protocol.
The file is divided into chunks, these chunks are generally one of 128kB, 256kB, 512kB long. The program will normally try to fill a chunk quickly once it starts so that it can do the checksum on it.
Each chunk is divided into blocks, these are 16 or 32k and are the data that is requested from a single peer. A client is likely to request different blocks for one chunk from different peers.
Still two seconds should be enough... Never gonna give you up
IMO even 2k had downsides so serious I was running windows 95 on a machine with 256Mb of RAM and a 700MHz processor, I kept that machine for a long time.
With 95 an explorer window would popup before you could release the keys from a Win-E. It was in itself stable, but was unable to protect itself properly from really crap applicatons (like for example "active desktop" which I avoided). Normally I didn't get crashes or bluescreens and when I did if I stopped using the program I'd recently installed they would go away.
If I was foolish enough to install an application that wouldn't uninstall properly the alternative was easy; five minutes to restore to a backup. The registry and desktop customisation would also be restored so it was a small pain; user files were seperated though.
So IME windows 95 was like a glass table, smooth and stable but a fragile and easily scratched if you happened to be even a little careless.
Maybe if you only shop at Dell, but I've just bought a machine that seems to fit your requirements. It'd probably be less than a thousand dollars.
1 x Intel Core 2 Quad Q6600 processor
1 x Gigabyte GA-P35-DS4 motherboard
2 x OCZ 4GB Kit PC2-6400 DDR2 (Gold Heatspreader)
1 x PNY GeForce 7 7200GS 128Mb PCI-E Graphics Card
1 x LITEON 20X DVDRW BLACK BARE INC SOFTWARE
2 x Seagate Barracuda 1TB ES.2 SATA 3Gb/s Hard Drive
1 x Antec nine hundred EU games case
1 x Ultra quiet Active PFC 500W PSU with blue LED fan
Have you noticed how everything seems to have blue leds these days!!
You need to chop off a little bit of the start of those terabyte disks to get you fast filesystem area, the rest can be raided archive. There are lots of drive bays and sata ports for whatever other flash or hard drives you want. You may want a better graphics card. If you app is single threaded you'd be better off with a dual core for the same cost.
On your second point, encrypted filesystems. If the filesystem is encrypted but the user knows the password they can:
Remove the hard disk from the machine (to get past BIOS restrictions)
Boot with another OS copy and use their password in that OS to unencrypt the hard disk.
Encryption is designed to protect against people who don't know the password to the disk. The only way you can arrange this for people who logon to the machine is if physical to the machine doesn't mean physical access to the keys.. ie TPM. Even then it's uncertain as when you're logged into the machine the plaintext disk key must be available to the OS.
Likewise, if the password the user enters is poor and the 256bit key is available on the hard disk (no "keyfob") you can probably get over 100bits of plaintext for a dictionary search from just the boot sector of the harddisk.
So to avoid the attack in the FA from a third party you either need a good FDE password, so the on-disk key is used only for password changing or a keyfob that cannot be left in the machine.
Against the user of the machine it's TPM and prayer.
The consensus seems to be that they were required to start logging all accesses from the US not turn over existing logs as there weren't any.
They did this but also disabled access from the US.
It's likely that an appeal would find the court order unreasonable or unconstitutional (eg it resembles a random search) or something similar as it would open a real large can of worms.
The checksum on a TCP packet is only 16bit thats 1 in 65536. You can only get about 100Mbytes in 65536 packets!
The lower layers normally have better CRCs so this is rather unlikely to cause a real problem but if something is chattering the TCP CRC is likely to fail too.
BTW: it's also a rather poor redundancy check even for 16bits.
Slashdot Mirror
Me too, old boom boom, AKA "Project orion" http://www.projectrho.com/rocket/orion3.gif, is just too much of an "OMFG they want to do WHAT!" to be forgotten.
http://www.astronautix.com/lvs/orion.htm
"Respect"? Yes that's the word.
The same sort of respect you give the guy who's face is covered in obscene tattoos!
reset on a one byte boundary
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.
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.
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, the idea of creating patterns in the encrypted data looks like a bad idea from the start. I suppose I'd be left with just sending deltas and resending the whole file when they get too big.
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.
This is starting to sound like DRM, ie something that's impossible because Bob and Eve are the same person.
Oh well, good luck.
Lines per day is frequently proposed and sometimes implemented. But it's also easy to kill, just do that little refactoring job you've been putting off and put in a report of minus two thousand lines.
They tend to get the message after that.
After a quick look at it, your decision function worries me. You are placing information about the plaintext into the encrypted rsync stream. This info is only processed by a simple sum function before it is given to the untrusted server.
My immediate feeling is that the decision function should be based on an ECB transform of the plaintext not the plaintext itself.
But you should be aware that, even without the above problem, you are downgrading the security a little because this restarting of the CBC chain is almost the same as using ECB mode to start with. The 'almost' being that the block size is much larger than ECB mode so you will need a much larger image than the wikipedia one to show the non-randomness.
Of course they would, this isn't about the millions who've already paid the RIAA (members), it's about those who can't prove that they've paid.
Haven't you been reading; there's almost no merit to these cases even before you look at the vastly inflated damages claims.
http://www.robweir.com/blog/images/rick.png
"echo -e 'global _start \n _start: \n mov eax, 2 \n int 80h \n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a
Now that's mean. (no I didn't run it)
Oh wow! Pyroclastic computing! I want!
IPv4 addresses are aliased as ::ffff:216.239.59.99 in IPv6 so as long as there's an address translator in the IPv4 space an IPv6 machine can talk to any IPv4 machine as if the IPv6 machine is inside a nat. (a VERY large nat!) The IPv4 cannot connect to the IPv6 machine though because it sees the connection coming from a proxy.
The public key of the self signed certificate should already exist in the browser's certificate store. If it doesn't the link is not secure until it is possible to prove that the certificate came from the entity you want to communicate with.
If the certificate is not already known the browser should say the link is insecure and probably switch back to using http.
A self signed certificate can and should be installed into the browser but only after you've manually validated it.
Once validated it may be more secure than a global CA issued certificate because there no certificate chain that may have been compromised. However, most users wouldn't know how to validate the certificate or even that they should.
I'll jump in at this point.
Firstly I think for infringment to be sure you have to have pushed out the whole (or most of) the file to one person. Giving a bit here and a bit there muddies the waters
In this way a leecher can only forward (to one other person) as much as they have downloaded. Even the first seeder doesn't give the whole file to one person; but in this case there's the chain of events that says the data must have come from seeder one originally.
Second there's details of the bittorrent protocol.
Still two seconds should be enough ... Never gonna give you up
If I got NaN when I asked "how much coolant is there for the reactor" I'd shut the fucker down too!
I might ask "What! How much?" first, but my finger would be hovering as I did.
The thing that forced XP for me was WiFi. At the time the 3rd party managment for WiFi was really crap.
Otherwise XP is a pudgy 2k with a teletubbies paint job.
IMO even 2k had downsides so serious I was running windows 95 on a machine with 256Mb of RAM and a 700MHz processor, I kept that machine for a long time.
With 95 an explorer window would popup before you could release the keys from a Win-E. It was in itself stable, but was unable to protect itself properly from really crap applicatons (like for example "active desktop" which I avoided). Normally I didn't get crashes or bluescreens and when I did if I stopped using the program I'd recently installed they would go away.
If I was foolish enough to install an application that wouldn't uninstall properly the alternative was easy; five minutes to restore to a backup. The registry and desktop customisation would also be restored so it was a small pain; user files were seperated though.
So IME windows 95 was like a glass table, smooth and stable but a fragile and easily scratched if you happened to be even a little careless.
Maybe if you only shop at Dell, but I've just bought a machine that seems to fit your requirements. It'd probably be less than a thousand dollars.
1 x Intel Core 2 Quad Q6600 processor
1 x Gigabyte GA-P35-DS4 motherboard
2 x OCZ 4GB Kit PC2-6400 DDR2 (Gold Heatspreader)
1 x PNY GeForce 7 7200GS 128Mb PCI-E Graphics Card
1 x LITEON 20X DVDRW BLACK BARE INC SOFTWARE
2 x Seagate Barracuda 1TB ES.2 SATA 3Gb/s Hard Drive
1 x Antec nine hundred EU games case
1 x Ultra quiet Active PFC 500W PSU with blue LED fan
Have you noticed how everything seems to have blue leds these days!!
You need to chop off a little bit of the start of those terabyte disks to get you fast filesystem area, the rest can be raided archive. There are lots of drive bays and sata ports for whatever other flash or hard drives you want. You may want a better graphics card. If you app is single threaded you'd be better off with a dual core for the same cost.
On your second point, encrypted filesystems. If the filesystem is encrypted but the user knows the password they can:
Encryption is designed to protect against people who don't know the password to the disk. The only way you can arrange this for people who logon to the machine is if physical to the machine doesn't mean physical access to the keys .. ie TPM. Even then it's uncertain as when you're logged into the machine the plaintext disk key must be available to the OS.
Likewise, if the password the user enters is poor and the 256bit key is available on the hard disk (no "keyfob") you can probably get over 100bits of plaintext for a dictionary search from just the boot sector of the harddisk.
So to avoid the attack in the FA from a third party you either need a good FDE password, so the on-disk key is used only for password changing or a keyfob that cannot be left in the machine.
Against the user of the machine it's TPM and prayer.
That's not the point
Linux doesn't try to be secure against physical access, just add init=/bin/sh to the kernel command line.
OTOH: Windows has always had this weird naivety that passwords will protect the OS from the guy sitting infront of the PC.
laughter and ridicule and also good responses!
Worthless, you bet! 4111111111111111
That reminds me of 111-1111111
...
At which point I'll give you a present, half a million spam messages through a botnet advertising your business.
Or at least I might if I were on the same continent.
The consensus seems to be that they were required to start logging all accesses from the US not turn over existing logs as there weren't any.
They did this but also disabled access from the US.
It's likely that an appeal would find the court order unreasonable or unconstitutional (eg it resembles a random search) or something similar as it would open a real large can of worms.
Transparent proxies also kill large downloads; especially when the browser is not IE. I hear "not IE" also included IE7!
You'll lose your $100
The checksum on a TCP packet is only 16bit thats 1 in 65536. You can only get about 100Mbytes in 65536 packets!
The lower layers normally have better CRCs so this is rather unlikely to cause a real problem but if something is chattering the TCP CRC is likely to fail too.
BTW: it's also a rather poor redundancy check even for 16bits.
I'll have a minor nitpick too please
Electrons in a wire move at around 3 inches per hour, it's the signals that move at near lightspeed.