A lot of people are upset that encyption in SR is either trivially easy to crack, or the GM just declares that it's impossible, and there's basically nothing in between.
I suggest a slight deviation from the basic mechanic, and the streamlined system.
Are you ready:
An extended test with a variable interval. The first test takes 1 action. The second roll takes 1 turn. The third roll 1 minute. The fourth roll takes 1 hour. The fifth takes 1 day. And so on.
Now admittedly, the core mechanic does not allow varying the interval on an extended test, but I think it's a pretty minor change.
Is this a decent fix? Terrible idea?
I'd like some help figuring out how many steps there should be; how fast the intervals should increase. If they increase too quickly it'll take too long to break encryption, making the game too realistic and thus not fun. If they increase too slowly, then it only slows the problem down slightly but any punk can still break super-encryption in a short time.
Um, help? Thanks!
Full Version: Possible "fix" for SR encryption.
I have no idea how well it will work, but it's certainly not too complicated/doesn't deviate from the core mechanic too much. So I like it in that sense.
That's an interesting way to approach it, and it has it's merits.
But I'm going to have to reiterate, one more time
, my disagreement with 'a lot of people'. The answer is right there in the book. Limit the Extended Test rolls to 4 (or 3 if you want to tip it somewhat in favour of Encryption rather than Decryption) and you get a good spread of results of crackable/beyond your ability.
But I'm going to have to reiterate, one more time
, my disagreement with 'a lot of people'. The answer is right there in the book. Limit the Extended Test rolls to 4 (or 3 if you want to tip it somewhat in favour of Encryption rather than Decryption) and you get a good spread of results of crackable/beyond your ability.
the problem with that is the encrytpion system in SR4 is SUPPOSED to be insanely easy to crack.
Given how awful most people's selection of encryption keys/passwords that's not unreasonable as a general idea. Essentially you'd start with a fairly huge set of commonly used passphrases and variations on them and see if there is a match. That takes a fairly trivial amount of time if you understand the systems encryption.
Then you run a much larger set against it and see if it works, which takes some time. Then you get into brute force, which can take a very sort time or off into roughly infinity depending on how effective the keys are.
So you can typically expect to break into the average home router in a matter of a minute or less and you can expect to spend until the heat death of the universe trying to break the system used for controlling nuclear weapons. Unless you go and steal the keys, that is. This allows you to trust that an signed encrypted email from your fixer probably from who it says or from someone who has stolen his keys, not from Joe Random who cracked and forged messages to amuse himself.
The key to make this work in that game would be to make the encryption setting reflect not the program used to encrypt but the amount of care used in selecting, managing and changing keys. Effectively managing encryption is a lot of effort and in a significant sized organization doing it well is very expensive.
You'd probably need to play with the the way successes are generated by decryption vs encryption levels such that it produces an interesting set of effects, which I'm not sure they would do right now.
Then you run a much larger set against it and see if it works, which takes some time. Then you get into brute force, which can take a very sort time or off into roughly infinity depending on how effective the keys are.
So you can typically expect to break into the average home router in a matter of a minute or less and you can expect to spend until the heat death of the universe trying to break the system used for controlling nuclear weapons. Unless you go and steal the keys, that is. This allows you to trust that an signed encrypted email from your fixer probably from who it says or from someone who has stolen his keys, not from Joe Random who cracked and forged messages to amuse himself.
The key to make this work in that game would be to make the encryption setting reflect not the program used to encrypt but the amount of care used in selecting, managing and changing keys. Effectively managing encryption is a lot of effort and in a significant sized organization doing it well is very expensive.
You'd probably need to play with the the way successes are generated by decryption vs encryption levels such that it produces an interesting set of effects, which I'm not sure they would do right now.
| QUOTE (blakkie) |
| But I'm going to have to reiterate, one more time , my disagreement with 'a lot of people'. The answer is right there in the book. Limit the Extended Test rolls to 4 (or 3 if you want to tip it somewhat in favour of Encryption rather than Decryption) and you get a good spread of results of crackable/beyond your ability. |
Fair enough, I'm using subjective terms again, with no polls to back me up.
Even with that rule, though, it means all encryption is either broken in under 12 seconds or not at all. That bothers me. Maybe it's just me, though.
And yes, breaking encryption is supposed to be easy in SR4. Good encryption makes hacking not fun. This solution would make tricky encryption actually take a little bit of time, but still allow a great hacker with good programs and a good roll to blow past simple encryption in one action.
I still think it's a neat idea.
| QUOTE (Moon-Hawk @ Dec 12 2006, 03:05 PM) |
| Even with that rule, though, it means all encryption is either broken in under 12 seconds or not at all. That bothers me. Maybe it's just me, though. |
I think that's the merit your approach has. Even though pretty much everything is crackable within a month, it makes it extremely difficult to crack during most SR combat. You basically get 2 rolls or it isn't going to happen. Although in truth using standard rules, and the speed at which most SR combat occurs, most times you'll not see any more than 2 rolls anyway. And once you get to 1 day per roll that's really the outer limit of timeframes that characters operate in SR. YMMV of course. *shrug*
EDIT: BTW I'd like to reserve the right to yoink that idea and use it.
I'm going to think about it a while. It isn't that the rules as they are suck so much as I think that is a pretty neat idea and might represent somewhat of an improvement.
With the schedule I have laid out in the first post, it means a super-great hacker with awesome programs will beat the best encryption in about a minute, or an hour at least 80% of the time, without using edge.
Someone with ratings of 3 in everything relevant would usually run up against the extended test limit and never make it, if you're using them, or very likely take at least a month if you're letting them roll as many times as they want, but could typically make it past rating 3 encryption in the 1 minute to 1 hour range as well. Again, without edge.
Hmmm, I don't know. I know encryption is supposed to be weak in SR4, but I wish it could be a problem, instead of an annoying speed bump that tends to feel like an unneccessary roll that just wastes time.
Someone with ratings of 3 in everything relevant would usually run up against the extended test limit and never make it, if you're using them, or very likely take at least a month if you're letting them roll as many times as they want, but could typically make it past rating 3 encryption in the 1 minute to 1 hour range as well. Again, without edge.
Hmmm, I don't know. I know encryption is supposed to be weak in SR4, but I wish it could be a problem, instead of an annoying speed bump that tends to feel like an unneccessary roll that just wastes time.
But do you consider that each data is encrypted with the same encryption ?
For example, I'm communicating with my teammate through an encrypted channel. A hacker is trying to decrypt our messages.
I speak for 3 seconds. The hacker gets the data, and spends 3 seconds decrypting it. My teammate answers. Is it the same encryption method ?
If it's not, the hacker will be able to decrypt each message, with some latency between the message and his getting it.
For verbal communications, it isn't that much of a problem. But it becomes more interesting when interacting with drones. If you can't decrypt the signal quickly enough, you won't be able to alter it (rules state that you have to decrypt the signal before being able to do anything on it).
Encryption isn't exactly supposed to be weak. It's supposed to add some exciting elements. The hacker has to be able to decrypt some communications while not being able to decrypt something very important too quickly. It should also be possible that the hacker ends up being unable to decrypt a very important communication. Problem is, you have to find a rule that covers all these events without making it look like "GM doesn't want the code to be broken".
For example, I'm communicating with my teammate through an encrypted channel. A hacker is trying to decrypt our messages.
I speak for 3 seconds. The hacker gets the data, and spends 3 seconds decrypting it. My teammate answers. Is it the same encryption method ?
If it's not, the hacker will be able to decrypt each message, with some latency between the message and his getting it.
For verbal communications, it isn't that much of a problem. But it becomes more interesting when interacting with drones. If you can't decrypt the signal quickly enough, you won't be able to alter it (rules state that you have to decrypt the signal before being able to do anything on it).
Encryption isn't exactly supposed to be weak. It's supposed to add some exciting elements. The hacker has to be able to decrypt some communications while not being able to decrypt something very important too quickly. It should also be possible that the hacker ends up being unable to decrypt a very important communication. Problem is, you have to find a rule that covers all these events without making it look like "GM doesn't want the code to be broken".
Well in order to change the encryption we'd have to broadcast the codes, which would defeat the purpose. So yeah, I'd assume successive commands are all using the same encryption, same as now.
Now, if you run into a team on one day and sample their communication and break it, then find them again the next day, it might not be the same anymore.
Now, if you run into a team on one day and sample their communication and break it, then find them again the next day, it might not be the same anymore.
| QUOTE (Moon-Hawk) |
| Well in order to change the encryption we'd have to broadcast the codes, which would defeat the purpose. So yeah, I'd assume successive commands are all using the same encryption, same as now. Now, if you run into a team on one day and sample their communication and break it, then find them again the next day, it might not be the same anymore. |
you have 12 encryption commands, and your team sends an RFID code along with their signal your system recognizes the code and initiates the command. in order to get all your teamates eavesdropping he'd have to decrypt each of your signals however only once per signal.
and yes on a different day he'd have to make a decryption attempt again.
But you can have a series of codes, defined prior to the encryption (a bit like one-time pads). This way, when you register to your online store, you are asked to connect through a secure connection (ie. a cable connecting directly to a terminal in a physical store) and your commlink exchanges encryption keys with the store node.
Then, each time you purchase something on an online store, you use different keys fo each data packet. When you arrive at the end of the list, you are asked to register once again through a secure connection to ensure maximum security.
If you apply this idea to team/drone communication, you can end up with a system that forces hacker to spend more time decrypting the signal (basically waiting for the same key to be used several times to have enough material to perform decryption).
The problem is that, due to the absence of storage limit, nothing prevents user from having insanely long key list to prevent the same key being used twice and that may lead to undecryptable systems...
Then, each time you purchase something on an online store, you use different keys fo each data packet. When you arrive at the end of the list, you are asked to register once again through a secure connection to ensure maximum security.
If you apply this idea to team/drone communication, you can end up with a system that forces hacker to spend more time decrypting the signal (basically waiting for the same key to be used several times to have enough material to perform decryption).
The problem is that, due to the absence of storage limit, nothing prevents user from having insanely long key list to prevent the same key being used twice and that may lead to undecryptable systems...
| QUOTE (Moon-Hawk) |
| Well in order to change the encryption we'd have to broadcast the codes, which would defeat the purpose. |
That's why smart people invented asymmetric encryption... for key distribution.
You could always use the cheezeezee way of encryption outlined in On the Run...
Use 30-year-old double-encryption technology. Find someone who sells 30-year-old communication cyber. Double-encrypt it such that if you remove one layer through a brute-force attack, the other is rendered so meaningless that not even the original code will decrypt it....
Yeah, it's bullsh, but I figure if the DM can do it, so can the players.
Use 30-year-old double-encryption technology. Find someone who sells 30-year-old communication cyber. Double-encrypt it such that if you remove one layer through a brute-force attack, the other is rendered so meaningless that not even the original code will decrypt it....
Yeah, it's bullsh, but I figure if the DM can do it, so can the players.
| QUOTE (Blade) |
| The problem is that, due to the absence of storage limit, nothing prevents user from having insanely long key list to prevent the same key being used twice and that may lead to undecryptable systems... |
To a large extent, if someone is willing to spend lots of thought and effort on encrypting their traffic it is undecipherable. Unless there is a flaw in the algorithm (very unlikely), a program flaw (possible), or poorly chosen keys you are not going to be able to decrypt it in a rational amount of time.
| QUOTE (kzt) |
| To a large extent, if someone is willing to spend lots of thought and effort on encrypting their traffic it is undecipherable. Unless there is a flaw in the algorithm (very unlikely), a program flaw (possible), or poorly chosen keys you are not going to be able to decrypt it in a rational amount of time. |
Heh, yeah. But where's the fun in that?
| QUOTE (eidolon) | ||
Heh, yeah. But where's the fun in that? |
Currently the system is set up in a way that would be clearly silly if used in another fashion. Consider how SR4 would work if anyone could unlock any door in 12 seconds. Storage shed or bank vault, all in 12 seconds or less.
Would that add any challenge or fun to the game?
| QUOTE (Moon-Hawk @ Dec 12 2006, 03:31 PM) |
| Hmmm, I don't know. I know encryption is supposed to be weak in SR4, but I wish it could be a problem, instead of an annoying speed bump that tends to feel like an unneccessary roll that just wastes time. |
Whether it takes 1 Combat Turn or 2 can make a difference sometimes. However most of the time Data Bombs are the real obstacles in the Matrix, and IMO far better devices for an engaging game. Data Bombs have risks with failure other than you just don't get in, and they use Opposed Tests which tend to give better results than fixed Thresholds which in turn are a step above Extended Tests.
| QUOTE (kzt) | ||||
Currently the system is set up in a way that would be clearly silly if used in another fashion. Consider how SR4 would work if anyone could unlock any door in 12 seconds. Storage shed or bank vault, all in 12 seconds or less. Would that add any challenge or fun to the game? |
About as much fun as if hacking were impossible in any amount of time that would plausibly fit into most 'runs.
I like the approach.
Though the numbers could be tweaked . . .
But it is also very practical to do the following:
- threshold to crack encryption is 4xrating
- interval for streamed data is 1 minute
- interval for persistent data is 1 hour (or 1 day if you like)
- limited to "electronic warfare skill +1 (or decryption program rating +1)" rolls
Does the job quite well.
Ther general problem every optional decryption rule in SR4 has: its response+decryption, so you could always just just 10 comlinks . . . So I would make it electronic warfare + decryption or even logic + electronic warfare limited by decryption.
Maybe unrealistic, but does the job.
Though the numbers could be tweaked . . .
But it is also very practical to do the following:
- threshold to crack encryption is 4xrating
- interval for streamed data is 1 minute
- interval for persistent data is 1 hour (or 1 day if you like)
- limited to "electronic warfare skill +1 (or decryption program rating +1)" rolls
Does the job quite well.
Ther general problem every optional decryption rule in SR4 has: its response+decryption, so you could always just just 10 comlinks . . . So I would make it electronic warfare + decryption or even logic + electronic warfare limited by decryption.
Maybe unrealistic, but does the job.
Moon-Hawk
| QUOTE |
| An extended test with a variable interval. The first test takes 1 action. The second roll takes 1 turn. The third roll 1 minute. The fourth roll takes 1 hour. The fifth takes 1 day. And so on. |
Why did you tie the intereval to the number of tests as opposed to the encryption rating, for example?
[edit] also I was going to ask; If they prove the twin prime conjecture won't that make busting encryption something like twice as fast in RL?
| QUOTE (djinni) |
| the problem with that is the encrytpion system in SR4 is SUPPOSED to be insanely easy to crack. |
However, there are some elements of the SR4 setting, like the near total use of electronic fund transfers for the monetary system, that just could not exist as presented if all encryption were insanely easy to crack. Short of arbitrarily giving certain types of encryption plot armor just because the setting wouldn't work otherwise, the only solution is houserule up a set of encryption rules that are fun and playable that still allow for tough to break encryption on the high end.
Besides, Technomancers were given encryption that isn't "insanely easy to crack" in the form of the sprite power Hash (only way to crack it is to be a TM yourself, spoof the sprite into thinking you're the TM who compiled it, and have it stop using the Hash power) and SR4 didn't fall apart from that.
thats because big mama corp do not have a TM on life support hooked up to their networks, running hash sprites on every bit of data available...
Okay I have a few ideas to throw in here.
First off lets start with decryption tests being threshold tests vs the encryption level + other difficulties. Not an extended test. You could make a test every interval but it is success or failure. That way it will not necessarily always be solved.
Other difficulties could be making the correct assumption on what language is being used. If you tell a computer that you are decrypting Japanese but really it is Swidish then it will make things more difficult.
You could increase it based on being encrypted multiple times and such. It could be more difficult if it has a changing key, etc.
Now the threshold that you end up generating could determine the interval for tests.
Finally you can make it where a decrypt must be equal to or higher level then the encrypt to do it in a combat time scale. Other wise it goes much higher in the time scale based on that difference.
Basically think in terms of that movie Sneakers about a math formula that allows you to break high level encryption because of the laws of math. Add in the program noticing which encryption program was used and exploiting known patterns that it uses.
Then the roll would be versus this threshold and not against any kind of successes from an encryption roll.
First off lets start with decryption tests being threshold tests vs the encryption level + other difficulties. Not an extended test. You could make a test every interval but it is success or failure. That way it will not necessarily always be solved.
Other difficulties could be making the correct assumption on what language is being used. If you tell a computer that you are decrypting Japanese but really it is Swidish then it will make things more difficult.
You could increase it based on being encrypted multiple times and such. It could be more difficult if it has a changing key, etc.
Now the threshold that you end up generating could determine the interval for tests.
Finally you can make it where a decrypt must be equal to or higher level then the encrypt to do it in a combat time scale. Other wise it goes much higher in the time scale based on that difference.
Basically think in terms of that movie Sneakers about a math formula that allows you to break high level encryption because of the laws of math. Add in the program noticing which encryption program was used and exploiting known patterns that it uses.
Then the roll would be versus this threshold and not against any kind of successes from an encryption roll.
Consider this:
-breaking signal encryption is a single test with threshold=rating (1 complex action)
-breaking data encryption is also a single test, but has an interval based on password type and parts of the needed code
Advantage:
-easy
-enables using the search for parts of a passcode (ie images) as plot device
-gives different types of passcode meaning
Which interval times would be good? High-end passcodes should take a few weeks if no extra help is present.
-breaking signal encryption is a single test with threshold=rating (1 complex action)
-breaking data encryption is also a single test, but has an interval based on password type and parts of the needed code
Advantage:
-easy
-enables using the search for parts of a passcode (ie images) as plot device
-gives different types of passcode meaning
Which interval times would be good? High-end passcodes should take a few weeks if no extra help is present.
| QUOTE (OneTrikPony) | ||
Moon-Hawk
Why did you tie the intereval to the number of tests as opposed to the encryption rating, for example? [edit] also I was going to ask; If they prove the twin prime conjecture won't that make busting encryption something like twice as fast in RL? |
OOh, lots of good stuff here, but to answer the question that was pointed directly at me:
I did it this way so that a good decker rolling well can still get through decent encryption very, very quickly (just like now), and in fact any encryption can be broken in one action with sufficiently good rolls. If you were to make the interval, say 1 hour for rating 6 encryption, then anyone with rating 6 encryption knows that they are 100% immune to hacking, at least for an hour. And that's no fun.
I was looking for a way for good hackers vs weak encryption to obliterate it just like now, because that's consistent with the feel of SR encryption, realism be damned. Comparable levels of hacker vs. encryption will take in the 1 minute to 1 hour range, so it's more than just a stupid extra roll, but it is still very surmountable, but a weak hacker against strong encryption just takes too damn long, so there's a real point in using it, without making it too strong that it breaks the game.
Plus, I was trying to come up with something that doesn't involve the GM saying "this is secret GM double-good encryption, so the interval is I-win", it's just rating 6, and you can beat it in one action if the dice gods love you.
But as I admitted in my first post, the intervals probably need some tweaking.
| QUOTE (OneTrikPony) |
| [edit] also I was going to ask; If they prove the twin prime conjecture won't that make busting encryption something like twice as fast in RL? |
If quantum computers actually work in a useful way (2 bits isn't useful) you destroy some forms of public key systems, as they become trivial. Symetric key systems don't become twice as fast, they cut the keyspace in half. So a 256 bit key effectively becomes a 128 bit key. Which changes the mean time for solution from after the heat death of the universe to only a few million years if you are using a huge amount of super optimized hardware.
My GM is using the following changes.
Limit of Electronic Warefare in rolls
Threshold of Rating x3 (potentially x2+3 but i think we are sticking with 3)
Some time increase that I dont remember
Its making it harder but not impossible. I'm playing a technomancer and threading gives me a large advantage on this already.
Limit of Electronic Warefare in rolls
Threshold of Rating x3 (potentially x2+3 but i think we are sticking with 3)
Some time increase that I dont remember
Its making it harder but not impossible. I'm playing a technomancer and threading gives me a large advantage on this already.
I like a lot of the thoughts in this thread...
I really like the OPs idea of the increased time per attempt... what this represents in my mind is that if they are using common / easy to break crypto (like WEP) and you've got the software / exploits to break it... poof, broken. (a good roll vs a weak encryption during combat)
Then, if they have slightly better encryption, perhaps you get it that next go-around (or just get lucky vs slightly better / unlucky vs the crappy stuff).
And it scales up from there...
This solves the problems with that stupid encryption from on the run where players aren't allowed to break the 2nd level of the encryption... and puts a reason why.
You could combine the levels together (adding difficulty to the 2nd layer from the first) and they will either hit their max amount of attempts due to their skill cap or give up due to the time involved at 1 day per attempt at that point.... either way it keeps the plot moving without having to "cheat" as a GM.
Even at the day per check though, it does show that eventually all encryption can be broken (which is very true)... you just have to put in the time / resources.
I really like the OPs idea of the increased time per attempt... what this represents in my mind is that if they are using common / easy to break crypto (like WEP) and you've got the software / exploits to break it... poof, broken. (a good roll vs a weak encryption during combat)
Then, if they have slightly better encryption, perhaps you get it that next go-around (or just get lucky vs slightly better / unlucky vs the crappy stuff).
And it scales up from there...
This solves the problems with that stupid encryption from on the run where players aren't allowed to break the 2nd level of the encryption... and puts a reason why.
You could combine the levels together (adding difficulty to the 2nd layer from the first) and they will either hit their max amount of attempts due to their skill cap or give up due to the time involved at 1 day per attempt at that point.... either way it keeps the plot moving without having to "cheat" as a GM.
Even at the day per check though, it does show that eventually all encryption can be broken (which is very true)... you just have to put in the time / resources.
Basically, however you set the intervals, with all ratings/skills equal you can expect the encryption to be broken on the 3rd roll, and broken on or before the 4th roll ~80% of the time. This is true for response/decrypt/encrypt of 1, or response/decrypt/encrypt of 7, and anything in between, as long as they're evenly matched.
I placed my 3rd roll at 1 minute and my 4th at 1 hour, but adjust these however you need to so that encryption is as breakable as you want it to be, and mismatched levels of hacker vs. encryption will make it trivial or secure, as you wish. I thought 1 minute to 1 hour was pretty good for what I perceive the feel of SR encryption was supposed to be, but YMMV.
I placed my 3rd roll at 1 minute and my 4th at 1 hour, but adjust these however you need to so that encryption is as breakable as you want it to be, and mismatched levels of hacker vs. encryption will make it trivial or secure, as you wish. I thought 1 minute to 1 hour was pretty good for what I perceive the feel of SR encryption was supposed to be, but YMMV.
If you want to be more precise, you can use different values/rules for :
- encrpyted files
- encrypted secure communication (between two devices that are configured to exchange encrypted data (with keys exchanged before the communication), for example between your commlink and your bank)
- encrypted standard communication
- encrypted nodes
Why bother with this ? Because sometimes it's more thrilling if you have to wait some minutes/hours/days before decrypting a message (and you don't have to decrypt it on the fly), because a hacker should be able to hack an encrypted message from someone to one of his friends without too much trouble but shouldn't be able to decrypt secure payment data that easily.
It might not be easy to find a streamlined way to do this, but I'll think about it.
- encrpyted files
- encrypted secure communication (between two devices that are configured to exchange encrypted data (with keys exchanged before the communication), for example between your commlink and your bank)
- encrypted standard communication
- encrypted nodes
Why bother with this ? Because sometimes it's more thrilling if you have to wait some minutes/hours/days before decrypting a message (and you don't have to decrypt it on the fly), because a hacker should be able to hack an encrypted message from someone to one of his friends without too much trouble but shouldn't be able to decrypt secure payment data that easily.
It might not be easy to find a streamlined way to do this, but I'll think about it.
True. Also, you could use the above system (possibly with an adjusted scale) and just give constant threshold modifiers based on the type of thing encrypted.
i.e. Standard encrypted communication -1 Threshold
Files +1 Threshold
Nodes +2 Threshold
i.e. Standard encrypted communication -1 Threshold
Files +1 Threshold
Nodes +2 Threshold
Yes, except that I'll give lower modifier for nodes, as node decryption should slow down the hacker. If it takes 3 days to break it, you can forget about hacking nodes on the fly (and that's no fun 
)
You could also have modifiers based on the available data :
i.e. (values are arbitrary)
* you know some elements encrypted in the files : up to +4 (depends on the amount of data you know)
* multiple files/data stream encrypted with the same encryption : +1 per file/stream
* especially short file/stream : -4
and so on...
)You could also have modifiers based on the available data :
i.e. (values are arbitrary)
* you know some elements encrypted in the files : up to +4 (depends on the amount of data you know)
* multiple files/data stream encrypted with the same encryption : +1 per file/stream
* especially short file/stream : -4
and so on...
Sure.
Yeah, good point about node decryption. I was just pulling numbers out of my arse without thinking about them.
Yeah, good point about node decryption. I was just pulling numbers out of my arse without thinking about them.
So, here is a calculation for SGM 1.0
Axioms:
- threshold for breaking encryption is 4 x rating
- logic + electronic warfare limited by decrypt is used
- hits beyond decryption are halved (round up)
- limit of skill +1 rolls for extended tests
We have the:
- (A) corporate joe hacker: Logic 4(5), electronic warfare 3, decrypt 6, cold VR: 8 dice (2.66 hits)
- (B) standard runner hacker Logic 5(7), electronic warfare 4, decrypt 6, hot VR: 13 dice (4.33 hits)
- © 1337 h4Xx0r Logic 6(9), electronic warfare 6, decrypt 6, hot VR: 17 dice (5.66 hits, 5.33 hits due to cap effects, estimated)
in addition we have the implant X, which gives you 1 extra hit per test which is not capped.
Aims:
- decrypting should be not impossible, but sometimes (when not using edge for example) fail
- decrypting traffic should take much less time than decrypting static data
acceptable times for decrypting traffic: 1-5 minutes
acceptable times for decrypting static traffic: 1-5 days
proposed intervalls (number of intervalls till next):
pass (4)
turn (5)
15 seconds (4)
minute (10)
10 minutes (6)
hour (6)
6 hours (4)
day (7)
week (4)
month (12)
year
traffic starts at "pass" - 4 tries before unacceptability
static starts at "minute" - 5 tries before unacceptability
Rating 3 encryption averages(threshold 12):
A - traffic: fails (not enough rolls) 60% of the time
B - traffic: 15 seconds
C - traffic: 3 seconds
A - static: fails (not enough rolls) 60% of the time
B - static: 1 hour
C - static: 10 minutes
Rating 5 encryption averages(threshold 20):
A - traffic: fails (not enough rolls) 99%% of the time
B - traffic: 10 minutes
C - traffic: 1 minute
A - static: fails (not enough rolls) 99%
B - static: 1 day
C - static: 6 hours
Rating 6 encryption averages (threshold 24):
A - traffic: fails (not enough rolls) 100%
B - traffic: fails (not enough rolls) 55% of the time
C - traffic: 1 minute (45% 10 minutes)
A - static: fails (not enough rolls)
B - static: fails (not enough rolls) 55% of the time
C - static: 6 hours (45% 1 day)
With implant X:
Rating 5 encryption averages (threshold 20):
A - traffic: fails (not enough rolls) 80%% of the time
B - traffic: 1 minute
C - traffic: 15 seconds
A - static: fails (not enough rolls) 80%
B - static: 6 hours
C - static: 1 hour
Rating 6 encryption averages (threshold 24):
A - traffic: fails (not enough rolls) 99% of the time
B - traffic: 1 minute (45% 10 minutes)
C - traffic: 1 minute
A - static: fails (not enough rolls) 99% of the time
B - static: 6 hours (45% 1 day)
C - static: 6 hours
Comments, Ideas?
Axioms:
- threshold for breaking encryption is 4 x rating
- logic + electronic warfare limited by decrypt is used
- hits beyond decryption are halved (round up)
- limit of skill +1 rolls for extended tests
We have the:
- (A) corporate joe hacker: Logic 4(5), electronic warfare 3, decrypt 6, cold VR: 8 dice (2.66 hits)
- (B) standard runner hacker Logic 5(7), electronic warfare 4, decrypt 6, hot VR: 13 dice (4.33 hits)
- © 1337 h4Xx0r Logic 6(9), electronic warfare 6, decrypt 6, hot VR: 17 dice (5.66 hits, 5.33 hits due to cap effects, estimated)
in addition we have the implant X, which gives you 1 extra hit per test which is not capped.
Aims:
- decrypting should be not impossible, but sometimes (when not using edge for example) fail
- decrypting traffic should take much less time than decrypting static data
acceptable times for decrypting traffic: 1-5 minutes
acceptable times for decrypting static traffic: 1-5 days
proposed intervalls (number of intervalls till next):
pass (4)
turn (5)
15 seconds (4)
minute (10)
10 minutes (6)
hour (6)
6 hours (4)
day (7)
week (4)
month (12)
year
traffic starts at "pass" - 4 tries before unacceptability
static starts at "minute" - 5 tries before unacceptability
Rating 3 encryption averages(threshold 12):
A - traffic: fails (not enough rolls) 60% of the time
B - traffic: 15 seconds
C - traffic: 3 seconds
A - static: fails (not enough rolls) 60% of the time
B - static: 1 hour
C - static: 10 minutes
Rating 5 encryption averages(threshold 20):
A - traffic: fails (not enough rolls) 99%% of the time
B - traffic: 10 minutes
C - traffic: 1 minute
A - static: fails (not enough rolls) 99%
B - static: 1 day
C - static: 6 hours
Rating 6 encryption averages (threshold 24):
A - traffic: fails (not enough rolls) 100%
B - traffic: fails (not enough rolls) 55% of the time
C - traffic: 1 minute (45% 10 minutes)
A - static: fails (not enough rolls)
B - static: fails (not enough rolls) 55% of the time
C - static: 6 hours (45% 1 day)
With implant X:
Rating 5 encryption averages (threshold 20):
A - traffic: fails (not enough rolls) 80%% of the time
B - traffic: 1 minute
C - traffic: 15 seconds
A - static: fails (not enough rolls) 80%
B - static: 6 hours
C - static: 1 hour
Rating 6 encryption averages (threshold 24):
A - traffic: fails (not enough rolls) 99% of the time
B - traffic: 1 minute (45% 10 minutes)
C - traffic: 1 minute
A - static: fails (not enough rolls) 99% of the time
B - static: 6 hours (45% 1 day)
C - static: 6 hours
Comments, Ideas?
How do you consider node encryption ? I guess it's traffic (hacking on the fly wouldn't be possible otherwise).
I think that it's a bit to hard to decrypt. Corporate Joe Hacker should be able to decrypt average encryption (rating 3) more easily and should be able to break rating 5 encryption (even if it's harder)... Someone with 8 dices is quite skilled. Maybe encryption rating * 3 threshold would be better.
I'd also consider adding threshold modifiers as I proposed in this topic.
Apart from that, I like it.
I think that it's a bit to hard to decrypt. Corporate Joe Hacker should be able to decrypt average encryption (rating 3) more easily and should be able to break rating 5 encryption (even if it's harder)... Someone with 8 dices is quite skilled. Maybe encryption rating * 3 threshold would be better.
I'd also consider adding threshold modifiers as I proposed in this topic.
Apart from that, I like it.
in my SGM I rule: Nodes can not be encrypted, only data can be encrypted.
Furthermore: if you let Joe Corporatehacker hack Rating 5, then we are back to RAW where everything is easily hackable.
Furthermore: if you let Joe Corporatehacker hack Rating 5, then we are back to RAW where everything is easily hackable.
Too bad, I like the idea of encryptable nodes that slow down the hacker.
I just want to let Joe Corporate Hacker have a chance at hacking rating 5 encryption (even if it's just 25%)... But that could be done, if Joe goes for HotSim and if you add some of the modifiers I talked about...
I just want to let Joe Corporate Hacker have a chance at hacking rating 5 encryption (even if it's just 25%)... But that could be done, if Joe goes for HotSim and if you add some of the modifiers I talked about...
I dont think that hacking is too fast. Its more the opposite.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.