When people talk about breaking encryption, most of the time they think about breaking public key encryption.

Public key encryption is based on the idea that Alice and Bob meet on the internet and want to share encrypted information. They can then share public keys, do some simple and fast mathematical operations on them, do some more operations, and now they're ready to transmit encrypted data. The clever part here is that they don't have to agree on an encryption code before they "meet" on the internet, enabling encrypted traffic between strangers.

This is because that even though Eve, who wants to spy on them, has picked up the data they transmitted between them to establish an encryption protocol, without Alice's or Bob's chosen private key (a very large prime number) she can't effectively "crack the code". The difficulty of the problem is basically one of factorizing a very large number that is the product of 2 very large primes. This just takes a really, really long time ("standard" professional current encryption takes months on supercomputers and 10,000ths of distributed computers to crack today). Build faster computers for cracking codes you say? The problem is that the complexity increases exponentially for the hacker - if computers get 1,000 times faster, the encrypters increase the complexity by 1,000 and are able to do their operations in the same time, while it now gets 1,000,000 times harder for the hacker so it now takes 1,000 times as long. The hacker just gets further and further behind as technology increases.

There are 2 potential ways to, in the future, hack encryption fast:
1) develop a mathematical method to quickly integer factorize large numbers by conventional means. It has not been proven that this isn't possible, but everyone expects that it can't be done. I wouldn't put my money on this.
2) develop efficient quantum computers. Quantum computers can do some operations that theoretically lets them integer factorize "quickly" and they don't get hit by exponentional complexity as the encrypters increase the size of the prime numbers.

Your average cyberdeck in 2070 obviously has a quantum computing module in there, letting it decrypt intercepted data quickly and easily.

All of this is however based on the premise of public key encryption, which is the only way to do it for communication strangers. People who are not strangers don't use public keys though. They use one time codes. Before you separate, you agree on a list with a number of codes, which are basically just long strings of random numbers you use to encrypt the data. There isn't a mathematical pattern to them, and the hacker doesn't have anything he can number crunch.

This is what a rigger would do with his drones. Back in the shop, he makes a one-time pad with each drone. What a hacker trying to intercept the traffic would hear is "Use code 23113132 [static for 100 milliseconds] Use code 654651651 [static for 100 milliseconds]". This can't be decrypted - there's no pattern, no numbers to crunch, nothing. The drone only accepts encrypted traffic, and the hacker can't spoof and encrypt a message - he doesn't know the encodings, so if he tries to send "Use code 7654435 [command]", the drone decrypts the command and gets static, so it disregards it.

The only ways to hack a drone is
1) hack the cyberdeck of the rigger and get hold of the one-time pads (or got hold off them in some other way, like from his drone shop)
2) if the rigger enables the drone to accept normal communication traffic.

Everything else is just plain unrealistic.
This goes for encrypted comms between professional forces too btw.

Althrough I can see what you mean. I myself would never run it like that it would take away a cool aspect of the game.

but it would add a very cool, very different other aspect. because from now on, you can't just hand encryption over to the hacker and have him wave his magic wand--you have to hack. that might mean a sneak-and-peak through a corporate office to see if anyone left their password written down at their desk. that might mean social engineering to convince an employee to give your team access. that might mean structural re-engineering on an employee's shins, for the same reason. etcetera.

Hmm... this rigger is using one time codes...

... let me see, spam his drone with random code commands to tear away at his drone's pad and now he cant use his own drone till he himself catches up... but everytime he tries, the drone moves up in the count again, so its a crapshoot if he gets the next one right and continues on from there...

Thats the problem with the one time pad method. Everytime you use or recieve an encrypted message, you have to discard the current code.

that only works if you can find his drone. and if the rigger doesn't find you and have his team shoot you in the face, because you're giving away your location with all those massive transmissions.

besides, spamming the drone with random commands won't work. you'd have to get insanely lucky to get an actual command out of random noise within any reasonable time frame--that's the whole point of good encryption. all you're doing with random noise transmissions is, basically, trying to crack the encryption with brute force. the encryption we use today would take, at a minimum, years to crack that way.

true. even so, the likelihood of getting a useable response--and i'm including random actions and malfuctions as useable responses--within a reasonable timeframe is vanishingly low.

Shadowrun is not about realism. Its about a certain kind of game experience.
I agree that the current hacking rules do not deliver this experience, as Joe Hacker can hack the most advanced encryption out there in about 18 seconds, but one time pad encryption does not deliver this game experience, too.

You basically want a rule where you take a little longer to decrypt things and where you may not succeed for sure if the encryption is too hard.

Using OTPs for transmissions requires packet-encryption, using codes that never are used twice: Not for encoding, nor in another drone.
The code-jumps you proposed are irrelevant to the encryption itself.

Enter old problem: source of random data. Real randomness isn't easy to come by, and much harder to generate.

Drones transmit huge amounts of data, especially if jumping into them. As they need exactly the same amount of data for codes as those are used up, you need huge libraries, which, depending on the mission lenght, might even stretch the 'unlimited storage' of SR4.
If you lose a drone, you lose the data completly, too.

So, basically, that setup might work some time, but it will be inpractical on the long run.


OTPs are great for secret communication of short messages, as they can be used to encrypt manually, though.

@RvD: The code jumps aren't necessary for encryption, they're there to ensure that you both agree on where you are in the encoding stream. It's a necessity when operating in environments where the parties sometimes lose contact.

You're taking the onetime pad name too literally. Most likely the codes will contain seeds for one or more semi-random functions that tells you how to encrypt the data with real random data. So a code might be 2-part, one says what semi-random function to use, the other is a table index that you look up a seed with. The semi-random function plus seed then gives you a long output that tells you what snippets to use from the real random data stream you've stored.

Something like that gives you effectively unlimited streams for encrypting. If it is not enough for you, then that scheme can be made a lot more random and given a lot more combinations. A combination of semi-random functions, tables that only Alice and Bob knows, and a large common real random data file, and you've got something that can keep on spewing out random data without repeating itself for ages without the need for unrealisticly large pads.

Certainly, I'm no cryptoanalyst, but that approach sounds like snake-oil:

Essentially it still is an OTP that is reused, but shifts the start and ending of that pad with a PRNG. This removes the proven security of an OTP, and the PRNG opens the possibility of pattern matching attacks.
As the OTPs algorithm itself is very easy, it is trival to break once you have exploited the PRNG for pattern matching.

This is especially true since the attacker has a very good guess what parts of the plaintext looks like, since the protocol for drone communication is standardized.

The whole setup is really just making the OTP extremely large without using extreme amounts of storage.

At the very least, you must agree that you could easily store a very large random stream to start with as a basis for a OTP - you could measure it in terms of the drone's recording capacity. Say 2 hours worth. Before you can even start pattern matching, you need 2 hours of full sensor feed transmitted. After 4 hours, you have 1 run-through of the stream. That is much too little to get anything useful out of, at best you figure out just a bit of the encoding stream if you're really lucky with recognizing the actual data.

If I mixed the random stream, even with PRNG-based methods, you'd completely wipe out any pattern matching attemps. Pattern matching through something encoded with a random stream that's mixed up between each pass, and with the underlying data being very close to random too (by far the bulk of the data will be video feed or neural impulses) requires an incredible amount of intercepted data, and the power needed to analyze it would be enormous (and AFAIK quantum computing tricks can't help pattern analyze).

Hey, you could even have one random stream to encode with, and another random stream to determine how it gets mixed up after each pass (and another random stream to mix up the second etc., for as long as you need the chain to be). That sounds like it gives pattern matchers an exponential problem with only linear storage increase for the encryption.

Well, there are ways of completely cut of any kind of Spoofing attempt, and Encryption can always be slightly redesigned to take longer.

Standing order: Doublecheck command
Drone always doublecheck latest sent order from Persona (Spoofing will fail as the Spoofer does not get anything sent back to it, the drone checks if the order was genuine with Persona and says Ay or Nay if the response was correct or not.

Harder Encryption
There are several ways one can encrypt a signal or the information of a device.

1. Public Encryption
Public Encryption is the standard Encryption people have on their devices and one does not need any special skills for it. Decryption works as in SR4 Core Rules (Encrypt X2).

2. Secure Encryption
This requires an Encryption test and the successes are added to the Multiplier for cracking the encryption. A rating 4 Encryption and 4 successes on an Encryption test would raise the threshold to Encrypt X6.

3. Military Encryption
Works as Secure Encryption but takes considerably longer. Decrypt+Response VS (Encrypt [Rating] / 1 Hour).

ah, the age old one-time pad, when will the debate ever stop?

Excuse me while I wade in with my own 2¥ ...

I think Smokeskin's right. The OTP he describes would be easy, especially if the "page" to be used is broadcast each time.

Could a hacker copy and store the signal, compare all of the transmissions, and find two uses of the same page and so crack part of the transmission? Sure. Sort of. If your OTP table has a million entries, and you change the page three times a second, you'll have enough entries to cover a constant stream of communication for a little over a hundred years without repeating.

But what about the size of such a table? Let's say that one entry is about 4 kilobytes, about the size of a page of text (that's probably a bit high for an OTP page, but let's just say). That would put our million-entry table at around 4 gigabytes (give or take). Elder Scrolls IV takes 4.6 Gb of space. In either case, you can get machines today with that much RAM, never mind storage. A 4-gig file is trivial in a world where three-dimensional sensory rendering can be handled over any distance in real-time. Heck, a 40-gig file is, too.

What Smokeskin is getting at is that there is a strong argument for subscribed systems (such as drones) being unspoofable without first getting a copy of the OTP file. Incidentally, after reading his (or her) argument, I agree with him. Note, please, that this does not render the Spoof program useless; there are plenty of items that take commands but would not be subscribed, such as garage door openers and hotel spa rooms and parking meters. This also does not make the drone un-crackable, but rather means the drone is part of the rigger's PAN, and so that PAN must be cracked to get at the drone, either by stealing the OTP file quietly, or hacking in hard and issuing commands from a more "legitimate" point.

And if you're wondering about how to hack a drone that is being controlled remotely by a rigger who is hiding, well, I'll let you figure that one out yourself; you'll know it when you're on the right Track.

If you're trying to drop a drone, shooting it would work better. If you're trying to dump a rigger who has jumped into a drone, hit it with a directional jammer. They're both faster.

I thought it might aid the discussion to explain a bit more about OTP use. But I'm feeling lazy, so I'll just copy and paste from Wikipedia:

Based on what I have been reading here, it seems the most logically way is just extending the period on when you can do your extended test. I know for my group, forcing a successful decryption to hours is going to effectively make it unbreakable for a specific run, as none of my players are going to wait that long if they are doing everything else on the fly.

As to the reality of unbreakable encryption or just ones that take a long time...I don't think I, nor any of my players, care to try to parallel the realworld with these kinds of mechanics...

I think I am also fine with making a subscribed drone unabled to be hacked unless the riggers comm is hacked first and then spoofed. I would still allow sniffed traffic, but that is of limited usage, IMO, when you are trying to gain control or get past a drone quickly...

Has anyone stopped to think.... Maybe its something new.... Maybe we're bringing an overcomplicated view to the table.... Maybe this view is going to overcomplicate things... Maybe this overcomplication isnt going to be fun....

Just My Opinion...

there's no such thing as a perfectly-implemented OTP. to do that, we'd first need a way to generate perfectly random numbers, and at the moment, all we have are ways to generate usefully (but imperfectly) random numbers. key word being 'useful'; for most intents and purposes, OTPs are unbreakable--as long as we understand 'unbreakable' to actually mean 'unbreakable within any useful timeframe'.

using OTP encryption on drones is, basically, using it wrong. there's nothing one-time about drone communication; by its nature, drone control is generally managed through a stream of constant communication. same with using it for team commo. to use OTPs correctly, you have to do what the name implies--use them one time. every time you use them, the chance that your code will be broken increases.

but i think there's a good way to mimic the behavior of OTPs in the rules, without unbalancing things. here's how i'd do it. i think it's pretty balanceable (i'm providing the framework the rules should be based on, not the rules).

basically, OTP encryption should be very strong, but should degrade over time, if used for something like team commo or drone control. i'd suggest something like this: give OTP encryption an effective rating equal to the square of its actual rating, for the purposes of decryption. in other words, if i'm using rating 4 OTP encryption, you have to decrypt it as if it were rating 16. however! the actual rating (4) would decrease over time. let's say something like -1 actual rating per hour. after an hour of drone control, the OTP's actual rating would be 3, effective rating 9. after two hours, 2 and 4. and so on. the reason it degrades is, there are lots of transmissions out there to collate, and the number of transmissions available for collation increases as time goes by. we just assume that searching for transmissions sent from the identified source is part of the decryption process.

et voila.

i meant "in constant use", eg for streaming traffic as opposed to single, discrete messages. yes, a rigger can (and should, since it won't last forever) change his 'OTPs' frequently. that's the downside to using them.

Not much of a downside for a rigger, as he gets direct access to the drone every once in awhile, albeit intermittently. During those times it would be pretty trivial to hook up a hard line to transmit that week/month's OTP set. It'd just be part of routine maintenence; heck by 2070 a good random number source would probably be a standard part of any good set of mechanic's tools, rather like laptops and other electronics gadgets are quickly becoming standard tools for dealing with the onboard computers of most newer cars.

(Edit): Yes, much data is going to have to change hands for a rigging interface to work. This does mean a whole lot of storage will be necessary to keep up with a true OTP encrypt, but then storage is aparently very cheap in 2070 so it's no big deal.

there are balancing factors you can fudge to make it workable. the time it takes the OTP to degrade, for one; if your rating 6 OTP degrades to 0 after 6 hours, you might not want to use it on extended operations. i'm not suggesting these rules are strictly realistic; if you're looking for strict realism, i can think of a lot better places to start no matter what edition of the game you're playing. but i think rules like these could help make encryption a bit more believable--if not, as i said, make them actually realistic.

unpredictability works, for cryptology, but not as well as true randomness. if it's truly random, there's basically no breaking it. if it's just unpredictable, it's possible to find patterns if you have enough material to work with. generating less-than-random OTPs means that, eventually, someone's going to crack the system that you use for generating OTPs. at which point, you're screwed.