One little sentence on 225

"Note that some encryption schemes may incorporate IC
as a second line of defense."

So that's massive. Maybe. What the heck does that mean? This seems to apply to files and communications from how the paragraph is phrased.

Personally I consider that IC with whatever programs it's supposed to have count as running on the system doing the encryption during communication or the encryption process. Essentially the IC is loading itself along with traps into the file or communication packet, and kind of acting a bit like a data bomb.

Whenever someone tries to decrypt the file I give the IC a matrix perception test to detect them. If it succeds I consider decrypt program to have triggered some trap and the IC activates wherever the decryption is taking place, likely sending communications to it's owner if possible and generally causing havok with whatever programs it has loaded.

However what do the rest of you do? I like the basic idea as it makes encryption worth something without making decryption take forever. So the hacker can still hack on the fly, but there is a risk.

It might just mean that after decrypting the file/node/communication you may have to face an agent that'll check if you're really authorized to access the data.

I usually either rule that or, slightly differently, I've said that if (when) the decrypt is successful, then the trap is sprung. Perhaps the IC is not given the encryption key for a file but it constantly tries to read it. If another person comes around and decrypts it, then the IC can suddenly understand the file and begins to deal with that problem as instructed.

Not specifically appropriate for communications as such IC would have to tap into the encrypted communication between the attacker and the source, but it works for files. Plus, you don't have to worry, really, about the IC succeeding in an perception test because it should be trivial for the IC to compare the current file with the one that it checked last time to find that
they're different.

That being said, I'm not sure the sentence quoted above specifically means that IC has to be triggered when dealing with encryption/decryption just that some systems will use both IC and encryption to secure said systems. Those two security measures need not interact to make the sentence valid.

I haven't ruled on this yet in my games, but I would likely just make it a triggered event. If the decrypt glitched or was unsuccessful, you would have an IC in your home node attacking you...no perception needed, just the attack begins.

The hacker is either going to know they need to do something extra during the decrypt, or it will completely catch them off guard...

Well the reason that it's confusing is that one sentence is the only reference we have until Unwired, but yeah, personally I treat it as meaning that you activate the IC by decrypting the file, which means that if you aren't an authorized user or aware of the scheme you are likely going to be caught off guard.

I don't know about the IC automatically launching. Could lead to IC fights nearly every hack. And that would slow the game down.

And glitches are just so rare it makes it nearly pointless, and depending on the GM failing to decrypt something may be practically impossible unless you really suck.

Automatic IC attack is a dangerous way to go, even the legitimate user can type in the wrong password to decrypt the file. Even if the password is stored in a file, entered with a physical key, smartcard or any kind of input method, there's a possibility that there will be an error even if the user is legitimate.

So it's possible to have the system send an IC to investigate when decryption fails, but this IC will first analyze what's happening rather than attack right away.

Once again you can compare with the real world. If someone enters the wrong combination on a keypad, the turret won't start shooting right away.

not in our take of real life. but in SR they may well do so. at least if the person doing so is a dime-a-dozen clerk, not some braniac research head or similar important person.

remember, for the corps in SR, unless your a big boss, your nothing, just a cog in the bigger machine.

still, i would not spring a IC if the problem was a wrongly typed password for the encrypted file. thats not encryption by use of the decrypt program. using the decrypt program is, for lack of a better example, like going after a dvd with decss.

so in many ways, encryption in SR have hit upon what RIAA and MPAA wants drm to be, a shoot on sight policy if you step over the thin yellow line that they keep moving closer and closer...

so to redo the shooting turrets. they would not trigger upon a bad key entry, but they would trigger if they detect any tampering with the keypad itself.

Plus like hobgoblin mentioned, there is a huge difference between an authorized user typing in the wrong password by mistake and a Decker brute-forcing the encryption.

I'd rule the IC has to successfully analyze the hacker (if the hacker is running a stealth program) before being able to attack or do anything to him. Just because he decrypted a file doesn't mean his stealth program stopped working or lets the system know who he is.