Information Warfare Mechanics

DSMatticus · Post by **DSMatticus** » Sun Sep 21, 2014 4:07 am

GnomeWorks, I was originally going to respond to you, but in the spirit of this discussion I decided that instead I'd just tell you the length of my message's plaintext: 455 characters. Also I lied it's not 455 characters. Good luck.

RadiantPhoenix · Post by **RadiantPhoenix** » Sun Sep 21, 2014 5:16 am

DSMatticus wrote:GnomeWorks, I was originally going to respond to you, but in the spirit of this discussion I decided that instead I'd just tell you the length of my message's plaintext: 455 characters. Also I lied it's not 455 characters. Good luck.

It's actually 233 characters!

GnomeWorks · Post by **GnomeWorks** » Sun Sep 21, 2014 5:47 am

momothefiddler wrote:I dunno. As messages get longer, the amount of info you can get from the length of the message is vanishingly small compared to the info from the time of the message ...

Sure. Diminishing returns is totally a thing, and in decryption, the curve is probably bad enough to the point where anything past a couple dozen characters is probably not worth the time and effort to attempt to decrypt, especially since total decryption isn't going to happen in probably 99% of cases.

The point I was trying to get at is that while OTP is unbreakable now, it certainly is not outside the realm of possibility that it could be subject to some degree of decryption (less than total) given sufficiently advanced tech.

Username17 · Post by **Username17** » Sun Sep 21, 2014 5:56 am

No. It is absolutely outside the realm of possibility for anything to ever break a otp message. It is literally impossible to break. Not 'it's very hard' or 'we don't think you'll ever have enough processing power to do it,' it's literally fucking mathematically impossible to break the code. There is non theoretical way to get any information at all from the contents of the message.

You can compromise either end of the transmission and read the unencrypted plaintext or steal the key and decrypt it the same way the intended receiver was going to. You can infer information based on where and when someone decided to send a message that securely. And... that is fucking it. The encryption is not a solvable equation because it isn't an equation.

-Username17

Lokathor · Post by **Lokathor** » Sun Sep 21, 2014 6:10 am

It is absolutely outside the realm of possibility.

The possibility space of an n-bit message is 2^n. I've got a small file on my desktop, it's 2600 bits big. 2^2600 is about 10^782. Given that there's only about 10^80 atoms in the universe, that's a fucking insanely big number. On a small file that might contain any sort of data.

So sure, let's apply some heuristics, that'll clean things up. It's probably text, probably ASCII. Okay so that's just 10^684. Yeah, that's not hard to sift through at all.

Wait shit, what if I'm using extended ASCII? Well that'd be 10^782 again. Damn. What if I'm using extended ASCII and the assumption isn't for a default codepage? Well that makes it even harder to decrypt because we don't know if the bit sequence we're checking is being decoded properly. Remember, converting bits into text is itself a decryption process itself, and there's never anything stopping you from layering encryption.

And even once you sift through all that, all you're getting is the list of possible messages. And then you have to decide if that was the message or not, because there's no way to check your answer.

It's like if you see me hand someone a 1m*1m*1m box, and then you try to guess what I gave them. You know it fits in the box, but that's all you know, so you'll never have any way to check your answer.

GreatGreyShrike · Post by **GreatGreyShrike** » Sun Sep 21, 2014 2:13 pm

FrankTrollman wrote:No. It is absolutely outside the realm of possibility for anything to ever break a otp message. It is literally impossible to break. Not 'it's very hard' or 'we don't think you'll ever have enough processing power to do it,' it's literally fucking mathematically impossible to break the code. There is non theoretical way to get any information at all from the contents of the message.

You can compromise either end of the transmission and read the unencrypted plaintext or steal the key and decrypt it the same way the intended receiver was going to. You can infer information based on where and when someone decided to send a message that securely. And... that is fucking it. The encryption is not a solvable equation because it isn't an equation.

-Username17

Pretty much this. Side channel attacks and key interception/hacking one end is the only real way to attack OTP encryption. That said, you could write up side channel attacks for all encryption that make the OTP scheme weaker than 'you never get to break this ever', and indeed it might make a lot of sense to do so, depending on the rest of your hacking rules.

fectin · Post by **fectin** » Sun Sep 21, 2014 3:00 pm

That's not entirely true. Most "one time pads" aren't random enough. In fact, most of the mystique of one time pads is just gloss on them getting analyzed as truest randomness, and everything else living with pseudorandomness.
Further OTP is fairly undesireable in other ways, in that you can't compress, or send to two recipients, or switch formats, or confirm receipt, or inherently securely exchange cyphers, etc., and it takes a really, really long time to set up (because e.g. recording ambient noise as your OTP is insufficiently random).

schpeelah · Post by **schpeelah** » Sun Sep 21, 2014 8:08 pm

fectin wrote:That's not entirely true. Most "one time pads" aren't random enough. In fact, most of the mystique of one time pads is just gloss on them getting analyzed as truest randomness, and everything else living with pseudorandomness.

What, your text message containing drone instructions is less indecipherable when it's encrypted with a randomly selected episode of the Simpsons?

Foxwarrior · Post by **Foxwarrior** » Sun Sep 21, 2014 8:13 pm

Yes, if someone knew or figured out that you were encrypting with a TV episode, they could just try decrypting the message with each episode until they found the right one.

But actual quantum randomness is now affordable enough that the Roll20 guys have a generator, it'll surely be even cheaper in the future.

RadiantPhoenix · Post by **RadiantPhoenix** » Sun Sep 21, 2014 9:27 pm

Foxwarrior wrote:Yes, if someone knew or figured out that you were encrypting with a TV episode, they could just try decrypting the message with each episode until they found the right one.

If it weren't XORed with an episode of the Simpsons, they wouldn't need to do that.

fectin · Post by **fectin** » Sun Sep 21, 2014 11:03 pm

Figuring out tv messages is one thing, but any sort of information in your random is bad.
Traditionally, you generated pads with 26 scrabble tiles and a bag (shake thoroughly, draw, replace, repeat), because no faster method was good enough.

Blade · Post by **Blade** » Mon Sep 22, 2014 8:45 am

If you go for an abstracted system, OTP can be broken, especially if used for communication:
- Recovering the key from the sender/receiver, or replacing it with your own key
- Recovering the plaintext before/after encryption from the sender/receiver
- Reverse-engineering the RNG and generating the key yourself
- Exploiting failures in the implementation of the OTP system and getting it to reuse the same key (or part of the same key)

Generally speaking, the weaknesses of encryption isn't in the math, it's in the implementation (and in the user, but we'll ignore that here). You can wank all you want about OTP being unbreakable, but RSA with long key is as far as we know just as unbreakable in a reasonable time. Yet, RSA encrypted data is stolen and decrypted regularly.

And in any case, OTP communication is difficult to use with unreliable connections (which can be problematic when someone is jamming the communications) and editing (since a wrong key can completely change the message).

So if your system is very abstract, you don't need a special rule for OTP. OTP is just a very high rating encryption for static data. If the rating is high enough that the hacker can't decrypt it, then it means that it has been used correctly. If it's not, then someone left the key somewhere and the hacker was able to get his hands on it.

Username17 · Post by **Username17** » Mon Sep 22, 2014 10:18 am

While in abstract there is a level of abstraction where the difference between a otp and any other symmetric key is meaningless, few cyberpunk games are going to want to go there. If anyone ever cracks a otp in your game having access to nothing but an encrypted message, people are going to call bullshit on your game and they are going to be right. That means that if you ever intend to have data on a memory chip/cube/stick/sphere/whatever be unavailable “for a period of time" because it is encrypted, players will rightfully call bullshit on your system if they can't pull otp shenanigans.

If you seriously are willing to say that messages are unreadable without some kind of access to the sending device or an intended receiver, then sure, otps are meaningless and you can skip it. But the stand alone 'encrypted file' is a very big genre trope to throw under the bus just so you don't have to include a paragraph of rules about one time pads, and it is a sacrifice I personally am unwilling to make.

-Username17

Blade · Post by **Blade** » Mon Sep 22, 2014 10:35 am

You don't need this to be OTP. This can be any kind of correctly implemented secure encryption.

The problem is that OTP, just like any other encryption, needs to be done properly, there are multiple possible points of failure, and some of them aren't trivial. That's why encryption rules should factor the algorithm as well as the ability of the users to use it properly.

A secure encryption algorithm used correctly shouldn't be breakable (in a reasonable timeframe), no matter if it's a OTP or something else. It's easier to do it with static data stored inside a chip/cube/stick/sphere/etc.

So you could just have rules where a decent hacker using a tool with a high enough rating for static data on storage device can get an encryption rating high enough that nobody will be able to decrypt it without the key.

Username17 · Post by **Username17** » Mon Sep 22, 2014 10:50 am

You could do that, but it would be immensely unsatisfying and fail to generate most cooperative stories people want to tell in the genre. You could just declare guns didn't work and everyone fought with swords now, but I wouldn't want to play your game and I would be uninterested in hearing more about your setting.

-Username17

Strung Nether · Post by **Strung Nether** » Mon Sep 22, 2014 8:26 pm

I have an idea for how to handle OTPs and encryption like this. Note: the mechanical engineer has no idea how encryption works.

Encrypted data is fundamentally impossible to access unless under the following circumstances:
You successfully hack the person before they have sent or received the data.
you hack someone who ether sent or received the data after you obtained a copy of the data.

Username17 · Post by **Username17** » Mon Sep 22, 2014 9:03 pm

Strung Nether wrote:I have an idea for how to handle OTPs and encryption like this. Note: the mechanical engineer has no idea how encryption works.

Encrypted data is fundamentally impossible to access unless under the following circumstances:
You successfully hack the person before they have sent or received the data.
you hack someone who ether sent or received the data after you obtained a copy of the data.

Basically what you have there is 'no decryption, keys only, final destination.' And that's a reasonable thing to declare for 'realistic' hacking. For much of the age of computers, encryption has at least seemed to have the upper hand, leaving all 'hacking' to various side channel chicanery - guessing passwords, tricking people into downloading your malware, photographing their messages as they are being read or written, and so on. That's how most real-world hacking works.

But you know what fucking sucks for cyberpunk cooperative storytelling? That. That shit right there is fucking bullshit. It's bad genre emulation and it's incredibly bad for cooperative storytelling. Real world hacking is based on large numbers of trials looking for someone somewhere to have screwed up in a particular way. It's not goal oriented and you don't pit your wits and skills against a rival - you don't target a computer, you just browse the network and hope someone left some valuable data in a shared folder. Probably someone did, but it's not mission relevant or skill dependent.

And the genre emulation thing is extremely important. If the villain gets their hands on an encrypted file, it's 'only a matter of time' before they break the encryption and get the missile codes or agent identities or whatever. That is how it fucking works in the genre. If I hear someone say "That disk has highly valuable encrypted top secret data on it, what good is that?" then the next sound you hear will be a scooching sound as I push my chair away from the table so that I can leave the game. It's a total deal breaker.

-Username17

Blade · Post by **Blade** » Tue Sep 23, 2014 9:33 am

Frank Trollman wrote:And the genre emulation thing is extremely important. If the villain gets their hands on an encrypted file, it's 'only a matter of time' before they break the encryption and get the missile codes or agent identities or whatever.

Which, if you consider that OTP are immune to all attacks and used for that kind of data, is not going to happen. (Unless the villain got his hands on both the encrypted file and the key, but in that case it's not a matter of time but a matter of bothering to look at the file).

name_here · Post by **name_here** » Tue Sep 23, 2014 2:10 pm

There are compelling reasons to not always use OTPs. For one thing, an OTP has to be as large as the data you're protecting with it. Also, a One-Time Pad is called that because you decrypt one piece of data with it and then set it on fire (In the old days they were on flash paper and that was literal). You do this because if you reuse the thing the possible set of keys is now only the keys that give sensible decryptions for both messages.

It's also no more secure than the method of passing keys. That's pretty good if you hand it to the intended recipient on a USB stick inside your headquarters and not so good if they're on the other side of the planet and meeting with them would be suspicious.

Other encryption schemes aren't so inviolate but are much easier to work with. Hell, with asymmetric encryption you don't even need a secure channel to send the keys over.

nockermensch · Post by **nockermensch** » Tue Sep 23, 2014 3:22 pm

GnomeWorks wrote:
FrankTrollman wrote:You seem to be a bit unclear on how good OTPs are.
What part of my analogy of the actual message being a needle in a haystack in a field of haystacks indicates that I do not understand how good they are?

There is, beneath the encryption, an actual message. I understand that - at the moment, with our level of tech - breaking an OTP is effectively impossible. But with sufficient computing power and sufficiently "intelligent" code-breaking algorithms, as well as taking context into account, you could probably arrive at some possibly-reasonable fraction of the total length of the string in number of possible decryptions of the string. Narrowing it down much further than that might approach impossible, but having a set of possibilities is a whole different beast from having no clue whatsoever.

Your set of possibilities is "all possible texts that could fit in the encrypted text length", which means fuck all.

DSMatticus · Post by **DSMatticus** » Tue Sep 23, 2014 4:00 pm

name_here wrote:Hell, with asymmetric encryption you don't even need a secure channel to send the keys over.

This is not technically true. The channel need not be private, but it does need to be able to guarantee that the key received is the same as the key sent. It's not a problem if people eavesdrop on the key exchange, but it is if they replace the keys in the key exchange with their own.

Strung Nether · Post by **Strung Nether** » Tue Sep 23, 2014 4:26 pm

FrankTrollman wrote:Stuff

I see the points you are making, but I think that in combinations with the brain hacking you suggested it could work. Maybe the OTP encryption is specific to your brain, and successfully hacking it gives them the key? Does it turn "only a matter of time" into "they are coming after us", or is it not enough? How should comunication actually be handled in the game? Should person to person comms be assumed to use OTPs and therefore be unbreakable? can you transmit a OTP key throug a previously set up OTP? can that be used to make a "pyramid" of security basically making all peer to peer communication un-breakable?

Or should we just handwave OTPs as not existing and say everything can be cracked?

momothefiddler · Post by **momothefiddler** » Tue Sep 23, 2014 4:44 pm

Strung Nether wrote:can you transmit a OTP key throug a previously set up OTP? can that be used to make a "pyramid" of security basically making all peer to peer communication un-breakable?

No, because an OTP is reduced in size by one bit for every bit of information transferred. You could communicate 25 bytes of OTP using an older OTP, but with context (/headers) you'd end up losing more than 25 bytes of your old one in the process.

John Magnum · Post by **John Magnum** » Tue Sep 23, 2014 4:47 pm

Strung Nether wrote:can you transmit a OTP key throug a previously set up OTP?

Yes, but you don't get anything useful for doing so. An OTP key has to be at least as long as the message it's encrypting. If you've managed to securely transmit a 512-bit OTP, you can use that to unbreakably encrypt 512 bits of information. Say you use it to send another 512-bit key. Congratulations, you sent zero actual message but you still have 512 bits worth of encryption. You didn't gain anything, you didn't lose anything.

Ice9 · Post by **Ice9** » Tue Sep 23, 2014 4:48 pm

Strung Nether wrote:Should person to person comms be assumed to use OTPs and therefore be unbreakable? can you transmit a OTP key throug a previously set up OTP? can that be used to make a "pyramid" of security basically making all peer to peer communication un-breakable?

You can transmit a OTP using a OTP, but it would be pointless - you end up with still a single pad, since the one you used to transmit has been used now.

The key thing here is that for a OTP to work, you need to have already been able to securely transmit a message of the same length you're now sending. It doesn't create a secure channel where one didn't already exist. The thing it does is allow you to have the secure channel exist at one point in time, and send the actual message at a later point.

So no, most things won't be using a OTP, any more than most wallets are stored in a bank vault.

Or should we just handwave OTPs as not existing and say everything can be cracked?

"Should we just handwave walls as not existing and say everything can be lockpicked?"

That's what a OTP is - a wall, in comparison to the locked door of other encryption methods. The existance of walls doesn't negate the lockpicking skill, because most buildings need doors also. If a single eccentric wizard has a door-less tower he teleports in and out of, then you use other means for that specific tower. It's not something that's going to extend to everything.