SR3R Project Forum

Discussion and debate for the SR3R Project
It is currently Mon Oct 21, 2019 2:09 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: Encryption
PostPosted: Thu Jun 26, 2008 3:57 pm 
Offline
Forum Admin

Joined: Tue Jul 17, 2007 11:50 am
Posts: 827
Location: DeeCee
Encryption has always been the elephant in the corner in my games. Of course, SR encryption generally doesn't make a lot of sense, and it doesn't help that there are at least three or four different rules based not on the type of encryption, but on what it's being used for. Therefore, in my games, I've sat down and briefly wrote out some very basic concepts for encryption.

Firstly, the radical change in the nature of computers has completely shifted how encryption works. You can decide for yourself what neat aspect of science fiction is the cause of this, whether it's the introduction of quantum computers or if optical computers just inherently work differently, but the core of it is, triple DES just won't cut it.

There are two major traits to observe when determining the appropriate encryption for a given thing:
1) high vs. low bandwidth (alternatively, static vs. dynamic content). High bandwidth/dynamic content is what you need for things like matrix and rigger connections. Low bandwidth/static content is what you use for files, or possibly, for certain access points and the like. Low bandwidth can be less transparent and take more time for the authorized user to decrypt, and so can have a more complex form of encryption. Because ASIST interfaces move at the speed of thought, necessarily they must be instantaneously decrypted and absolutely transparent, which ultimately serves to reduce its strength as an encryption algorithm. We can decide later where we'd categorize low bandwidth stuff like radio communications. So far I've been categorizing it with matrix and rigger connections, but it might be more interesting to say that things as simple as the command line can, because of their simplicity, take advantage of superior encryption.

2) Large vs. small pool of users. A small pool of users can be managed more precisely, because you know precisely who you'll be dealing with. The easiest example (if only to get people on DSF to shut up about it) is to say you have a one-time pad. With a small group of users, each user and each device manually has its firmware updated. In theory this would be best done IRL and manually, but you could upload it via the matrix (of course, introducing security concerns in the process). A large pool of users makes this unfeasible, because of the sheer difficulty in sharing that secret so far, and the fact that so many people with that secret means it's much easier for it to be compromised, and should it become compromised, the person is given basically free access. Instead, the large pool method uses some other method of verifying every user who logs on. The actual mechanics are fairly irrelevant, but let's say it's certificate based. It checks your certificate against a central authority somewhere. There are holes in this defense, but overall it's fast, effective, and requires no prior setup.

Given these two axes, we have four options which can be applied to any wired or wireless encrypted technology:

High-bandwidth/many users - this is your common matrix setup. It's relatively easy to crack with the right gear, but it allows matrix hosts to be robust and user-friendly.

High-bandwidth/limited users - this is generally your rigger setup. The result is drones are a good deal harder to steal because they use this form of encryption which is so much tougher to crack. However, on the flip side, it requires more time invested for each drone and user (generally not an issue for drone riggers). This method is definitely time consuming.

Low-bandwidth/many users - These are files and, possibly, command line connections. While they aren't as secure as the one-time pad above, they don't need to be as transparent as the high-bandwidth matrix connections, and so can afford to be more difficult to use and less user friendly. These can be cracked with the right tools, but it takes time.

Low-bandwidth/limited users - Haven't found a use for this yet, but it would be the absolutely most difficult to crack, the plot item you just can't allow into the PCs hands at this point, state secrets, hard core programs and the like.



If people agree on this, we can just make these three or four types of encryption and people can apply them to whatever they want. You can have a well-secured matrix system with high-throughput/limited users. You can have a factory with a thousand specialized drones and 500 operators which use the high-throughput/many users system. A small party might use the limited user protocol on their radios, but find then they can't take advantage of the new member who hasn't had a chance to sync up with their radios, and meanwhile everyone is limited to the lowest-rating encryption in the group.

Any thoughts on this?


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Sat Sep 13, 2008 7:01 pm 
Offline

Joined: Thu Jul 19, 2007 9:34 pm
Posts: 105
Location: Oceania
Assuming one uses a common mechanic for decryption (i.e. opposed test) the different options could be used to set the time frame for decryption, from a turn to a month (or year?).


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Mon Sep 15, 2008 1:06 pm 
Offline
Forum Admin

Joined: Tue Jul 17, 2007 11:50 am
Posts: 827
Location: DeeCee
I was considering a different method, but I think your suggestion has its place as well, as evidenced even by what I already wrote.

I don't really like the idea of just lengthening the time, simply because wicked-hot gear gets diminishing returns. A rating 20 decryption module is only slightly faster than a rating 10 decryption module, assuming both get at least 1 success, because each additional success means less than the one before. However, making it harder to get that initial success means the rating 20 gear is more valuable again, because that first success is so difficult to achieve. However, when you don't have a lot of data (low-bandwidth), it really may just be an issue of taking lots of time. This also helps for plot, because high-bandwidth stuff (matrix and rigging) are almost always high-action things, where every second counts. EM warfare where you had to spend two hours trying to crack the bad guy's communications is boring. On the flip side, it's fun to have secrets which you can't decrypt when you need them, but come up later. Coincidentally, this matches our low-bandwidth stuff. You have the password to the file, but you can't open it... yet. You have the other guys' radio comm channels, but don't know what they're saying... yet. Holding this data for minutes or hours has a lot of strategic fun, but cracking it in seconds eliminates all suspense.

So I would suggest the following:

The number of users determines the effective rating of the encryption. Many-users run as currently specified. You roll decryption against their encryption and vice versa. Net successes wins.

Low-user systems are harder to crack, the encryption is effectively doubled. So you roll decryption against encryption * 2 (not sure if they'd roll encryption or encryption * 2 against your decryption, however. Keeping the multiplication on the other side might make it a bit too cut and dry.) Net successes wins.

High-bandwidth systems are cracked faster because they have more data to examine. Time is measured in minutes or rounds. I would tend to say that each attempt takes a single initiative turn (although since the machine is doing most of the work, the person takes a single complex action, then can do other things while waiting for the result.) This does mean multiple decryption systems running in parallel would be a bonus, however, so the current pricing system would have to be reworked (since for someone with the initiative to run it, two rating 4 systems are equivalent to a single rating 8 system).

Low-bandwidth systems are cracked slower, so the base time is 2 hours, perhaps.

Thoughts?


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Thu Sep 18, 2008 12:23 am 
Offline

Joined: Thu Jul 19, 2007 9:34 pm
Posts: 105
Location: Oceania
nezumi wrote:
The number of users determines the effective rating of the encryption. Many-users run as currently specified. You roll decryption against their encryption and vice versa. Net successes wins.

Low-user systems are harder to crack, the encryption is effectively doubled. So you roll decryption against encryption * 2 (not sure if they'd roll encryption or encryption * 2 against your decryption, however. Keeping the multiplication on the other side might make it a bit too cut and dry.) Net successes wins.

Yeah that works, it keeps the basic mechanic and covers the variations you defined with your bandwidth/users axis where bandwidth determines time and the number of users modifies difficulty.

It's been discussed elsewhere on sr3r about having have drone networks (and battletac and CCSS systems too) less vulnerable than decking and to what degree. In doubling the rating, the idea is that attacks will be more difficult but still resolved in a viable time frame, yes?

nezumi wrote:
I don't really like the idea of just lengthening the time, simply because wicked-hot gear gets diminishing returns. A rating 20 decryption module is only slightly faster than a rating 10 decryption module, assuming both get at least 1 success, because each additional success means less than the one before.

In an attempt to reform the electronic warfare rules, I considered having the unit of time for all tasks (e.g. decryption and signal interception) be determined by the number of successes obtained. This ranged from a day for 1 success to a turn for 4+ successes. Whether this would work with the system you've outlined I don't know.

nezumi wrote:
This does mean multiple decryption systems running in parallel would be a bonus, however, so the current pricing system would have to be reworked (since for someone with the initiative to run it, two rating 4 systems are equivalent to a single rating 8 system).

I see the gear ratings as something more akin to the richter scale where a point of rating is exponentially superior so that a rating 8 decryption module might be 10 times better than a rating 4 model or such.

Other elements of my house rules that may be relevant include the idea that encryption outstripped decryption (where 1st ed. capped decryption at rating 8.) and the rule from Cybertechnology regarding skill users with good gear. This would require more involvement than an action to turn on the gear but could yield a significant advantage.
Quote:
Jamming and counter-jamming are achieved with ECM/ECCM (also as add-ons to communication equipment.) To resolve jamming or counter-jamming attempts, make an opposed test pitting the rating of the Jamming component against the rating of the counter-jamming component (or vice-versa). Characters who have a Special Skill related to the use of the jamming or counter-jamming element in question, or who have encephalon (see p49 Shadowtech) may add a number of additional dice up to the rating of the ECM/ECCM gear. The jammer or counter-jammer that achieves the greater number of net successes accomplishes its task; In the case of a tie, the jamming unit is successful. The number of net successes determines the overall success of the jamming or counter-jamming attempt. To resolve attempts at encryption and decryption of communications signals, use the same procedure as for jamming and counter-jamming. from Cybertechnology


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Thu Sep 18, 2008 8:58 am 
Offline
Forum Admin

Joined: Tue Jul 17, 2007 11:50 am
Posts: 827
Location: DeeCee
Link wrote:
It's been discussed elsewhere on sr3r about having have drone networks (and battletac and CCSS systems too) less vulnerable than decking and to what degree. In doubling the rating, the idea is that attacks will be more difficult but still resolved in a viable time frame, yes?


Correct.

Quote:
In an attempt to reform the electronic warfare rules, I considered having the unit of time for all tasks (e.g. decryption and signal interception) be determined by the number of successes obtained. This ranged from a day for 1 success to a turn for 4+ successes. Whether this would work with the system you've outlined I don't know.


That's a neat idea. My one complaint would be, there's no precedent for it in the rules, so it would be yet another form of resolving tests. If we find the current method doesn't work (and as a general rule, I don't think it does), that's a good alternative, but I'd prefer to work within the rules as stated as much as possible first, just for consistency's sake.

Quote:
I see the gear ratings as something more akin to the richter scale where a point of rating is exponentially superior so that a rating 8 decryption module might be 10 times better than a rating 4 model or such.


Precisely, which is why I quoted that as a problem. Although on further thought, I forgot that it's an opposed test, so two rating 4 systems still won't quite be comparable to one rating 8 system. However, as someone keeps upgrading systems, he'll have older systems sitting around presumably, so he may still find it worthwhile to run the lesser systems after he starts the highest rated one. I don't know if this should be considered a problem or not.

Quote:
Other elements of my house rules that may be relevant include the idea that encryption outstripped decryption (where 1st ed. capped decryption at rating 8.)


I think that's problematic for a few reasons.

Firstly, as a GM, you can always set encryption above anything the party can reasonably crack, if that's your desire. So that rule doesn't contribute any tools the GM doesn't already have.

On the flip side, it means that at higher level decking systems, encryption becomes the end-all and be-all. If you're running a red host, you can encrypt everything at rating 12 and not bother loading any IC knowing that it's practically unhackable. With our low-use systems, it effectively already is the case, since a rating 8 encryption is equivalent to rating 16 decryption.

Quote:
and the rule from Cybertechnology regarding skill users with good gear.


(Thanks for including it.)

Hmm... That's an interesting rule. I am not displeased with it, although it may warrant its own discussion. I'll go ahead and start a new thread on that so hopefully we can actually settle an issue in the SR3R forum (hah, maybe).


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Fri Nov 27, 2009 11:52 pm 
Offline
Forum Admin

Joined: Wed Jul 18, 2007 3:11 am
Posts: 903
I think nezumi has managed to hit on exactly the reason we can justify keeping SR3 encryption essentially the way it is.

If I remember right, there are basically two different types of encryption in SR3. There's the Matrix version of Encrypt/Decrypt, which basically makes encryption a joke (Simple Action Roll Computer against TN of IC Rating-Decrypt), and then there is broadcast encryption and Rigger drone encryption, which if I remember are basically the same and can probably be combined (canon rule p. 289 is roll Decrypt w/ Electronics Warfare complementary skill, vs TN of Encrypt+4, Threshold of Encrypt/2, round up, base time (Encrrypt*5) minutes.)

Before this seemed like a stupid inconsistency, but when I hear nezumi talk about limited audience and large audience it makes more sense. Now I see that Matrix "encryption" is certificate-based, which is largely a joke by 2060 and really only exists to check a box on a corporate compliance worksheet. Rigger- and radio-broadcast encryption is made of sterner stuff because the audience is limited, and thus you can use rotating one-time pads or some other computer security jargon that actually works, though it's still limited due to the high bandwidth giving plenty of plaintext to attack and vulnerabilities to exploit.

So all we need to do is explain that and we're fine... well, once we make the broadcast decryption rule follow every other rule in SR and have it use the player's skill (Electronic Warfare) rather than the gear rating.


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Mon Nov 30, 2009 9:24 am 
Offline
Forum Admin

Joined: Tue Jul 17, 2007 11:50 am
Posts: 827
Location: DeeCee
Are we not allowing matrix hosts to use 'rigger encryption' or vice versa?


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Mon Nov 30, 2009 8:31 pm 
Offline
Forum Admin

Joined: Wed Jul 18, 2007 3:11 am
Posts: 903
Well, matrix hosts really can't use rigger encryption because they're not ever going to be low-user; in the rare cases that they are (say a high-security low-volume datastore) then if it's encrypted in any meaningful way it's going to have "essentially unbreakable" encryption: something with either a physical component that you're going to have to steal (ID card/SR-equivalent of an RSA dongle), or a password that you're going to have to "coax" out of a person.

As for riggers "encrypting" like you see on a high-volume Matrix host... why? Who'd want to: Matrix "encryption" is a joke.


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Tue Dec 01, 2009 9:16 am 
Offline
Forum Admin

Joined: Tue Jul 17, 2007 11:50 am
Posts: 827
Location: DeeCee
Imagine I have a host with a constant datastream to a second host held by another corporation. Right there I have a perfect invitation to use rigger encryption. RSA dongles and passwords really don't apply to ongoing streams.

For the riggers, imagine I have one of those nice systems where the entire building is hooked up as a rigger 'vehicle'. It has, literally, hundreds of devices added to the periphery. The whole building is networked;, coffee makers, community fridges, lights, printers, the whole caboodle. And it needs to be such that Joe Worker can install his new printer without spending half an hour synchronizing security codes. In this case, a rigger using matrix encryption seems the best use of time and money.


Top
 Profile  
 
 Post subject: Re: Encryption
PostPosted: Fri Dec 04, 2009 12:43 am 
Offline
Forum Admin

Joined: Wed Jul 18, 2007 3:11 am
Posts: 903
Hm. Yeah, I guess I can see both of those examples. So, sure, why not let riggers have access to "crappy" encryption (Scramble IC) and let deckers have access to "good" encryption.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group