Help - Search - Members - Calendar
Full Version: Encrypting a device or node
Dumpshock Forums > Discussion > Shadowrun
I found a couple older posts that talk about similar topics, but nothing that addresses this directly.

From the BBB,

"Files, signals, and devices may all be encrypted with a Simple Action. If you have the proper key, decrypting takes only a Simple Action."

"Encrypt programs utilize various cryptographic schemes and ciphers to secure files, access nodes, and communications between nodes."

I understand how encrypting and decrypting files and communications works, but what exactly happens when you encrypt a node/device? Does it mean that anyone accessing the node must run a successful decrypt before they can do anything? If you haven't yet decrypted a node, could you still engage in cybercombat in that node even if you can't browse files and such?

In order to encrypt a node, does the node itself have to run Encrypt? Or can some random hacker enter a node, encrypt it with a simple action (per the first quote), and then leave again? That doesn't make much sense to me...

But if the system itself is running Encrypt, who would take the simple action to encrypt the device? As far as I can tell, nodes don't actually have a place in the combat turn sequence. Would it just happen automatically (with no action) for the case of a node running Encrypt?

Here's an example sequence of how I imagine it would work:

Commlink A is set up to run Encrypt 5 to encrypt both itself and its communications. Whenver it boots up, it launches Encrypt as part of its startup sequence.

Hacker Stimpy tries to hack into the commlink. Stimpy breaks in, but he's sloppy, and the commlink detects him. As soon as he's in, the commlink launches IC to attack him.

Stimpy is now in an encrypted node with IC attacking him. He can't take any actions on the system (browse or edit files, etc.) until he breaks the encryption via Decrypt. He can still fight back against the IC, but only by direct combat (e.g. he couldn't try to crash its programs or spoof a command for it to stop attacking).

What Stimpy really wants to do is connect to the commlink owner's cybereyes, which are subscribed to the commlink. Before he can even start hacking into the cybereyes, though (i.e. use an outgoing connection from the commlink), he still needs to complete his decryption.

If Stimpy succeeds in decrypting the node, he can act normally there. If he leaves and comes back again, though, he'd need to break the encryption all over again. Of course, he could probably extract the encryption key before he leaves via some other commands (Data Search, Disarm a data bomb, Decrypt the file where it's stored).

Does all that look correct?
My ruling: You cant encrypt a node or device, only static data or traffic.
i think encrypting a node or device is encrypting the traffic.
Well then thats really bad wording. Something you should avoid in a rulebook.
eh, not really. i mean, from a rules perspective, the node/device is the traffic it sends out. trying to differentiate will just cause confusion.
encrypt the traffic and you have to decrypt to gain access. simple really nyahnyah.gif

that is, if the node only allows encrypted traffic.

to me, encrypting a node would be just like encrypting a SAN in SR2 pre VR2.0...

say the password using the secret language...
QUOTE (kerbarian @ Dec 25 2006, 06:06 PM)
I understand how encrypting and decrypting files and communications works, but what exactly happens when you encrypt a node/device?

In short, I view encrypting a node/device as the process of encrypting all the node's communications links with the outside world under a single encryption scheme.

I go with cinematic references to explain how this works:

Reference #1: Sneakers
In particular, the scene where the team is having their party after first acquiring "The Box" and they end up testing it out by connecting to several dial-ups from Whistler's list of "supposedly unhackable" computers. At first, when they connect, they get nothing but an encrypted stream of data. Because all outgoing data is scrambled, there's no point of reference for any exploit-type program to even attempt to crack in. Even if it were to attempt something at random, the attempt would be rejected because the computer at the other end is expecting any incoming data to be encrypted under the same scheme. (Note that in Sneakers, once "The Box" had cracked the encryption, they had direct access to the computer they were connecting to. In SR4, this would only work if the node were configured for full public access underneath its shell of encryption. Typically, under SR4, breaking the encryption on the node merely allows your exploit program to be able to read the data it needs to be able to begin its break-in attempt, and to be able to have the data it sends back even be recognized by the node)

Reference #2: Lawnmower Man
The climax of this movie shows a process similar to encrypting a node, in that the virus that Dr. Angelo releases into the system is designed to identify all the system's communication ports with the outside world and encrypt them. Once encrypted, the port is unusable for any meaningful data transfer with the outside world, unless the decryption key is used. An important take-away point from this example would be that to encrypt a node, you likely should have both an account with admin rights, and perfect knowledge of all the methods that node uses to communicate with the outside world.

As for whether or not encrypt would have to be running on the node, that would depend on how your table views the encrypt program to work. Some tables require both ends of an encrypted data stream to run encrypt constantly while the data stream is active. However, there are some tables that handle encrypting of a data stream by saying that all the Encrypt program does is define a particular encryption protocol that is then applied to the stream at all ends. In those cases, Encrypt only has to run on one node at one end of the datastream, and it only counts as running when the encryption is first established.
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