Oh, I never said alchemical passkeys were better in any way, except being harder to forge. I just said that was how it was done.

Honestly, the rampant argumentation concerning encryption is tired because it has already been done, to death and beyond. There exists two grades of encryption in SR and in the real world: unbreakable and breakable. The latter is the most common, and comes in a variety of flavors, levels of difficulty, etc. The former is essentially one-time pads. If it is not a one-time pad, then given sufficient resources, time, effort and ingenuity the code can be broken. That's true today, that's true in Shadowrun - the only difference is that in SR the means to break standard encryption have been extremely improved. This was explained away as a mathematical breakthrough, but really it's an excuse to allow the player characters to break encryption in something resembling the time frame of a standard session; no one is going to want to devote years of their game life to break the encryption on a single email from some Renraku middle manager's misstress when they can pirate a decryption program and get it done with a couple die rolls. Basically, the difficulty of encryption in a given game or a given situation in a game falls down to how difficult the gamemaster wants it to be - Zurich Orbital, as the epitome of trying to run up a skyscraper, is going to be described as "unbreakable encryption" even if it is feasible to break the codes, because the need is there to impress on players and player characters that it is not easy.

Or the ability to read the wire (or even any compromising emissions).

http://en.wikipedia.org/wiki/TEMPEST may inspire thoughts in that area.

You can't brute force it. As kzt said, any message is equally likely. A brute force attempt at something OTP encrypted looks like an alphabetical sorting of any and all combinations of characters of that length. If you're trying to decrypt a 160 character twitter message, you will among other things get any and all twitter messages ever posted, any and all 160 character length passages you can pick from any novel ever written. And all of that backwards. Even if you could find just the ones you thought would be likely messages, you'd end up with a list of all the possible things you could imagine the message being - which you already knew.

On the one hand, local use of OTPs for perfect encryption makes sense, like riggers securing the connection to their drones. This is eminently possible with Shadowrun technology.

On a worldwide scale, it does create some issues, as people have addressed above.

If the game rules tried to accommodate both - tried to implement different encryption methods - we'd have way too complicated game rules...

(Oh wait, we actually have those without a good implementation of encryption!)

And how would he do that? It does one thing - takes incoming strings, decrypts them according to the OTP identifier, encrypts it for the receiver, and transmits it. It doesn't accept commands, or remote administration. It is one hell of an infil job to pull off.

And you're still ignoring the central point - even if someone managed to break into their OTP hub, it would only leave them where they were without it. By using a hub they go from "no secure comms" to "100% secure comms except against the one team that can do a datasteal on our best protected and isolated system".

Very true. But it would narrow down the list of possibles a bit as you have the exact length. I'm not saying its practical but its theoretical doable to narrow down a OTP to at least some thing useful. Though I'm sure all the manhours and processing power could be better assigned in nearly all cases.

No: no matter what feed you have, you can find storage space for it on the matrix. But remote storage does not work for pads. Local storage capacities are left for the GM to decide. Storing the equivalent of every single packet you ever send or receive might very well make your commlink explode.

No it isn't theoretically possible to narrow it down to anything. You would get the exact same result if you just started writing down every single message you could imagine your enemy sending (the point here being, you could do that even without intercepting the message, so no need to bother with that).

There is not a single bit of meaningful information in an OTP encrypted message unless you have the OTP. Literally not one single bit. It is totally, completely random data.

Actually, it says

Storage memory and data compression technologies by 2072 allow vast amounts of
information to be stored in relatively minute spaces. For the most part, gamemasters
and players can assume that characters have enough storage memory on any
particular device to meet their needs

I'd expect even a small camera to be able to hold many, many hours of data. Commlinks, I can hardly imagine a situation where storage would be a problem. The only heavy stuff that gets transmitted is files, which there's obviously plenty of storage for, and sensor feeds, which there's no real limit on how long you can record.

hi hi


- p.218 SR4A

Hey, why don't you quote the whole paragraph?



Can't be clearer than that: the GM gets to say when too much is too much. And I would add: doubly so when players are trying to break the world. I understand very well that your interpretation differs from mine, but they are only interpretations. My only point was that the setting gives you all the tools you need to make OTP impractical. If you choose not to use them, don't complain after.

hi hi

In the setting, military/security teams routinely go on missions and come back with a full record of all sensor inputs obtained during the mission. If you want to assume they're uploading those records to youtube during the mission, thats fine I guess, if you want to assume that computer storage and file sizes are drastically less efficient than they are today, thats fine too, if you want to say that a realistically cold equation is breaking the rules that is also fine. However, with each of those assumptions you had best be prepared to deal with unintended consequences.

Besides, you don't need to do anything at all to disallow PADs because they don't exist as an encryption option in SR4. As I stated earlier, my original intention was only to point out how they actually work in reality. If someone wants to house rule them in, I hope they get the mechanics right.

There are at least 4 "systems".

1) Those systems whose underlying design is fundamentally insecure and can be broken no matter how carefully you use it. Examples are Rot13, WEP. These can be broken in essentially real time.

2) Those systems whose underlying design pefectly executed makes an attempt to decrypt take a long but reasonable time (like hours to days). Examples are DES and Enigma.

3) Those systems whose underlying design perfectly executed makes any attempt to brute force decrypt take geological time and (due to Shannon's information entropy) release nuclear weapon scale waste heat. Examples of this are AES and the NSA's type 1 and Suite A Cryptography.

4) Those that are provably secure if perfectly executed. These are the class of math problems called undecidable. The One Time Pad is the only example of this. For practical purposes 3 & 4 are the same.

There are then 4 subsets of these:

A) The implementation of the system is perfectly executed and operated, so it provides all the protection you expect. This is not easy or cheap to do in a large scale system.

B) The implementation of the system is flawed so that the system doesn't provide nearly as much protections as expected. This is often done for cost saving reasons or just sloppy work and means the system is practically attackable if you understand how it works.

C) The implementation of the system is perfectly executed but the keys suck. No matter how great a system is using 'Password' as the key means the system provides essentially no security and will be breakable in real time. Key distribution and changes is always a problem in any large-scale system and many smaller systems.

D) The implementation of the system sucks and the keys suck.

All systems are vulnerable to black bag jobs or rubber hose cryptanalysis. The KGB broke extremely secure US Navy codes by getting the North Koreans to capture the Pueblo (which had a Navy crypto machine) and then paying Walker to give them the keys. The Verona messages are a large number of one time pad encrypted Soviet messages that were decrypted by the NSA because of operational mistakes.

Except that TCP/IP isn't really 1 to 1
the data is burst transmitted to the router, that looks where it's going and burst transmits it to the routers above it, and it gets all mixed together the farther up the pike we go.

You're thinking because this post was sent between you and the server, or me and the server in a direct line.
WHen it wasn't. My message was never encrypted. Perhaps yours was if you went over a WEP connection of some kind. But it was decrypted by your router. If you had a passphrase of some kind, then everyone connected to your wep had the same passphrase, unless you're using a RADIUS server, which does individual authentication.

If we were all using 1 to 1 encryption to get to this forum, then the forum server would have to have thousands of decryption keys.

Stop putting words in my mouth. My point all along has been that the internet has a lot of one-to-one communication schemes and yet you can still post to Dumpshock, and so can I. Your point about TCP/IP is specious because I never talked about TCP/IP. I was talking about the wires that internet traffic passes through.

You, on the other hand, have been completely failing to notice that I have been analogising OTP-secured connections and wires in relation to the internet. Everything you've been saying about my post making its way to Dumpshock applies equally to a network (overlain on the worldwide network, like peer-to-peer filesharing networks are) of OTP-secured connections and information from ZOG making its way to a financial institution. It doesn't make it in one encrypted hop, but it can be relayed or forwarded until it reaches the destination.

But you're so obsessed with the use of Encryption that you can't see the forest for the trees. An encrypted channel is a channel like any other, it's just harder to snoop on. That's all.

I don't see why.

There are two possibilities for encryption.
1) The stuff is encrypted on the first node and decrypted on the last node and any node in between just carries packets of gibberish. In this case, the number of 1 to 1 encryption needs are many but the middle network needs no security at all.
2) The stuff is encrypted on node 1, decrypted and re-encrypted on node 2 for delivery to node 3, etc. etc. In this case the number of 1 to 1 keys on the node is limited to the number of devices subscribed to that node. If you have this setup you need a secure network but you don't need to maintain a key for every possible start point end point combination. Subscribing to a node with encryption is just a handshake.

To me, the second option is maintainable and, from a shadowrun hacking storytelling standpoint, much more enjoyable.

I'm getting the feeling that packets and hops are important to this discussion and may be causing some communication issues.

If you're running windows, pop open a command window and type "tracert forums.dumpshock.com". (If you're on a linux or mac, run a traceroute. If you're on Linux, you should know how and if you're on a mac you should know how to look it up. )

What you should be seeing are the nodes that, for lack of a better description, a technomancer would walk through to get from your house to dumpshock. This is one possible route, the best route at that time. There may be others routes. (We're trying to keep this at a simple level.). You can do this for a variety of destinations.

When dumpshock sends you a file (such as the HTML needed for your computer to display this) it breaks it up into lots of tiny twitter-like messages, sends them through this path of nodes and your computer reassembles them. One advantage of doing so is that if one of these little messages (packets) glitches, we only need the packet resent, not the whole dang file. Another advantage is the packets can be sent along different routes, balancing the load.

As a hacker, you want to be on a node that all the packets go through, not a node a packet might go through. And if that node has little to no encryption, so much the better.

What I'm describing (with the exception of the actual example used to to give you an idea) is technology-free. This could be implemented in many many ways 60 years from now. But it's a decent way of describing how a network operates at a simple level.

Yes, this is all first-year stuff simplified way way too much. I'm just trying to get everyone on the same page and if this isn't the page, I'm hoping someone will show me what page I should be on.

The reason why is this:

If you encrypt something using OTP, in order to decrypt it you /have/ to have it's twin.
OTP's come in pairs. Pad1 encrypts, Pad2 decrypts.
You /cannot/ decrypt without Pad2.

The way the encryption you're talking about usually works is using a private key.public key setup.
The server has the private key. Users you want to have access have the public key.
There is 1 private key, and 1 public key, but /many/ people can have the public key.

SSH works the way you describe #2 as working.
The server has a private key, you have a personal key (usually with a password, although that's not actually required).
You do a handshake to the server, and you are in on an encrypted line.

But neither example you gave is actually OTP. OTP is a very different thing.

Heath Robinson keeps on talking about "wire systems" like the internet or the matrix are connected by actual wires between servers and traffic flows directly from commlink to node to node to commlink. And that's just not how the traffic works. It's not like 2 tin cans with a line between the two. packets are actually broadcast across vlans, subnets, all sorts of fun things.

There are many many ways to do solid encryption in real life, and in ShadowRun's Matrix. But an OTP system is not going to work for 99.9% of the communications being handled by corporations.

BTW, the way it usually works today:
Source Node encrypts data.
It passes it up the line to it's router, that passes along the encrypted data without ever really trying to look at it, except to get it's destination address.
The data bounces from router and switch to router and switch until it gets into the right subnet, then it's picked up by the Destination Node and decrypted.

If every node in between unecrypted it, reencrypted it and passed it on, that would be a nightmare. Because your data passes literally through the hands of a dozen different legal entities hands between source and destination. If any of those could decrypt your data at will when it was on their leg of the journey, nothing would be secure.

Which is why you don't send secure data through their hands.

The following statement seems obvious to me. What am I missing?

Don't let secure data outside of your network.

I don't care how mathematically confident you are in your encryption. It makes no sense to me to entrust something I want secure to my enemy in the hopes that he'll deliver it unmolested to my friend. Why would someone do it?

Yes if its so high risk that you need a huge crypto effort to protect it your best bet if it NEEDS to leave your network is physical transportation in that hands of soem one you trust not UPS ect.

Except we know that Corporations use VPN's and are all connected to the Matrix.
Because you can't necessarily afford to lay cable to every single one of your friends.

It's called money. People use the internet because they can't lay down cable to everyone they want to be able to talk to. It's just not feasible. And it's even less feasible for individuals.

Not that this'll get through, but the emphasis is on secure.

What level of secure though.
Originally there was talk of using OTP for everything.

Using VPN tunnels you can have decently secure data. Is it unhackable, probably not, but it's certainly difficult.
Corporations use VPN tunnels across the internet /all/ the time to transfer data 'securely'

You don't need to lay down cable for EVERYONE you want to talk to. For those things that aren't secure and vital, go ahead and use external networks. Your post indicates you believe all communications need complete security and therefore we can't use public networks and neither can corporations. I don't believe this to be true, now or in the world of Shadowrun. Most data isn't worth the effort it would be to capture it in the wild.

VPN is great for many things. But there are jobs where if you want to do the job you go into the secure building and log-in and all the work is local. The tempest protected classified machines aren't even connected to the outside world. Translated to shadowrun, that's a job for a team. Get the hacker in, get the data, get it out, don't get caught.

And that data probably isn't a corporate memo or mission statement.

No, I don't believe you need secure communications for everything.

I'm trying to point out that using OTP for every communication is completely unworkable.



Bolded in the key parts

I've been trying to say that this setup is completely unworkable for most of the data transmission needs of Corporate Entities in ShadowRun.

Except we're not talking "most of the data transmission needs of Corporate Entities".

We're talking the secure transmission needs of Zurich Orbital.

There's probably a lot of non-critical data chatter to and from ZO that uses standard channels.

But the hyper-critical data transfers? The ones that CANNOT be allowed in the wrong hands?

Those are probably low traffic enough to use OTP or similar level encryption methods.


-karma

This is actually how a GSM cell phone call works. The link between your phone and the tower is encrypted, the tower decrypts it and hands the call off to someone else decrypted. The voice/data stream passes unencrypted unit it reaches the destination. If the destination is a cell phone the tower connected to the cell phone encrypts the traffic and sends it to the cell phone.

GSM also initially used a poorly designed encryption algorithm, not sure it this was ever corrected.

What strikes me about this is there is one data transfer that CANNOT be allowed into the wrong hands involved in this and that's the OTP. The people in favor of it have been very convinced of it's physical security and invulnerability to with regards to social engineering and de-syncing.

Whatever one's method is for getting the OTP from here to there, it makes me wonder a few things:
1) How far in advance has the OPT be transferred to the endpoint? How much time does a team have to get a copy of that OTP? At what points is the physical OTP vulnerable? How much is a copy of that pad worth?
2) What is it about the data that's forcing it to move through public channels if the OTP didn't have to?

1.) I would say monthly. Since there are constant trips up to ZO and back, a vetted courier can hand-deliver the OTP to the recipient either spaceside or dirtside. The OTP is most vulnerable in the pre-delivery stage, because if it's coming from GOD like I would assume it is, then you're only going to get it between the time it lands on Earth and is delivered to the end-user. It's probably delivered with a heavy escort and tucked away in a highly-secure environment guarded by, well, everything. If you could get a copy of that pad, you would be privy to the communications of ZO and everything that entails. Thoughts from the judges on the Corporate Court about cases, advance interest rates from ZOG, new security algorithms from GOD - all the juicy bits. It would be priceless for as long as it took to create and send another OTP once the copy is discovered missing.

2.) You lost me.

Oh, you mean like how it is in SR4, where everything can be decrypted at will and nothing is secure?

Guess that's your argument gone right there.

In SR4 it is really, really easy to hack and nowhere even approaching secure.

Time? You need to send the data as soon as they are ready, and as fast as possible. The pad, however, can be sent in advance so you can afford slower and more secure transmission (for example physical transfer in military vehicles with spirit escort, humorless guards, decoys,...) and you can send it in bulk to reduce the cost of said security.

Or you have the quantic explanation. The difference between the pad and the data is that the data actually mean something, whereas you don't care what the pad is as long as both ends have the same. There are people working on quantum transmission that generates the pad during the transfer and ensures no one else can listen to the communication. But it seems you cannot do that with any pre-generated data. I don't know much about the details.

You haven't provided a single argument for it though.

The issue here is "OTP only the important stuff or OPT everything.

If it's OTP everything, then anyone who can get a copy of the OPT and keep it in sync and copy the data going through the public lines is golden. The easier it is to keep in synce the more golden they are. The harder it is to keep it in sync, the more vulnerable the communication is to being disrupted. Turning that vetted courier is worth a heck of a lot. Getting Technomancer access is even better and easier to hide. And how many vetted couriers do you need to keep all your units in communication with each other constantly? What is the process when a facility can no longer communicate via OTP ?

If it's OPT only the important stuff, why isn't the important stuff carried by the vetted courier?

The issue here is that breakability is only half of security. Usability is the other half. Usability is killer when it comes to security and OTPs are really a pain to use properly. One uses them when not getting the transmission is preferred to the enemy getting the transmission. The reason so many things are often so badly secured is that security, done properly, is a giant hassle. Ignoring that and embracing only the math is neither fun to play nor fun to deal with in the real world.

Of course there are social engineering and infiltration issues (desync is not an issue, you can easily verify your position in the OTP).

Compare the two situations

Current SR4 encryption
1) Some degree of vulnerability to social engineering
2) Some degree of vulnerability to hacking
3) Comms that are effectively unsecure

SR4 with OTP
1) Some degree of vulnerability to social engineering
2) 100% safe from hacking through encrypted lines, some degree of vulnerability to hacking on other lines
3) 100% secure comms

Number 1 is something you can handle through operational security. Number 2 is by and large something you can handle with spiders, but you're still cutting down your vulnerability a lot with OTPs. Number 3 is the really, really bad news, there is nothing you can do about it under the current SR4 system, you comms are matematically certain to be wide open - you can go from that to 100% secure with OTPs.

Bottom line, you can't fault the OTP scheme for having a vulnerability that also exists under the current setup. Using OTPs would be a MAJOR security improvement.

If you want to argue against the OTP scheme, you HAVE to point out something in it that is worse than the current setup (and on top of that more of a downside than the major advantage of non-dectryptable comms).

You apparently fail to realize that getting a copy of the OTP is equivalent to comprimising their entire security setup. If you can do that, you already have a backdoor that lets you listen in on whatever you want. You'd be screwed over no matter if you ran with OTP or not, so it isn't an argument against the method, just the simple fact that if the opposition can infiltrate your organisation, they can spy on you. That's not something you can solve with encryption anyway.

And please, this sync thing, why do you get the idea that OTPs go out of sync? Why should there be any packet loss? Do normal transmissions suffer packet loss? In the future, they stopped using protocols that fixed that? And even if it did, there's no harm done exchanging resync info.

Heh, which kinda makes the whole concept fall apart if you try and model an actual society.

Really good encryption security is what lets a highly technological society function.



-karma

It is only OPT the important stuff (the fluff coming out of ZO, for the fifth time now, is encrypted to a lesser degree albeit heavily and masked with a 12-satellite shell game to throw folks off), and the vetted courier doesn't carry it because it takes time to get a mission into orbit. Prep time, launch window, secure the dataz, all of it. Easier to send down a OTP once a month and then the data can be sent near-instantaneous using the OTP as an encryption. It's hid with the rest of the garbage on the commsats they're using for a shell game to minimize anyone even picking up the transmission.

Yeah. I try not to think about how they make the whole electronic money thing work without encryption.

So what you're saying is, if a black ops team used channelhopping and hid their actual comms in lots of garbage, people couldn't listen in, spoof commands, etc.? Why aren't they taking lessons from ZO orbital, it sounds easy enough (frequency hopping radios are already in use today).

That's another thing the Chaos Sprites fuck up I guess.

Because you'll get farther with minimal communication since that kind of noise screws up everyone's signal. It's concentrated on that scale. ZO has tight-beam transmissions bouncing to these sats, and these sats bounce it down to the target. Or each other. Half of it is to hide where the station actually is.

To the best of my experience, it's mostly along secure lines. FED transfers do NOT go over the internet unless something has radically changed lately. When I worked with them access to the area where the computer was kept was extremely controlled. The physical network itself was protected.

Doc: You are saying OTPs are for special use only. Smokeskin is claiming they're for constant use. Both have different advantages and vulnerabilities.

Yes, normal transmissions suffer packet loss. This isn't the fault of the protocols. Protocols exist for dealing with packet loss so that transmissions can be reliable and quick.

How are you exchanging resync info in a secure manner? Why is that exchange assumed to be invulnerable and reliable?

How do you keep hackers and sprites from brute forcing keys off the OTPs in an effort to destroy the reliability of the communication?

I don't know if you're being serious, or just doing the "GM-must-defend-the-setting"-thing.

I don't know if you're being serious, or just doing the "must-be-contrary-because-it's-edgy"-thing.

Since you're trying to equate hiding a signal across hundreds of thousands of miles with hiding a signal in about 150m of blaring garbage that any rigger/hacker is going to say "yup, jackasses there", then I'm leaning towards the latter.

But everyone goes around paying for stuff in their every day life in SR4. Without encryption, that's pretty hard to have working.



My point is, the protocols ensures that lost packets get resend - every bit gets through. Sending an OTP encrypted signal is no different from any other signal, you'll end up with everything in the right order in the right place, for you to decrypt.



A protocol could be "Begin at cipher x, the first 100 bits encrypted bits are all 1s". If you receive such a message and the first 100 bits doesn't decode to all 1s, it is from an enemy, and you discard it. If it decodes properly, it is from a friend.



You can't brute force an OTP. Even a 100 bit check as above would require a trillion fake messages per second for 30 billion years to run through them all - only one of those signals would strip off one "key". If that's not good enough for you, we can go to a 200 bit check to make it take a million trillion trillion times longer.

I'll just throw you a few key lines from Corp Guide p 27:

There is a constant stream of
communications traffic going between the ground and the station
[...], and no matter how good your Matrix
people are, that sort of traffic is tough to hide. [...]
I know a few hackers who have driven
themselves crazy trying to break the encryption of these streams,
only to find that beneath the garbled noise is only more noise.
> For all we know, some of those hackers might have lucked on the
real deal. I’d be severely disappointed in GOD if their encryption was
weak enough that some yahoo on the ground could break it.
> Except it’s not just yahoos who are looking for this info. Those who
are capable of cracking the encryption algorithm, however, are also
the least likely to talk about what they have done.

They're not managing to hide anything. They have some encryption going that is apparently hard to break.