Latest reports are that the nobel prize being awarded needs five more confirmations from random networks across the world, so I guess we'll need to wait on those.
If the FCC had this power, you could ask it about all manner of other stuff- "hey FCC, these adblockers are interfering with our, uh, 'transmission'", etc.
Maybe.
The reason this is ok is because there's plenty of workarounds, and they are becoming more common. If we really care about this, we could get laws passed, but expecting this to fall under the FCC in the first place seems hopeful and blind to the possible downsides.
A car analogy would be, if you are discussing how poor Bob's car got stolen, then you are arrested for stealing Bob's car, even though you've never seen nor touched it, let alone stole it.
For most, the "year of the Linux desktop" is when they decide that their main or auxillary box needs to be safe from all the shenanigans Windows does- but that doesn't even mean pitching Windows. I mean, if your hobbies and job don't require Windows- for instance, if you don't play Star Wars: The Old Republic, or you don't need explicitly MS Office to keep up at work, or if you don't need to develop for Windows- you can forgo even that final Windows box. But I don't think that's most power users, and its definitely not most gamers.
They are an intelligence agency. You'd EXPECT that they would hold onto some method to do their job, which absolutely involves electronic infiltration. This is neither controversial nor unexpected.
Don't mistake the fact that they reach out to industry to improve everyone's (worldwide) security most of the time, for that being their primary mission or charge. That's a nice bonus.
If you want to get worked up, get angry about the same shit Snowden did- the possible indiscriminate spying against US citizens, and the idea that they only way that the government can do its job is by casting a worldwide net that monitors everyone everewhere all the time. Not that they can hack systems, which is a huge part of why they fucking exist.
I use tinyurl, because anyone who is familiar with it will do preview.tinyurl and then be able to see the link. If the place seems paranoid, I'll use the preview directly, letting you see the link and you click on it if you want.
The vast majority of url shorteners, beyond the few name brand ones, exist to ruin you somehow. But the good ones are still good.
Will this thing seriously hit the desk of any president except this one? Also note that your best bet to actually stop TPP is to get your representative and senators on board with voting against it. The "fast track" means that Congress can't try to amend or change it in any way, giving them go / no-go vote on it whenever it comes to vote (now that the draft is public, I would assume this will occur as fast as they can to minimize the time for the mainstream media to report it as anything but a "trade deal").
The point is that the magic still has problems *even when it works as described*, and that a magic spell that does that is functionally equivalent to "what was going on when this message was encrypted"- it is the power to place a camera in the past and transmit that data to you now. And my overall conclusion is, this takes it out of the realm of cryptography completely- the magic decryption spell is really a time-scrying spell, and therefore not a crypto attack at all- it's a surveillance / security type attack. It's like claiming that Veracrypt is broken because you can keylog the guy entering the password.
If your implementation insists on leaking extra data, then sure, it isn't a one time pad anymore. In this example, to ensure that the message is intact and correct, why not send a SHA256 of... THE CIPHERTEXT!
One time pads requiring at least as many random bits as data bits is, of course, the point. Nothing in my post says otherwise- in fact, it relies on it.
If a one time pad is reused, then it is not a one time pad. It's even in the fucking name. Now it's a long XOR cipher, and is substantially compromised.
One time pads are completely secure. Things that look like they might be one time pads but instead leak plaintext information are not one time pads.
Top notch graphics means a PC. The peasantboxes have strengths, including a huge base of games, but the cases where the graphics compare are only because they are designed first for the console, and then ported to PC.
That being said- if this thing didn't require the use of remote for the games, there would be a gaming culture on it for certain.
> Unless they're dropping systemd, not interested.
Ok, I see your systemd complaint is a full twelve minutes after a loosely related article dropped. You need to up the rate of the systemdQQ cron job or something, get that downtime fixed.
I don't even know what it stands for. I always read it as Do Nice Files. Like, make the files nice so I can use the thing? I'm sure it stands for something else.
Fedora is free software, and Red Hat uses it to see what will get pulled into their Red Hat / Cent OS distros. Vendor lock in? What on earth vendor lock in is implied here?
Right, but when you talk to the cryptowizard and he casts his spell, you have two problems.
1- His spell is ultimately reversing entropy to get at the original data somehow. Maybe it sees back in time and space or whatever. If your wizard can do that, he doesn't need the plaintext really, because he's pulling data equal to the length of the plaintext from the ether. It's possible that the spell needs the plaintext for some magical reason, but it's not in any way based on the contents of the plaintext. Importantly, this wizard can pull data from the past and bring it unaltered to the future- you obviously can't hide any information from him in any way whatsoever. The one time pad is as safe as any other method when your opponent has demigod level powers over time.
2- The cryptowizard's spell produces a plaintext and a key out of the ciphertext. But I could do that too- I just choose what I want the plaintext to be, XOR it with the ciphertext, and present both the plaintext (that I made up) and the key (that is generated from that). Unless cryptomancy is so well trusted that it is believed by all that his spell went back through time versus just stamping some incriminating text onto a page, you have the same problem- how do you trust that out of all nearly infinite source plaintexts, that THIS is the one that is trusted? Now you gotta vet the wizard, and the spell, with some kind of enchantment review process. Even if the wizard can grab the data from the past with his spell, how do you trust that? You can't verify it through mundane means.
In the one time pad case, we know for a fact that there's no way to be sure you've found the cleartext.
For instance, assume that every message sent from Alice to Bob begins with:
Hello Bob, You Scoundrel!!
And you have a message that is XORed with a one time pad, and contains data equal to the length of that salutation, plus 10 bytes.
What's in the 10 bytes? No one can ever know. If you were to generate all possible plaintexts of that length (a huge number), and you were to throw away all the ones that don't begin with "Hello Bob, You Scoundrel!!", you will be left with a message set equal to all the possible permutations of 10 bytes. You'll also know what the one time pad said over the bytes that were XORed with "Hello Bob, You Scoundrel!!", but because those bytes are utterly and completely unrelated to any other byte in the ciphertext, this is useless information. If it was related to it in some way, it wouldn't be a one time pad- it would be some other thing, where this known plaintext attack could help.
One time pads will never provide a way to verify that you have found the cleartext message.
1- You must have a good random number generator. Maybe pseudorandom is fine for your needs*, but you might want hardware randomization if you want a real random number. 2- You must physically make the exchange- easy enough, since it's just you and your mom. 3- You must now scramble each message, then UUENCODE the binary. Since you are proficient, this is easy enough- you save your message, run a program that looks up the last index into the file, uses the data there, and then outputs it, and saves the new index into the file. You attach the message. Optionally, you include the offset. 4- Now your mom's software, which could be on her iphone, her android, her Windows PC, or her chromebook or whatever, has to be smart enough to decrypt this message. In order to do this, it needs access to the key, and it needs the offset as an input. If you always send messages in order or have that information in the header or the message plaintext, then this works just fine assuming you automate it. But how did you automate this? You must proactively modify either every email program your mom uses, to special case your message, train her in some offline utility that processes the XORed data, or insist she use a specific email program to get your email. 5- Your communications are safe as long as both copies of the one time pad are safe.
Now, does this SOUND easy? If you think it is, consider all the burdens you place on yourself and your mom. You have to write at least one utility, and likely you will need one utility on your box, and one or two remote programs or scripts. Your mom has to be using the right type of receiver, and she has to be able to get that terabyte stick of data wherever she wants to get data from you. Additionally, if she loses the stick, all your communications are subject to being scooped by an adversary that retrieves the stick, and of course she can't get any encrypted data until then. This assumes that you solve the problem of passing the index explicitly (put it in cleartext) or implicitly (every message in order determines the index).
*Finally, we come to the issue- in this case, by using "your mom" as an example, you trivialize some pieces of this- notably, any method of making this secure could be hand waved away by the reader as unneeded for discussing how the baby is doing or whatever.
In practice, if you want to communicate with your mom securely, you are best using some encrypted email site like tutanota.com, which actually has the ability to be used from many places, including her phone. I'd argue it would even be easier to exchange very small (FAT16 or whatever) formatted veracrypt drive files, with a prearranged symmetric password.
If you brute force your way through all possible pad contents, then you have brute forced your way through all possible contents of that length.
So if your source document in 300 kilobytes, that's 2400 kilobits, 2457600 bits. You are "brute forcing" your way through 2^(2457600) possibilities. That's truly absurd, because it's every possible state that a 300 kilobyte message could be in. It's every image, in jpg format, that can fit in 300kb. It's every 300kb mp3. It's every 300 kb text file. It's meaningless to say you have decrypted it, because your output state (every possible thing) *isn't based in any way on the input or the key*- it's just a giant set of possibilities- EVERY possibility. You have all the information needed to decrypt my theoretical 300kb message right now, because your technique doesn't care what the input was, or what the pad was, because it generates all possible outputs with literally no way of searching.
It's fucking retarded. Did you find child porn? Yes, all of it. Was just some random numbers? Yup, got that too. How about "all work and no play", repeated for the whole message? Absolutely. As it turns out, the result was all 0s. And also all 1s. Utterly meaningless.
The other piece that shouldn't need to be stated, is that every possible state of that 300kb file is impossible to even talk about. 2^2457600 is shockingly and truly absurd- it's bigger than everything. A universe filled with computronium wouldn't be able to solve that shit in a million universes of time or something.
Anyway, you were either joking, or trolling. Whatever. Here's the takeaway:
A one-time pad is absolutely unbreakable, period. The only challenge is generating a random one time pad (that is, none of the bits of your one time pad are predictable given any other bits of your one time pad, even if your adversary discovers your generation method), and, of course, keeping the one time pad physically secure. If you try to use this to send messages, you also need to ensure that the same one time pad is being on decryption- after all, you can't ever reuse the pad.
It doesn't matter, is literally the point. If they claim to be Anonymous and are doing something that Anonymous would do, then they are Anonymous. Would Anonymous screw with the KKK? Absolutely. So they are doing that.
I don't think we lose much by assuming they are the same group, because they are generally acting in the same fashion. In general, after the feds tracked down the original crew, we haven't seen the same vigor as before, but they still do hacktivist stuff here and there to stay relevant and scare their potential foes.
> never imagining that "arms" would be more than muzzle loaded guns that can be fired more than once a minute
The quoted assumption isn't true.
First, muskets were fired faster than once a minute. The musket lines fired thrice a minute, and a musket could be loaded and fired in 6 seconds in some cases. Second, rifles existed. Third, pistols existed. Fourth, the long rifle had been invented recently, an arms tech boost they saw happen during their lives or directly before. https://en.wikipedia.org/wiki/...
Throwing an error is likely going to be handled different from checking an overflow flag, because you have to "catch" it, right?
On most (all these days?) processors, you get a carry flag and an overflow flag to reflect the state of the thing you just did. There's a lot of cases where the correct thing is to check the overflow flag, which you can't do in most high level languages, C included. The options are to inline assembler it if it matters that much, or to go through hoops, and the latter option is almost always chosen in practice.
Slashdot Mirror
Remember, use nothing but special characters for security.
He means like rainbow tables and other aggregate attacks. You won't get every password but you will get a lot of them.
There's plenty of ways to make explosions in war, though. Those were all around way before that.
Latest reports are that the nobel prize being awarded needs five more confirmations from random networks across the world, so I guess we'll need to wait on those.
If the FCC had this power, you could ask it about all manner of other stuff- "hey FCC, these adblockers are interfering with our, uh, 'transmission'", etc.
Maybe.
The reason this is ok is because there's plenty of workarounds, and they are becoming more common. If we really care about this, we could get laws passed, but expecting this to fall under the FCC in the first place seems hopeful and blind to the possible downsides.
A car analogy would be, if you are discussing how poor Bob's car got stolen, then you are arrested for stealing Bob's car, even though you've never seen nor touched it, let alone stole it.
For most, the "year of the Linux desktop" is when they decide that their main or auxillary box needs to be safe from all the shenanigans Windows does- but that doesn't even mean pitching Windows. I mean, if your hobbies and job don't require Windows- for instance, if you don't play Star Wars: The Old Republic, or you don't need explicitly MS Office to keep up at work, or if you don't need to develop for Windows- you can forgo even that final Windows box. But I don't think that's most power users, and its definitely not most gamers.
They are an intelligence agency. You'd EXPECT that they would hold onto some method to do their job, which absolutely involves electronic infiltration. This is neither controversial nor unexpected.
Don't mistake the fact that they reach out to industry to improve everyone's (worldwide) security most of the time, for that being their primary mission or charge. That's a nice bonus.
If you want to get worked up, get angry about the same shit Snowden did- the possible indiscriminate spying against US citizens, and the idea that they only way that the government can do its job is by casting a worldwide net that monitors everyone everewhere all the time. Not that they can hack systems, which is a huge part of why they fucking exist.
I use tinyurl, because anyone who is familiar with it will do preview.tinyurl and then be able to see the link. If the place seems paranoid, I'll use the preview directly, letting you see the link and you click on it if you want.
The vast majority of url shorteners, beyond the few name brand ones, exist to ruin you somehow. But the good ones are still good.
Will this thing seriously hit the desk of any president except this one? Also note that your best bet to actually stop TPP is to get your representative and senators on board with voting against it. The "fast track" means that Congress can't try to amend or change it in any way, giving them go / no-go vote on it whenever it comes to vote (now that the draft is public, I would assume this will occur as fast as they can to minimize the time for the mainstream media to report it as anything but a "trade deal").
The point is that the magic still has problems *even when it works as described*, and that a magic spell that does that is functionally equivalent to "what was going on when this message was encrypted"- it is the power to place a camera in the past and transmit that data to you now. And my overall conclusion is, this takes it out of the realm of cryptography completely- the magic decryption spell is really a time-scrying spell, and therefore not a crypto attack at all- it's a surveillance / security type attack. It's like claiming that Veracrypt is broken because you can keylog the guy entering the password.
If your implementation insists on leaking extra data, then sure, it isn't a one time pad anymore. In this example, to ensure that the message is intact and correct, why not send a SHA256 of... THE CIPHERTEXT!
One time pads requiring at least as many random bits as data bits is, of course, the point. Nothing in my post says otherwise- in fact, it relies on it.
If a one time pad is reused, then it is not a one time pad. It's even in the fucking name. Now it's a long XOR cipher, and is substantially compromised.
One time pads are completely secure. Things that look like they might be one time pads but instead leak plaintext information are not one time pads.
Top notch graphics means a PC. The peasantboxes have strengths, including a huge base of games, but the cases where the graphics compare are only because they are designed first for the console, and then ported to PC.
That being said- if this thing didn't require the use of remote for the games, there would be a gaming culture on it for certain.
> Unless they're dropping systemd, not interested.
Ok, I see your systemd complaint is a full twelve minutes after a loosely related article dropped. You need to up the rate of the systemdQQ cron job or something, get that downtime fixed.
I don't even know what it stands for. I always read it as Do Nice Files. Like, make the files nice so I can use the thing? I'm sure it stands for something else.
Fedora is free software, and Red Hat uses it to see what will get pulled into their Red Hat / Cent OS distros. Vendor lock in? What on earth vendor lock in is implied here?
Also, how dare you say a hot dog is a non essential character?
http://www.fileformat.info/inf...
I'm on 22, and I use xfce. Am I safe to upgrade?
They didn't just buy Candy Crush though, they bought a whole company.
Right, but when you talk to the cryptowizard and he casts his spell, you have two problems.
1- His spell is ultimately reversing entropy to get at the original data somehow. Maybe it sees back in time and space or whatever. If your wizard can do that, he doesn't need the plaintext really, because he's pulling data equal to the length of the plaintext from the ether. It's possible that the spell needs the plaintext for some magical reason, but it's not in any way based on the contents of the plaintext. Importantly, this wizard can pull data from the past and bring it unaltered to the future- you obviously can't hide any information from him in any way whatsoever. The one time pad is as safe as any other method when your opponent has demigod level powers over time.
2- The cryptowizard's spell produces a plaintext and a key out of the ciphertext. But I could do that too- I just choose what I want the plaintext to be, XOR it with the ciphertext, and present both the plaintext (that I made up) and the key (that is generated from that). Unless cryptomancy is so well trusted that it is believed by all that his spell went back through time versus just stamping some incriminating text onto a page, you have the same problem- how do you trust that out of all nearly infinite source plaintexts, that THIS is the one that is trusted? Now you gotta vet the wizard, and the spell, with some kind of enchantment review process. Even if the wizard can grab the data from the past with his spell, how do you trust that? You can't verify it through mundane means.
In the one time pad case, we know for a fact that there's no way to be sure you've found the cleartext.
For instance, assume that every message sent from Alice to Bob begins with:
Hello Bob, You Scoundrel!!
And you have a message that is XORed with a one time pad, and contains data equal to the length of that salutation, plus 10 bytes.
What's in the 10 bytes? No one can ever know. If you were to generate all possible plaintexts of that length (a huge number), and you were to throw away all the ones that don't begin with "Hello Bob, You Scoundrel!!", you will be left with a message set equal to all the possible permutations of 10 bytes. You'll also know what the one time pad said over the bytes that were XORed with "Hello Bob, You Scoundrel!!", but because those bytes are utterly and completely unrelated to any other byte in the ciphertext, this is useless information. If it was related to it in some way, it wouldn't be a one time pad- it would be some other thing, where this known plaintext attack could help.
One time pads will never provide a way to verify that you have found the cleartext message.
That's a theoretical situation.
In reality:
1- You must have a good random number generator. Maybe pseudorandom is fine for your needs*, but you might want hardware randomization if you want a real random number.
2- You must physically make the exchange- easy enough, since it's just you and your mom.
3- You must now scramble each message, then UUENCODE the binary. Since you are proficient, this is easy enough- you save your message, run a program that looks up the last index into the file, uses the data there, and then outputs it, and saves the new index into the file. You attach the message. Optionally, you include the offset.
4- Now your mom's software, which could be on her iphone, her android, her Windows PC, or her chromebook or whatever, has to be smart enough to decrypt this message. In order to do this, it needs access to the key, and it needs the offset as an input. If you always send messages in order or have that information in the header or the message plaintext, then this works just fine assuming you automate it. But how did you automate this? You must proactively modify either every email program your mom uses, to special case your message, train her in some offline utility that processes the XORed data, or insist she use a specific email program to get your email.
5- Your communications are safe as long as both copies of the one time pad are safe.
Now, does this SOUND easy? If you think it is, consider all the burdens you place on yourself and your mom. You have to write at least one utility, and likely you will need one utility on your box, and one or two remote programs or scripts. Your mom has to be using the right type of receiver, and she has to be able to get that terabyte stick of data wherever she wants to get data from you. Additionally, if she loses the stick, all your communications are subject to being scooped by an adversary that retrieves the stick, and of course she can't get any encrypted data until then. This assumes that you solve the problem of passing the index explicitly (put it in cleartext) or implicitly (every message in order determines the index).
*Finally, we come to the issue- in this case, by using "your mom" as an example, you trivialize some pieces of this- notably, any method of making this secure could be hand waved away by the reader as unneeded for discussing how the baby is doing or whatever.
In practice, if you want to communicate with your mom securely, you are best using some encrypted email site like tutanota.com, which actually has the ability to be used from many places, including her phone. I'd argue it would even be easier to exchange very small (FAT16 or whatever) formatted veracrypt drive files, with a prearranged symmetric password.
I'm glad everyone is shitting on your post.
If you brute force your way through all possible pad contents, then you have brute forced your way through all possible contents of that length.
So if your source document in 300 kilobytes, that's 2400 kilobits, 2457600 bits. You are "brute forcing" your way through 2^(2457600) possibilities. That's truly absurd, because it's every possible state that a 300 kilobyte message could be in. It's every image, in jpg format, that can fit in 300kb. It's every 300kb mp3. It's every 300 kb text file. It's meaningless to say you have decrypted it, because your output state (every possible thing) *isn't based in any way on the input or the key*- it's just a giant set of possibilities- EVERY possibility. You have all the information needed to decrypt my theoretical 300kb message right now, because your technique doesn't care what the input was, or what the pad was, because it generates all possible outputs with literally no way of searching.
It's fucking retarded. Did you find child porn? Yes, all of it. Was just some random numbers? Yup, got that too. How about "all work and no play", repeated for the whole message? Absolutely. As it turns out, the result was all 0s. And also all 1s. Utterly meaningless.
The other piece that shouldn't need to be stated, is that every possible state of that 300kb file is impossible to even talk about. 2^2457600 is shockingly and truly absurd- it's bigger than everything. A universe filled with computronium wouldn't be able to solve that shit in a million universes of time or something.
Anyway, you were either joking, or trolling. Whatever. Here's the takeaway:
A one-time pad is absolutely unbreakable, period. The only challenge is generating a random one time pad (that is, none of the bits of your one time pad are predictable given any other bits of your one time pad, even if your adversary discovers your generation method), and, of course, keeping the one time pad physically secure. If you try to use this to send messages, you also need to ensure that the same one time pad is being on decryption- after all, you can't ever reuse the pad.
> And how do we know this is really Anonymous?
It doesn't matter, is literally the point. If they claim to be Anonymous and are doing something that Anonymous would do, then they are Anonymous. Would Anonymous screw with the KKK? Absolutely. So they are doing that.
I don't think we lose much by assuming they are the same group, because they are generally acting in the same fashion. In general, after the feds tracked down the original crew, we haven't seen the same vigor as before, but they still do hacktivist stuff here and there to stay relevant and scare their potential foes.
> never imagining that "arms" would be more than muzzle loaded guns that can be fired more than once a minute
The quoted assumption isn't true.
First, muskets were fired faster than once a minute. The musket lines fired thrice a minute, and a musket could be loaded and fired in 6 seconds in some cases.
Second, rifles existed.
Third, pistols existed.
Fourth, the long rifle had been invented recently, an arms tech boost they saw happen during their lives or directly before.
https://en.wikipedia.org/wiki/...
Throwing an error is likely going to be handled different from checking an overflow flag, because you have to "catch" it, right?
On most (all these days?) processors, you get a carry flag and an overflow flag to reflect the state of the thing you just did. There's a lot of cases where the correct thing is to check the overflow flag, which you can't do in most high level languages, C included. The options are to inline assembler it if it matters that much, or to go through hoops, and the latter option is almost always chosen in practice.