Help - Search - Members - Calendar
Full Version: Encryption and hacking drones
Dumpshock Forums > Discussion > Shadowrun
Pages: 1, 2
Smokeskin
QUOTE (Rotbart van Dainig)
QUOTE (Aaron @ Aug 22 2006, 06:11 PM)
However, a non-mathematical algorithm, such as a random list generated by the the keyboard mashing common to PGP key generation, is suitably random for an unbreakable OTP table.

No. It may suffice for some time.

Even atomic decay or interstellar radiation were found having patterns.

Correct me if I'm wrong, but as I understand it those patterns only mean it is easier to pattern match if you use the same encoding stream repeatedly? If you just use the stream to encode once you're completely secure, since you can't predict atomic decay?
Rotbart van Dainig
QUOTE (Smokeskin)
Correct me if I'm wrong, but as I understand it those patterns only mean it is easier to pattern match if you use the same encoding stream repeatedly?

If you reuse your stream, there is no real security at all.

QUOTE (Smokeskin)
If you just use the stream to encode once you're completely secure, since you can't predict atomic decay?

Not really. If you know what parts of the plaintext should look like, and have a good guess how the pseudo-random data is created, it reduces the necessary amount of operations to a point where you just can brute-force it.
Red
For all the back and forth here about what can and cannot be cracked eventually, I see no math with regard to magnitude. And without magnitude, we have no sense of scale.

For all intensive purposes SR4 has given an "infinite" amount of memory. In other words they looked at the insanity of megapulses, and the growth curve of memory over the last few decades and said "hell no, we're not doing that again."

We don't know a lot about what goes on with computers and radiowaves in SR. It isn't specified whether commlinks are quantum based, nor even how their operating systems work. (OS appears to work in a very alien way to how we look at them today.)

That said, I see no reason why dozens, hundreds, or thousands of hours spent by quantum processors utilizing all encryption algorithms, techniques, and methods known by 2070 cannot produce an OTP which is highly unlikely to be cracked within the time span of a single game mission. In terms of magnitude I don't find that concept unreasonable. Naturally it doesn't replace public keys, nor should it. But it would seem feasible for OTPs to be used for select circumstances.

If it doesn't fit the feel of somebody's game, so what? Nobody has the right answer here. Hell, nobody even has enough information to give an estimate between 30 seconds and 30 billion years. But if the team hacker is willing to strike a deal where X many hours of downtime results in Y many hours of OTP safe transmissions, I'd be cool with that. Just have OTP files sitting on team commlinks, and keep track of how many hours worth of lists are stacked here or there. And remember to mark it on your sheet in case your team is being hacked.

Run the idea by your GM and fellow players. Consider the consequences. Decide, and enjoy.

Aaron
QUOTE (Rotbart van Dainig)
QUOTE (Aaron @ Aug 22 2006, 06:11 PM)
However, a non-mathematical algorithm, such as a random list generated by the the keyboard mashing common to PGP key generation, is suitably random for an unbreakable OTP table.

No. It may suffice for some time.

True. That's why I said "unbreakable OTP table" instead of "eternally unbreakable code." If you glance a few posts up, you'll note that an OTP table with enough entries to allow you to use a new entry three times a second without ever repeating for a hundred years would cost around 4 Gb. Four gigs is trivial in 2070; it could be stored in active memory. This means that one could trivially use OTP encryption, changing it up three hundred times per second and not need to generate a new pad for a year.

And before anybody starts talking about the super-duper-fast real ultimate computing power of the Inter-tubes in 2070, don't bother. What's protecting OTP-encrypted data isn't processing power, it's mathematics [edit: more accurately information theory; thanks, Rotbart]. Not wonky Logopolis maths, either, real scientific mathematical laws. So unless somebody makes a spell that causes two plus two to equal five, you can't stop the signal. Increasing the interval for the task is like increasing the interval for tracking an astral signature to Mars. Track down the rigger and hack her PAN, or shoot the damn drone.

And before anybody starts whining about this making hackers and technomancers ineffectual, I'll point out that the only logical and safe configuration for OTP use is a subscription list, which the RAW already suggests when it talks about a PAN. Has anybody ever noticed that PAN stands for Personal Area Network? Has anybody else noticed that a PAN is a single node? Anyway, anything not on a subscription list wouldn't be covered by an OTP; the communication required to keep it updated while not in lock-step would render the OTP useless, anyway. So there's still plenty of stuff on which to use that Exploit program/complex form.

(Incidentally, if the tone of this post seems snarky, it's because I'm feeling snarky about having to duplicate the effort of explaining this stuff. If I'm repeating myself because I didn't explain it very well the first time, I'm sorry. If it's because people don't read posts, I'm not.)
Aaron
QUOTE (Red @ Aug 22 2006, 12:16 PM)
For all the back and forth here about what can and cannot be cracked eventually, I see no math with regard to magnitude.  And without magnitude, we have no sense of scale.

All the math you can eat for the one-time pad is in a PDF document from Queen Mary University of London.

As far as magnitude is concerned, for all intents and purposes, the OTP doesn't have one. Shannon's Theorem (which is about one-time pads) basically boils down to "the probability of a given cyphertext is independent of the probability of a given plaintext." This means that even if the probability of a cyphertext that you have (like an intercepted drone communication) is 1 (or 100%, which is to say you have the cyphertext), then the probability of a given plaintext (a command to attack, let's say) is the same as it was before you knew the cyphertext, which would be 1/(q^n), where q is the size of the alphabet and n is the length of the message. If you want an example for reference, a modern Ethernet frame has a minimum length of 64 bytes. Given 8 bits per byte, we get a length of 512 bits, with an alphabet size of 2 (0 and 1), for a total of 1.34 x 10^154 possible combinations; the probability of guessing the correct message is zero, followed by a decimal point (or comma) and a hundred and fifty-four zeros, then a seven (if you want a percentage, knock off two of those zeros after the decimal).

And it's not a matter of working through all those possibilities to find the right answer. Every possible plaintext is equally probable, so all you get by working though all the possible plaintexts is a list of possible plaintexts. Sure, you could do some pruning by assigning arbitrary possibilities (a rigger is unlikely to be reading Stackpole to her drone), but in the end those are only arbitrary judgements. And once you have your weighted list, you still have nothing to compare it to, since the algorithm for that message has been used and never will be again.
Rotbart van Dainig
QUOTE (Aaron)
That's why I said "unbreakable OTP table" instead of "eternally unbreakable code."

Unbreakable means exactly that - never, ever.
Everything else is just normal encryption.

QUOTE (Aaron)
If you glance a few posts up, you'll note that an OTP table with enough entries to allow you to use a new entry three times a second without ever repeating for a hundred years would cost around 4 Gb.

That doesn't matter for OTPs - 4GB will allow you to encode 4GB of data:
The pad must be as large as the plaintext, and thus, you just proclaimed that the 'effectively infinite storage' of SR4 allows storing hundreds of years of FullX data.
I don't think so. wink.gif

QUOTE (Aaron)
And before anybody starts talking about the super-duper-fast real ultimate computing power of the Inter-tubes in 2070, don't bother. What's protecting OTP-encrypted data isn't processing power, it's mathematics.

Only if the pad is perfectly random... and every modern encryption is 'protected by math'.

QUOTE (Aaron)
Increasing the interval for the task is like increasing the interval for tracking an astral signature to Mars. Track down the rigger and hack her PAN, or shoot the damn drone.

You can justify the same thing with most advanced forms of encryption, when done right and played 'realistically'.

QUOTE (Aaron)
And before anybody starts whining about this making hackers and technomancers ineffectual, I'll point out that the only logical and safe configuration for OTP use is a subscription list, which the RAW already suggests when it talks about a PAN.

We heard that argument before, and it still doesn't fly. Read the RAW and check what a subscription list real is. A hint: it's about the same thing BlueTooth does - peering.
BTW, concerning 'whining' - stop trying. If you want to take out certain aspects of the game, consider the consequences and houserule it if everyone agrees.

QUOTE (Aaron)
So there's still plenty of stuff on which to use that Exploit program/complex form.

If you would have read the RAW, you would know that Exploit is a whole different cattle of fish, it's Spoof - and Decrypt. The latter which becomes really useless.
Aaron
QUOTE (Rotbart van Dainig)
Unbreakable means exactly that - never, ever.
Everything else is just normal encryption.

I posted a link to a PDF up above. Read it. While you're at it, read the Wiki page on information-theoretic security. Then come back, formulate an argument, and present it.

QUOTE (Rotbart van Dainig)
That doesn't matter for OTPs - 4GB will allow you to encode 4GB of data:
The pad must be as large as the plaintext, and thus, you just proclaimed that the 'effectively infinite storage' of SR4 allows storing hundreds of years of FullX data.
I don't think so. wink.gif

You're making a straw-man argument by omitting some of the constraints I laid out; stop that. And yes, it can, but please keep your fantasies to yourself.

QUOTE (Rotbart van Dainig)
QUOTE (Aaron)
And before anybody starts talking about the super-duper-fast real ultimate computing power of the Inter-tubes in 2070, don't bother. What's protecting OTP-encrypted data isn't processing power, it's mathematics.

Only if the pad is perfectly random... and every modern encryption is 'protected by math'.

It's a fair point; it would be more accurate to say that OTP encryption is protected by information theory. But every encryption method ever is "protected by math," being that information theory is a subset of math. I could say that pubilc-key encryption is protected by math, too, but it would be more accurate to say it was protected by probability. The difference is that public-key is vulnerable to attacks involving large computing resources (like those available in 2070), whereas OTP is not.

QUOTE (Rotbart van Dainig)
QUOTE (Aaron)
Increasing the interval for the task is like increasing the interval for tracking an astral signature to Mars. Track down the rigger and hack her PAN, or shoot the damn drone.

You can justify the same thing with most advanced forms of encryption, when done right and played 'realistically'.

No. Only information-theoretically secure schemes, of which OTP is one, can be justified in this manner. For schemes that rely on the factorization of (really fraggin') large primes, an increase in the threshold make perfect sense.

QUOTE (Rotbart van Dainig)
BTW, concerning 'whining' - stop trying. If you want to take out certain aspects of the game, consider the consequences and houserule it if everyone agrees.

You and your straw-man arguments. I'm disappointed; I respect you too much to believe that you have to resort to such tactics.
sfogarty
I am assuming that every implementation of encryption and decryption algorithms is flawed. The math may be perfect, but there are common exploits in the random number generators, the code, etc, etc, etc that make it POSSIBLE for a really complex program to defeat the encryption. Breaking encryption isn't attacking the math, it is attacking the reality.
Rotbart van Dainig
QUOTE (Aaron)
I posted a link to a PDF up above. Read it. While you're at it, read the Wiki page on information-theoretic security. Then come back, formulate an argument, and present it.

Just both are utterly irrelevant to the matter at hand:
One is explaining what an OTP is, and why it is - we are way past that point, as does the second.

Both rely on perfectly random sequences, thus are perfectly secure.
If that isn't the case... well, there goes 'unbreakable':
There's a difference between security through enough O and unbreakable.

QUOTE (Aaron)
You're making a straw-man argument by omitting some of the constraints I laid out; stop that. And yes, it can, but please keep your fantasies to yourself.

As there is no straw man that you proved, and the latest sentence is a personal attack, you just resorted to the ad hominem fallacy.

Again: An OPT has the inheritent limitation that the pad has to be as large as the data encrypted. As the amount of data transfered by drones is never declared, a claim how long an OTP lasts is futile.

QUOTE (Aaron)
The difference is that public-key is vulnerable to attacks involving large computing resources (like those available in 2070), whereas OTP is not.

If done right - i.e. perfect.

QUOTE (Aaron)
Only information-theoretically secure schemes, of which OTP is one, can be justified in this manner. For schemes that rely on the factorization of (really fraggin') large primes, an increase in the threshold make perfect sense.

Anything can be justified, given the correct spin. You mean 'founded'.

QUOTE (Aaron)
You and your straw-man arguments. I'm disappointed; I respect you too much to believe that you have to resort to such tactics.

Just exclaiming 'straw man' without proving it still means that it's just ad hominem - as does the rest of that quote, as it carries no argument, but attacks.
Ironically, the 'sentence 'And before anybody starts whining about this making hackers and technomancers ineffectual' is a straw man itself, as it distorts a valid concern about reduction in playability into something not to be taken seriously.
Smokeskin
I'm through debating this with you RvD. OTPs are unbreakable. Period. You're just making stuff up or omitting central parts of what people say. Claiming that there's enough of a pattern in numbers generated from measuring naturally random processes to predict what the next numbers are going to be just shows that we're up against pure stubborness. Using brute-force against something encoded with a cipher from naturally random events is just plain pointless, a pattern in the ciphers will just skew the statistical distribution making pattern matching if the same cipher is repeated easier. Trying to brute-force before the cipher is repeated is absolutely pointless, even if you know a lot about how the plaintext should look - check out Aaron's post 4 posts up to understand this.
Aaron
QUOTE (sfogarty)
I am assuming that every implementation of encryption and decryption algorithms is flawed. The math may be perfect, but there are common exploits in the random number generators, the code, etc, etc, etc that make it POSSIBLE for a really complex program to defeat the encryption. Breaking encryption isn't attacking the math, it is attacking the reality.

Information-theoretically secure ecnryption schemes are not impervious to defeat. They are, however, impervious to defeat by purely mathematical analysis. The OTP is vulnerable in three specific ways:
  1. If the OTP table is not random enough, the algorithm used to make the table can be cracked, and then the whole scheme is blown wide open. This vulnerability is easily countered by not using an algorithm when generating a table, as in the keyboard mashing commonly used when generating a PGP key or the random public stream of bits in high-bandwidth traffic (as used in Michael Rabin's hyper-encryption, another information-theoretically secure scheme).
  2. Each OTP table entry can only be used once. If it is used twice, it becomes simple to decrypt any message encrypted with that entry.
  3. The OTP table must be secure and secret. Once an attacker has it, she can use it to decrypt any message by testing the cyphertext with the key and checking the plaintext, a trivial task for computers in 2070.
If I may even go so far as to suggest a few things for people who want to use real encryption rules in their games:
  • Allow characters to use OTP encryption in their subscription lists.
  • A Sniffer program can automatically detect whether public-key encryption or OTP encryption is being used. [This is actually a dicey proposition in Real Life, but I believe it's within the realm of possibility, and so I included it for game balance.]
  • OTP encryption cannot be decrypted with the Decrypt program, but is instantly decrypted if the commlink has a copy of the OTP table file.
  • A device that is forced to reboot (as through electrical attacks) may not use OTP encryption until the OTP table file is given to it by its owner. If transmitted wirelessly, this file is sent using the standard encryption in the RAW, and as such is vulnerable to Sniffer-Decrypt attacks.

In my games, I assume that subscription lists are using some form of information-theoretically secure communication. I simply use that as the fluff explanation for why those devices get the protection of the node's Firewall and go on from there.

As for hacking drones, at some point, I posted two methods to deal with a drone by hacking. I stand by that post.
Rotbart van Dainig
QUOTE (Smokeskin)
I'm through debating this with you RvD.

Then stop it and do whatever you like.
Just don't expect everyone chiming into praises about what perfect loophole you found. wink.gif

QUOTE (Smokeskin)
OTPs are unbreakable. Period.

Like I said: Snake-Oil.
It can - it doesn't have to.
But there are reasons why peolple like Mr. Schneier react allergically when someone claims to have found a perfect encryption scheme.

QUOTE (Smokeskin)
You're just making stuff up or omitting central parts of what people say.

No. You are missing specific limitations, even detailed in Wikipedia.

QUOTE (Smokeskin)
Claiming that there's enough of a pattern in numbers generated from measuring naturally random processes to predict what the next numbers are going to be just shows that we're up against pure stubborness.

It's never about prediction in the beginning. OTP-Encryption has too much possibly valid results on decryption, depending on the key used and thus it is safe. If the key is patterend, however, this is no longer the case.
That doesn't mean that the message isn't sufficiently secure, but sufficient security can be achieved in other ways, too.

QUOTE (Smokeskin)
Using brute-force against something encoded with a cipher from naturally random events is just plain pointless, a pattern in the ciphers will just skew the statistical distribution making pattern matching if the same cipher is repeated easier.

If you ever reuse the key, you have no real encryption at all.
Aaron
QUOTE (Rotbart van Dainig)
Just both are utterly irrelevant to the matter at hand:
One is explaining what an OTP is, and why it is - we are way past that point, as does the second.

Both rely on perfectly random sequences, thus are perfectly secure.
If that isn't the case... well, there goes 'unbreakable':
There's a difference between security through enough O and unbreakable.

I can't decide if this argument is wrong or just poorly expressed.

QUOTE (Rotty)
As there is no straw man that you proved, and the latest sentence is a personal attack, you just resorted to the ad hominem fallacy.

No, I mentioned that the straw-man argument was constructed by removing chunks of my premise. And my last sentence in your quote of me could be construed as a personal attack if you like (it wasn't intended as such, but let's run with the theory), but it's not an example of the ad hominem fallacy. The ad hominem fallacy would have been exemplified by my saying, "you're dumb, and so your argument is false," which I wasn't doing. I was just commenting on your tastes in video; hey, you brought up a hundred years of porn, not me.

But since your argument has devolved, and I've lost respect for you, and I've been looking to blow off some stress, and I'm in a bad mood, I'm going to start mocking you. Politely, though. Look on the bright side: I'm not going to respond to you until you start coming up with a reasonably informed opinion (so, most likely never), so you get to have the last word.

QUOTE (Rotbutt)
Again: An OPT has the inheritent limitation that the pad has to be as large as the data encrypted. As the amount of data transfered by drones is never declared, a claim how long an OTP lasts is futile.

Oh, come on. We're told by the RAW that storage is trivial. Entire simsense flicks can be transferred in under three seconds, and the guidelines tell us that only the smallest of devices should even be considered for possibly running out of storage space. Now you're arguing that since we don't have an exact figure for how much data is transferred by a drone, we can't determine if an OTP table will work? I actually chuckled aloud when I read that.

Here's a guideline for you: pick an amount of time for a rigger to be "jumped into" a drone. Go ahead, make it arbitrarily large. Now, if there's enough space in a device to store that many minutes of simsense flicks, then you've got enough storage.

And if one OTP table runs out of entries, guess what? You can make a new table! Oh, the amazement of it all! Heck, let's make a bunch of tables ahead of time!

Sheesh.

QUOTE (Rotbart van Dumming)
QUOTE (Aaron)
The difference is that public-key is vulnerable to attacks involving large computing resources (like those available in 2070), whereas OTP is not.

If done right - i.e. perfect.

Asked and answered. And given an answer that hasn't been refuted. I'm beginning to suspect it's because you can't.


QUOTE (Rotting vin Diesel)
Anything can be justified, given the correct spin. You mean 'founded'.

Your usage of the period outside of the quote marks is incorrect.

QUOTE (Hobart van Draining)
Just exclaiming 'straw man' without proving it still means that it's just ad hominem - as does the rest of that quote, as it carries no argument, but attacks.

I like how you edited your own comment out of your quote of mine, taking my comment completely out of context in a thinly-veiled effort to prove yours. You don't happen to work for the current U.S. Administration, do you?

Oh, and the ad hominem fallacy requires that I assert that you're wrong because you're ignorant or something like that. I maintain that fact has nothing to do with the reason you're wrong. Even if I was wrong about you making a straw-man argument (I could be; I leave that as an exercise to the reader), it wouldn't be an ad hominem argument, it would be a false statement.

QUOTE (Same Guy - Different Blathering)
Ironically, the 'sentence 'And before anybody starts whining about this making hackers and technomancers ineffectual' is a straw man itself, as it distorts a valid concern about reduction in playability into something not to be taken seriously.

Ever so wrong again. Do you actually look anything up? You should try reading some time. That would be a straw-man argument if I had attributed to someone who did not hold that opinion. What I was doing was distorting a valid concern about reduction in playability, like you said. Hey, that means you disproved your argument with your own supporting statement; you're right, that is ironic.

And here's another ironic thing: I'd still be happy to buy you a drink and talk this out like grown-ups if we ever get the chance to meet in person. That's just the kind of guy I am.

Buh-bye, now.
Rotbart van Dainig
Bah, your FlameFu is as weak as your knowledge of encryption. rotfl.gif

QUOTE (Aaron)
I can't decide if this argument is wrong or just poorly expressed.

That doesn't speak for your cognitive abilities.

QUOTE (Aaron)
No, I mentioned that the straw-man argument was constructed by removing chunks of my premise.

Isolating your false premise indeed wasn't easy.

QUOTE (Aaron)
I was just commenting on your tastes in video; hey, you brought up a hundred years of porn, not me.

So you associate 'FullX' with porn instead of simsense with emotive tracks? How very Freud.

QUOTE (Aaron)
I'm not going to respond to you until you start coming up with a reasonably informed opinion (so, most likely never), so you get to have the last word.

Circular reasoning is so yesterday. wink.gif

QUOTE (Aaron)
We're told by the RAW that storage is trivial.

Nope, we are told that it is up to the GM to decide.
At which point the 'good for years' idea gets busted by whacking the player on the nose with a rolled newspaper.

QUOTE (Aaron)
Asked and answered. And given an answer that hasn't been refuted.

If you don't accept that your definitions are false, doesn't really mean a thing.

QUOTE (Aaron)
That would be a straw-man argument if I had attributed to someone who did not hold that opinion. What I was doing was distorting a valid concern about reduction in playability, like you said.

The latter indeed is what makes up a Straw man.

QUOTE (Aaron)
And here's another ironic thing: I'd still be happy to buy you a drink and talk this out like grown-ups if we ever get the chance to meet in person. That's just the kind of guy I am.

Heading straight for booze on every occasion? I imagine. wink.gif

QUOTE (Aaron)
Buh-bye, now.

Don't drink and drive.
M.Fillmore.1138
QUOTE (Aaron)
And if one OTP table runs out of entries, guess what? You can make a new table! Oh, the amazement of it all! Heck, let's make a bunch of tables ahead of time!


The point is that you have to somehow, securely get the new OTP key to the Drone. If it is out "in the world" and has used up all its pages, then you have nothing to send it. If you ever re-use a OTP cypher it stops being one-time and becomes significantly easier to crack.

You are arguing "competing infinities". If you can always have enough storage to continue the pad, great. Someone can always continue to trigger results that force you to consume the pad. If you can ever trigger a false positive hit such that you can increment the pad count on either end of the equation, then you will throw them out of sync and they will not get back into sync until they have a non-compromised channel to set up communications. Since they are not on the same "page" of the pad, there is no way to re-establish communications.

The best way is to just corrupt the commands on their way to the drone, but sending false commands also works pretty well. Most drone commands are very time sensitive, so if you can force enough retries, the command becomes irrelevant.

Aaron
QUOTE (M.Fillmore.1138)
The best way is to just corrupt the commands on their way to the drone, but sending false commands also works pretty well. Most drone commands are very time sensitive, so if you can force enough retries, the command becomes irrelevant.

I agree. The best ways to deal with an agressive drone are to either smack it with a jammer, or just shoot it down.
Red
QUOTE (Aaron)
QUOTE (Red @ Aug 22 2006, 12:16 PM)
For all the back and forth here about what can and cannot be cracked eventually, I see no math with regard to magnitude.  And without magnitude, we have no sense of scale.

All the math you can eat for the one-time pad is in a PDF document from Queen Mary University of London.

Thank you for the doco, Aaron. I will run this idea by my gaming circle and see if we can come to a consensus.
Smokeskin
Alright, let's look at some of your ideas:

QUOTE (Rotbart van Dainig)
QUOTE (Smokeskin)
OTPs are unbreakable. Period.

Like I said: Snake-Oil.
It can - it doesn't have to.


That's the same as if I said "I can run a marathon" you'd say "not if you had the flu"? Or "Snipers can hit targets at 800 meters" you'd say "Some people can't do that, and if their rifles are unzeroed they sure can't"? Sure, you can make OTPs that are breakable, but why on earth would a military black-ops equivalent operation 64 years in the future screw up like that?

QUOTE (Rotbart van Dainig)
QUOTE (Smokeskin)
You're just making stuff up or omitting central parts of what people say.

No. You are missing specific limitations, even detailed in Wikipedia.


You're the one ignoring specific limitations. For exampe, you like to say "if the encryption scheme uses PRNGs, it's breakable". What you're omitting is that you don't just wave a magical decryption wand to break anything with a PRNG. You need a lot of samples to work out the guts of a PRNG. A scheme where you use a number from a PRNG every 2 hours is effectively unbreakable since we're not talking about a situation where you'll be transmitting for weeks.

QUOTE (Rotbart van Dainig)
QUOTE (Smokeskin)
Claiming that there's enough of a pattern in numbers generated from measuring naturally random processes to predict what the next numbers are going to be just shows that we're up against pure stubborness.

It's never about prediction in the beginning. OTP-Encryption has too much possibly valid results on decryption, depending on the key used and thus it is safe. If the key is patterend, however, this is no longer the case.


Look, it is about prediction. If you can't predict what the next cipher is, you haven't cracked the encryption scheme. You can't hack the drone, because you can't send properly encrypted messages.
If you just want to decode the transmission, the more of a pattern the easier it becomes. However, if the cipher has a pattern but it is not predictable (which I think even you will agree isn't the case here, if these naturally generated ciphers were predictable there'd be a Nobel prize in it), that is a lot harder than predictable patterns. Plaintext coded with an unpredictable cipher carries as much "regularity" or "variance from the plaintext" as the cipher. If the cipher is sufficiently "noisier" than the plaintext, then you lose any ability to decrypt it by brute-force methods. Brute-force is based on recognition of a correct decryption. If you're trying to decrypt my comms, even if you know my voice, you're just as likely to get my voice describing a completely fictional battle plan or citing shakespeare as what I actually said. The methods you're suggesting just aren't feasible. (Sorry for not knowing the information theory lingo for it.)

You're just going "random naturally data has a pattern => it's pseudo-random => it's decryptable". Each of those steps are just wrong in the cases used here. You're going on pure strawman.
Rotbart van Dainig
QUOTE (Smokeskin)
Sure, you can make OTPs that are breakable, but why on earth would a military black-ops equivalent operation 64 years in the future screw up like that?

In short - because that's the way SR is designed: On the premise that everyone screws ups.
'Weak' security in every aspect of the game so it can be overcome and there is a run at all. (Not that all runners are even a close equivalent to military black-ops, but the opposition quickly is.)
Correctly done, you can justify any increase in difficulty by real world applications (or decrease, in the case of bumping keys...), to a point were it is 'realistic', but that's about the point were it stops being a game (that simply can be played by the rules) and becomes a training scenario (that requires profound actual knowledge).

The suggested use for OTPs is not 'drone-only', as it can be used for any peered communication that features secure transmission of the key. Given the storage capabilities, you can easily encrypt communication networks of teams that way, the important channels of corporate communication, in short - if you do it, everyone could and will.
And no, hacking the drone commlink isn't an option, as it is a second, stand-alone link that only accepts OTP-encrypted messages, too and otherwise is directly controlled by the user.

Basically, that results in two possibilities: Take out hackers of most elements of the game, or handwave that such encryption is only possible for drones, resulting in a game balance shift.
If everyone agrees, those are perfectly acceptable houserules.

QUOTE (Smokeskin)
For exampe, you like to say "if the encryption scheme uses PRNGs, it's breakable".

Not really... nearly every modern encryption scheme does, for seed of hashing and salt, etc. - that isn't the reason you can break them, though. The point is that OTPs directly rely on the quality of randomness, and are only proven for perfectly randomness.
Like I already said, that doesn't mean that the security isn't sufficient for the given application.

QUOTE (Smokeskin)
You need a lot of samples to work out the guts of a PRNG. A scheme where you use a number from a PRNG every 2 hours is effectively unbreakable since we're not talking about a situation where you'll be transmitting for weeks.

Where do you get those numbers from?
Again: As the amount of new key used is the same as the amount data transfered, how long it takes for an attacker to have sufficient data depends entirely on what you are transmitting and the quality of the PRNG.

If you limit that data to the bare minimum, you wouldn't need such an encryption scheme in the first place: You would maintain radio silence and thus be nearly invisible in the static.
SR has no rules for that, either.

QUOTE (Smokeskin)
Look, it is about prediction. If you can't predict what the next cipher is, you haven't cracked the encryption scheme. You can't hack the drone, because you can't send properly encrypted messages.

It's possible that security schemes through encryption can still work after a partial break, for exactly those reasons. The point is that this doesn't qualify for 'unbreakable' anymore.

QUOTE (Smokeskin)
If you're trying to decrypt my comms, even if you know my voice, you're just as likely to get my voice describing a completely fictional battle plan or citing shakespeare as what I actually said.

In the case of an OTP, that's exactly what I meant by too many possible results.

QUOTE (Smokeskin)
You're just going "random naturally data has a pattern => it's pseudo-random => it's decryptable". Each of those steps are just wrong in the cases used here. You're going on pure strawman.

Look, again: It's not about 'sufficient security', it's about 'unbreakable', which you claimed, and which, given perfect randomness, a OTP really is.
Aaron
Smokeskin, you don't need to use a PRNG. In fact, most modern encryption systems don't use them, because they're predictable. Michael Rabin came up with a clever way of getting random numbers without using a pseudo-random algorithm: he takes numbers out of a public data stream. If you pull numbers at pseudo-random intervals out of, say, the wireless traffic going by, you come up with truly random numbers. The interval is predictable, but the actual data going by is not, and that actual data is what is being used. You don't even need to decrypt the signal going by, you can just take n bits out of it and call that your number.
Smokeskin
QUOTE (Aaron)
Smokeskin, you don't need to use a PRNG. In fact, most modern encryption systems don't use them, because they're predictable. Michael Rabin came up with a clever way of getting random numbers without using a pseudo-random algorithm: he takes numbers out of a public data stream. If you pull numbers at pseudo-random intervals out of, say, the wireless traffic going by, you come up with truly random numbers. The interval is predictable, but the actual data going by is not, and that actual data is what is being used. You don't even need to decrypt the signal going by, you can just take n bits out of it and call that your number.

Clever smile.gif

I guess it could work for a drone and a rigger apart from eachother even. The rigger tells the drone to download a large media file (this can be done in cleartext), and they're both picking bits from it by the same pre-arranged method to make new OTPs as needed.

Didn't Johnny Mnemonic encrypt the data in his head with 3 images from the TV? I bet that was before Rabin came up with it even wink.gif
Aaron
QUOTE (Smokeskin @ Aug 23 2006, 02:24 PM)
I guess it could work for a drone and a rigger apart from eachother even. The rigger tells the drone to download a large media file (this can be done in cleartext), and they're both picking bits from it by the same pre-arranged method to make new OTPs as needed.

Either this wouldn't work (as the source of the "randomness" is actually a fixed media file), or it's just another layer on the same thing (where the large media file is essentially either the OTP table or merely another key, except a predictable one).

QUOTE (Smokeskin)
Didn't Johnny Mnemonic encrypt the data in his head with 3 images from the TV? I bet that was before Rabin came up with it even wink.gif

Maybe. The hyper-encryption algorithm was first published (I think) in 2002, but Dr. Rabin has been working on this sort of thing since the 1950's.

Even so, conceptualization is not design and implementation. Hermann Olberth described the use of satellites in geostationary orbit for telecommunications in 1923, and was more fully developed by Sir Arthur C. Clarke, but Syncom 2 was developed and created by NASA.
Rotbart van Dainig
QUOTE (Smokeskin)
Didn't Johnny Mnemonic encrypt the data in his head with 3 images from the TV?

Not quite - those image were a part of the key (which means JM used a classic symmetric key as this facilitates key distribution), indeed, but served as starting point for 'remembrance', too.

Just don't use media files directly as an OTP, (any form of using them as seed/table will do, though) as those formats have container data that is structured.
Smokeskin
QUOTE (Aaron)
QUOTE (Smokeskin @ Aug 23 2006, 02:24 PM)
I guess it could work for a drone and a rigger apart from eachother even. The rigger tells the drone to download a large media file (this can be done in cleartext), and they're both picking bits from it by the same pre-arranged method to make new OTPs as needed.

Either this wouldn't work (as the source of the "randomness" is actually a fixed media file), or it's just another layer on the same thing (where the large media file is essentially either the OTP table or merely another key, except a predictable one).

Then I don't think I understood the mechanism you described - you said you could pull out numbers from a public data stream at pseudo-random intervals. The problem we're trying to solve here is that the drone has limited storage - it can't carry an infinetely large OTP, so it is only a matter of time before they've used the entire pad. What do they do from there?
Aaron
QUOTE (Smokeskin)
Then I don't think I understood the mechanism you described - you said you could pull out numbers from a public data stream at pseudo-random intervals. The problem we're trying to solve here is that the drone has limited storage - it can't carry an infinetely large OTP, so it is only a matter of time before they've used the entire pad. What do they do from there?

I think that's a moot point from an operational standpoint, given the storage descriptions in the rulebook. Given the assumption that a command is probably not too much more than around 4k (assuming that a single command is around a full page of text in size), then a table that can handle a constant stream of commands at four IPs per Combat Turn (eight commands every three seconds) for over three days would fit on a USB thumb drive that you could run out and buy from Circuit City.

Given Moore's Law (which isn't a law so much as an observation), which roughly states that computing power doubles every two years or so, and the fact that it's 64 years until 2070, we can guess that a similar thumb drive will store over four billion times more data. Heck, even if we assume a tenth of that, that's still a really big fraggin' OTP table.

So I believe it's a reasonable assumption that any rigger with an Electronic Warfare Rating would create an OTP table (using a public data stream as the random number generator) that was fraggin' huge, like good for a year or so, and then transfer that table to the drone(s) in a secure manner, as through a cable, skinlink, or even physical transfer via datachip. If she remembers to change that OTP table every month, then it's all good. If she's in the field for a year straight, without a break, then she's probably got other concerns than keeping her drones encrypted properly.
Rotbart van Dainig
QUOTE (Aaron)
So I believe it's a reasonable assumption that any rigger with an Electronic Warfare Rating would create an OTP table

OTPs are an old, simple method of encryption, that, by no means, is secret knowledge and can be done with a parer and a pen - in short, everyone with peering-applications will.
Smokeskin
QUOTE (Aaron)
QUOTE (Smokeskin)
Then I don't think I understood the mechanism you described - you said you could pull out numbers from a public data stream at pseudo-random intervals. The problem we're trying to solve here is that the drone has limited storage - it can't carry an infinetely large OTP, so it is only a matter of time before they've used the entire pad. What do they do from there?

I think that's a moot point from an operational standpoint, given the storage descriptions in the rulebook. Given the assumption that a command is probably not too much more than around 4k (assuming that a single command is around a full page of text in size), then a table that can handle a constant stream of commands at four IPs per Combat Turn (eight commands every three seconds) for over three days would fit on a USB thumb drive that you could run out and buy from Circuit City.

Only encrypting commands wouldn't require much storage, and would prevent hacking and spoofing.

But if the rigger jumps in, you'd need a lot more than just commands transferred. The drone needs to constantly transmit the sensor feed, and the rigger needs to send very detailed operations commands back. If you want to be able to transmit encrypted sensor feed to the rigger so he and the team can get an overview on their AR for example, you'd need more too.

I was figuring that if the drone had storage to record 8 hours of sensor feed, you'd use 25% of that storage to allow for 2 hours of OTPed transmission. If you assume drones have more storage capacity, that changes it of course.

Anyway, back to the public stream random number generation, couldn't it be done on the fly by just downloading some public media files of some sort?

PS: I think that if Moore's law holds till 2030, then transistors will have to be the size of hydrogen-atoms. AFAIK people recognize that there's a physical limit to how fast information can be processed (as we understand physics today at least).
Aaron
QUOTE (Smokeskin)
Only encrypting commands wouldn't require much storage, and would prevent hacking and spoofing.

But if the rigger jumps in, ...


Good point. I never jump into my drones (I find that the advantages are outweighed by the risks), so I didn't think of that.

QUOTE (Smokeskin)
Anyway, back to the public stream random number generation, couldn't it be done on the fly by just downloading some public media files of some sort?

I'd feel uncomfortable doing that, from a security standpoint. There's too much order in a coherent file, and the security of the OTP is based on perfect randomness. The idea is that the OTP table is generated with complete randomness, and so any system to do that on the fly would by necessity impose a certain amount of order, thus making it insecure.

QUOTE (Smokeskin)
PS: I think that if Moore's law holds till 2030, then transistors will have to be the size of hydrogen-atoms. AFAIK people recognize that there's a physical limit to how fast information can be processed (as we understand physics today at least).

Nobody said that the chips we put the transistors on had to stay the same size, just the number we get to work together. As to the speed of information processing, I'm fairly certain I read an article some years ago where they actually got something to travel faster than light: data. It was done -- and I'm trying to recall this, so I might be mistaken about a few details -- with a long tube containing some sort of gas, where some property of that gas changed uniformly throughout the tube when somthing was changed at one end.

But who can really predict The Future?
Crusher Bob
QUOTE (Smokeskin)
...

Anyway, back to the public stream random number generation, couldn't it be done on the fly by just downloading some public media files of some sort?

...

In theory, you can generate random pads from things like exact packet timings. However, the problem remains that the pad can ge generated either by the drone or the rigger. However, you then have no way of sending the new randomly generated pad to the other.

Aaron
QUOTE (Crusher Bob)
In theory, you can generate random pads from things like exact packet timings. However, the problem remains that the pad can ge generated either by the drone or the rigger. However, you then have no way of sending the new randomly generated pad to the other.

Excellent summary of the problem. One can't really send it via OTP, because your (current) table would have to be at least as large as the new one. If that were the case, there would be no advantage to having a new table.
kzt
From a theoretical standpoint, anyone who wants to put a lot of effort into maintaining a secure network should be able to do it. For example, the use of OTPs to change out the 1048576 bit cipher block encryption keys via OTAR every few seconds.

But the number of people who really care enough to do this is small. It's a LOT of effort. Pretty much the only people who really do this in the real world are the military/DOE. And even then they don't do it for everything.

The commercial market for really secure encryption hardware is very small, for a good reason. Setting up a secure network and the required key distribution system is complex, painful and expensive, and is expensive to maintain.

Just operating in a secure mode is a pain. I knew someone at a DOD contractor that seemed to spend half his life reinitializing secure hardware that had a bit glitch and flushed the keys. I'm sure it's better now, but very few commercial organizations are wiling to do this sort of stuff. How many commercial companies have their buildings constructed and maintained as faraday cages to protect against electronic snooping, which is fairly well understood threat?

In the real world, outside of the military, people use 3DES VPN passwords that are 6 characters, which gives an effective password length of maybe 40 bits, because it's easy. They use AES encryption on wireless network with 12 character passphrases because it's easy and makes them feel secure.

So it's reasonable to say that a given organization has effectively unbreakable encryption for something that is very important to them and worth spending a lot of money on. These would be the same people who use run all their outside cables in pressurized rigid conduit, have mantraps on all the entrances and exits, construct their buildings as faraday cages, enforce multi-factor access control systems and, in Shadowrun, have 24x7 on-site magical security TEAMS and immediately responding reinforcements loaded for bear.

I think Shadowrun makes all encryption way to easy to break, but most people won't really lock their systems down like they should, so many to most systems will be compromisable with some to lots of effort. But it all depends on what you want the game to run like.


I once played Shadowrun with a guy, who in real life, was a USAF Pave Low pilot. He pointed out that he had hundreds of people in his unit who would spend days or weeks doing the prep work for a mission that, in a game, he'd accept from some guy in a bar and spend 20 minutes looking around before executing.
kzt
QUOTE (Smokeskin)
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.

The use of one-time pads is unnecessary. Symmetric key encryption is not significantly vulnerable to quantum computers.

Essentially a functioning quantum computer that is able to attack a large cipher (it is still not at all clear that it's possible to actually construct and keep stable at all, much less in a portable form factor - but we will pretend it is) cuts the number of bits in symmetric key cipher (like AES) in half. So what this means is that a 256 bit AES encryption system being attacked by a really huge distributed system dedicated to decryption using all the fancy tricks and quantum computing hand waving can brute force the entire keyspace in a mere 23,397,696 years. If you go to a 512 bit key it takes about 8*10^45 years.

This assumes a computer processor 1,073,741,824 (2^30) faster than current, with 1024 systems, each with 1024 blades of 1024 processors each, each processor running 4.3*10^14 keys per second and using quantum computing to turn it into effectively a 128 or 256 bit key from a 256 or 512 bit key.

Wiseman
Trying to follow all that was one hell of a mental exercise, but I think I understood enough to at least comment a little.

Its argued that most encryption in the game would be Public encryption (breakable) and the really tough stuff would be OTP (unbreakable for all intents and purposes of a run). No problems there.

Forgetting all the assumed or imagined realism in 2070, what does that all mean to the game? So as a GM I look at what is the impact on the game and players. Would every hacker/rigger use an OTP, unique to every item on his subscription list and perfectly set-up with random numbers to be unbreakable (doubt it). Would even a security rigger (spider) have em (probably not).

Considering decrypt is a hacking program and has a much higher availability and is restricted, it makes sense that average encryption is plenty of security for basically everyone.

My windows OS has encryption capability (in the game a common computer program), but I don't have anything on my PC that will decrypt even the combo to my briefcase, without searching warez or writing my own.

So when does this come into play, when is encryption unbreakable. When the GM needs it to be I guess. In the published "On the Run" adventure, the players are asked to decrypt a disk, but they can only decrypt a little of the information, not the whole disk. No matter what they try they can't decrypt it all. Now, no reason is given as to the mechanics of why, but for plot purposes, the adventure doesn't want them to fully decrypt it, so it can't be done.

Unbreakable encryption does exist (or at leasts exists in the timeframe that players are usually forced to operate in). Would requiring the runners break into some military facility to download some currently used OTP's so they can spoof commands at the door of a nuclear test facility rather than let them crack the door, edit the camera feeds, and turn off the auto-turret drones in 2 minutes be desirable for a GM? Damn right it would, and it would make them feel that they are dealing with the more than average security of 2070.

I don't see any problem with the "unbreakable/perfect" OTP lists when used sparringly and on very important items/data/etc, and only when it furthers plot by making the players think a little more outside the box than toss a handful of dice.

But, I wouldn't allow every rigger/player to set up unbreakable encryption though, as it would just slow down the game for only the benefit of realism. If I wanted to do that, I'd require characters to run out of breath, go to the bathroom regularly or suffer cramp distraction penalties, eat nutrious food or suffer junk food addiction and weight gain (eventually requiring strength tests to move), or give them a penalty to charisma/social skills for not brushing their teeth enough.

What this whole post amounted to (for me anyways) was a good bit of knowledge on how to explain why they can't just crack the Atlantean Foundation's data disk on the location of that super wiz artifact gate-stone and the instructions on how to utilize the markings on its side to call back Ghost Dragons or what not, rather than just saying "because you can't" or "its unbreakable".

There really isn't any arguement for realism in any RPG. It simulates reality only to the extent that it needs to for imagination to latch onto something. Mechanics exist only to give a basic structure to build that fantasy in terms/definitions everyone can agree on.

So thanks for some good learning for my brain and a nice trump card justification for when the players want to do something in the matrix that I don't want to be that easy that one time. Other than that, I don't get the point.


Rotbart van Dainig
You have two problems here:

First, the encryption featured by 'On the Run' is a symmetric key combined with stenography, including a reactive component, based on ten year old algorythms.
Neither is it possible for it to be unbreakable, nor to act as a Databomb for a read-only media.
Basically, OTR features a typical Deus Ex Machina.

Second, OTPs are valid for any pairing application as the transimissen of the OTP is secure and used for later communication. Given usual attack scenarios, it would be perfectly reasonable to use it for any critical component.
On the other hand, given the TL of SR4, it would be more efficient to use quantum channels for drones.
Wiseman
I mean your right, and you definitely understand more about encryption than I ever will.

However my point is: whats it mean to the game? see to me discussing rules and would-be's without the context of players in the actual game is just a lot of wind and words.

I don't want players with unbreakable encryption on their commlinks anymore than I want the bad guys to. With the exception of a few special cases, not being able to do something isn't fun, as you point out with OTR.

My only reason for bringing up OTR is to say that the OTP sounded like a far better reason than the ones they gave which amounted to "no you can't do this".

I haven't run the OTR adventure however, I bought it as a template or guide to see how the designers think its done. So I couldn't tell you how satisfying or unsatisfying it was.

I can't really argue why they don't use OTP or how it would be better, its not in the game. Its neat info for those "well I want the bad guys after the player's disc but I don't want the players to read it" scenerios, but any good game would be built on them cracking the contents open and deciding what to do next.

Seriously though, alot of interesting thoughts in this thread, but mostly just for the behind the scenes background stuff than actual game mechanics.


Metalsmith
QUOTE (Smokeskin @ Aug 21 2006, 02:32 AM)
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.

I've always envisioned the Exploit and Decrypt programs to be a Front-End of a Big-Damm-Codebreaking Network. The Program takes an "impression" of they type of Crypto thats targeted. Takes Measurements and then squirts it back to the Network and the B.D.Network thrashes though mathematical gymnastics and replies with some information the Front-End can try to beat the Encryption.
Rinse Repeat.
The various ratings of the Front-End program shows how good the collection of measurements will be.

This means industrious hackers can code up their own Exploit and Encrypt 7 programs without being monstrously intelligent. They are not developing new codebreaking tecniques they are improving the front end.

Besides if encryption was universaly unbreakable then Hackers wouldnt be necessary and the game would just consist of running around and beating people up.


-----------METALSMITH------------^^^^
Rotbart van Dainig
QUOTE (Wiseman)
My only reason for bringing up OTR is to say that the OTP sounded like a far better reason than the ones they gave which amounted to "no you can't do this".

OTPs are nearly useless for data storage:

Essentially you would have two discs of the same size filled with completly random data, that only combined result in something meaningful.

The number of scenarios where such security would prove actually useable and usefull is very limited...
Wiseman
QUOTE
Essentially you would have two discs of the same size filled with completly random data, that only combined result in something meaningful.


Works for me! Hell, there could be more than two...Now you may have something golden there....

I smell a plot device.

I like that, its akin to assembling artifacts in old school DnD and even better.

But point noted, I didn't really think through the OTP as you guys explained it when I was talking about a disk. Think I defaulted to the disk example in talking about OTR, but the original example was a security door/camera/turret thing.

Steak and Spirits
I'm coming in late to this conversation. But, to be honest, the notion of any sort of realistic encryption being broken in a few combat turns is incredibly ridiculous.

As a representative of the cryptographic field, specialized cryptography takes years to decipher at the most unsecured level, short of user error.

It's purely as a gameplay facet. So. You're going to need to accept Shadowrun Cryptology works different than real life, and suspend disbelief.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Dumpshock Forums © 2001-2012