I've been mulling over both the general rules for extended tests, and things like Encryption on your files.

How would someone set up a failsafe on encrypted files to prevent the 'well gee I have nearly forever to try and break this' situation. Could you as the owner/programmer/hacker of the encrypted files set up a sorta secondary threshhold on the files? Guidelines in the book talk about you can get "dice pool" number of chances to succeed at the given task. But for general encrypted files, I figure rating 5 and 6 will be the maxes, setting threshold at 10 to 12. That still makes it highly likely the general hacker is going to bust it.

Would you be able to program it so if they don't get it in say, 2 or 3 tries, the prog crashes? Or would that sorta be a linked databomb? Set to go off if decryption is failed 2 or 3 times, but also set up that the databomb cannot be defused UNTIL the encryption is beaten?

I apologize if this seems rather simple to some, I've never played a hacker type in game before, yet my impressions of SR4 so far is you sorta need to be one at least to a little degree (in addition to having really skilled hacker contacts otherwise) to protect yourself.

I usually run with the system make regular sweeps to try and spot hackers. If an alarm is on I have the system start to spawn IC/call in sec hackers. If Ic crashes the system reloads it and it comes at you again. Hmm that security tactic will make Tarpit type programs handy...

Also, my intent was towards securing (hopefully) data that remained secure even when you didn't have to worry about fending off IC or security hackers. Like the paydata you might retrieve that the Johnson doesn't want you to fart around with while waiting in your safehouse as you organize a safe drop.

What sorta rating should/would an encryption program that adapts have? If you don't wanna have a databomb nuke the data itself, rather an encryption prog that resets and changes form if someone fails to decrypt it after a set # of times? So in the example I'm thinking, if you don't get it in 2 or 3 attempts, you have to start all over again.

Another thing you might consider that I've been thinking about is to increase the threshold by a certain amount every time the roll is made. For just those situations when persistence shouldn't be good enough to solve the problem. I like that solution more than capping the number of rolls, personally. The downside is that there isn't much room to play with the number here, as once you start adding 3 or more to the threshold every roll, you're pretty much making the action impossible.

hmm, kinda like a encryption that reencrypts with a new key pr x number of times the file is read/accessed?

Decryption interval is 1 combat turn, you could bump this into the hours or days category, basically set an interval where there simply isn't the time to to decrypt before you have to turn it over, or you will decrypt it after it is far too late.

The problem I see with encryption that re-encrypts itself when it fails is that
A) Breaking the new encryption is no more difficult than breaking the old encryption
and B) the actuall owner of the file wouldn't have the new randomly generated key... so it would be making the file (theoretically) unaccessable to him when he receives it.

If he *did* set it up so that one key could decrypt any of the encryptions it might have done... then decrypting it (no matter how many times it has reset itself) is basically the task of breaking one encryption (finding that key).

IMHO, the decryption interval needs to be larger, and the # of attempts either needs to be capped, or have the threshholds increase. Either way, once the threshholds reach the size of your dice pool, you're done. Thsoe rules also keep peopel from defaulting to logic, and using a rating 1 decryption program to eventually decrypt anything in the universe in about an hour.

You already cant break encryption buy defaulting to logic with rating one encryption, every time you glitch the threshold goes up. With such a small dice pool you will glitch so often you will be getting further from success with every roll.

You probably need a dice pool of about 4 to expect to succeed eventually.

It really is a bit of a problem, any competent hacker (or for that matter script kiddie with a dice poop of 4 or 5) will defiantly be able to crack any encryption you care to create within the attention span of the average 5 year old. At this point as I would probably not bother with encryption, all it dose is point out the files I care about.

Edward

One way would be to have a rolling encryption key. Every so often the file encryption is changed, and those that encrypted it will have a similar rolling key on a separate device. Several government and private agencies have this type of system for passwords now. Those that need access have an account and receive a credit card sized password generator. By combining what is displayed on the card (which cycles every 90 seconds or so) with their chosen password, they have the full password to access their account on the system.

If you have a node running they encryption program, it could perform the rolling encryption every 3 combat rounds for all files it has control of, forcing a hacker to restart his extended test. The only way to avoid that would be to get ahold of someone's key card that has access to what you want. That way, you would have the rolling portion and only have to figure out the fixed part through decryption, allowing the extended test to continue uninterrupted.

Also, don't forget about glitching and critical glitches. Any time they glitch, give the system a perception test to notice them, and if you want to be hard on them, give the system a cumulative bonus (+1 die per glitch), or really difficult, make it an extended test for the system for glitches in the same extended test. If they glitch 3 times with a stealth of 5 while trying to decrypt a file, that would give the system 3 tries to total 5 hits to notice them and set off an alert.

You could also nest encryption, having 2 or 3 layers for extending protection, though that wouldn't a whole lot. You could require an external key, like a dongle, or biometric data to decrypt without an alarm going off. You just encode something like a databomb, but instead of doing damage, it challenges your right to access the file when decrypted.

Say you have node verify proper biometric data or the presence of a key when a file is decrypted, and if there is a problem an alert is set off. If the hacker doesn't know about it before hand, he gets caught. If he or she does know, they can attempt to fake the data and spoof the datatrail to make it look like it is from the correct source.

If they just copy and run, and then try to open it up on their system, you can have the file set to send out a signal to its proper host, signaling that it has been decrypted and allowing the host to attempt a trace if the hacker accessing the file on a networked system.

There have been a few past discussions around Encryption in the past. Use the Search function, I don't feel like posting links today.

But, as I was analysing the problem myself and looking at possible solutions, limiting the number of tries to a static 4 times is the best option, statistically speaking (again, you want it laid out, use the Search funtion).

Thus limiting the dice pool, even to an static 4 times, is within the rules, as the book says the GM may lmit the number of tries to his or her discretion.

At some point the Johnson just has to trust the runners he hired not to snoop. Or arrange to have them killed before they can talk. No need to invent new rules.

The jonson may trust the runners not to snoop all he wants, but he wasn’t the one that encrypted the file anyway.

Looking from eth POV of the security hacker for the corporation being stolen from you may as well not bother with encryption, once somebody has unauthorised access to the file they will easily decrypt it.

Edward

So would it be better to use encryption to..I dunno mask the 'name' of the file so you have to decrypt the name to see if its the thing you're looking for? Sounds like databombing a standalone file, (something intended for courier transport, etc) would be better than encrypting it, as even with a 4 cap or so on extended tests for something encrypted means your generic hacker is going to crack it.

Course, then it would make sense for someone to always check for a databomb, cause that'd be one of the only worthwhile defenses to put on a file

Just link the databomb to everything - and encrypt everything too. Hey, they tell you to back-up every three months...

But a J wanting to hide data should just put the chip inside a "priceless heirloom" and tell the runners to deliver that. Or have the data in the suitcase/handcuffs, not in the commlink secured inside.

unless its a "one of a kind" info, the encryption could be buildt so that unless you get it within x attempts, it selfdestructs or something.

still, having a hotwired repeating databomb on it could make things interesting to. for each attempt at decrypting, you get to resist an attack from the databomb. and if your persona crashes, you have to start over from scratch.

I'm wondering, is encryption a useful buffer tool you could use in order to make a hacker spend more time while you're trying to do something like say, shutdown/reset the system?

I believe it mentions that you can encrypt everything, or selection of things, with a simple action. Would it be a valid delaying tactic for a security decker if they fear the system is about to get taken? Encrypt everything, files, devices, whatever and hopefully make the intruder spend more time analyzing/decrypting stuff as you initiate a shutdown or something?