Help - Search - Members - Calendar
Full Version: Thoughts on Encryption/Decription
Dumpshock Forums > Discussion > Shadowrun
Pages: 1, 2, 3
Smokeskin
QUOTE (Rotbart van Dainig @ Dec 31 2009, 01:38 AM) *
rotfl.gif

Because we all know - datasteals never happen in SR.
Icing on the cake: For your system to work, it needs to be online... and thus can be hacked. Gives paydata a whole new meaning, really.


You're looking at it the wrong way. It isn't about the system being unbeatable.

It is about this: Would people

a) go ahead with just easily breakable encryption
or
b) pay a very small cost to use a one-time pad encryption service that can only be compromised if people manage to hack the encryption service provider.

It sounds like you want it to compete with an unbreakable system that people already have access, but that isn't the case - in SR, people have no effective encryption available to them, and that should be the starting point of your analysis.
Rotbart van Dainig
QUOTE (Smokeskin @ Dec 31 2009, 11:28 AM) *
You're looking at it the wrong way. It isn't about the system being unbeatable.

No, it's about the system being broken-by-design. Handing over both the key and your plaintext to a trusted third party defeats the whole idea of encryption.
QUOTE (Smokeskin @ Dec 31 2009, 11:28 AM) *
go ahead with just easily breakable encryption

Yes, because at least they control the keys and the plaintext for a certain amount of time.
QUOTE (Smokeskin @ Dec 31 2009, 11:28 AM) *
pay a very small cost to use a one-time pad encryption service that can only be compromised if people manage to hack the encryption service provider.

The thing is, those services will go out of business with the first breakin.
QUOTE (Tymeaus Jalynsfein @ Dec 31 2009, 05:12 AM) *
The Military has no sense of Humor when it comes to their Crypto...

Which can lead to disaster as well due to inflexibility: The protocol for encryption is slow and rigid, and everything that is too much hassle will stay plain unencrypted, before failing in the field.
This is what caused the drones to transmit video uncrypted, which in turn was captured and used by the opposition.
kzt
The problem with a one-time pad is that you have to have secure means to get a copy. As in RAW there are NO secure means other then face-to-face this makes it pretty hard to have service that provides it to you electronically.

By RAW you can't trust anything you get electronically. That call from your fixer? It could just easily be LS and there isn't any way you can tell, until you show up at the meeting. Your calls can be overheard by anyone. There are no "secure matrix conferences", the entire idea of having a matrix meeting to discuss anything more secret then the lunch menu is totally insane.

Any time you transmit anything, like a credit transfer, it can be decoded in real time. So once you use your credstick to buy anything anyone can empty to account trivially.
Rotbart van Dainig
QUOTE (kzt @ Dec 31 2009, 01:36 PM) *
By RAW you can't trust anything you get electronically.

The Resonance Realm expands on that problem by an insane amount, too:

With a Realm Search, you can find and recover any data that ever existed on a non-hardcopy system, even if long-gone in the real world. If that wasn't already worse, you can make data in the real world disappear, too, regardless of protection.
Sengir
QUOTE (Smokeskin @ Dec 30 2009, 08:31 PM) *
the provider has previously exhanged one-time pads with both.

And how did he do that, in a secure and verifiable way? wink.gif
StealthSigma
QUOTE (YuriPup @ Dec 30 2009, 06:07 PM) *
WTF is a ton of heat?

If observing your data changes it, you're screwed well before you get to the decryption--writing it would change it, reading would change it. Whatever you are storing your data in/on will operate on a level higher than the uncertainty principle so that, you know, your data doesn't change on you while you are looking at it.


Quantum encryption in theory is supposed to prevent people from eavesdropping on a secure communication. Since the data changes when observed, the receiver will know if there's an eavesdropper since data is not what are expected. Communication ceases, and the eavesdropper only has a small portion of data that by itself is likely meaningless.

--

QUOTE (Rotbart van Dainig @ Dec 30 2009, 10:48 PM) *
And the latter is why storing the keys of everyone on an online system just is disaster waiting to happen.


That's the foundation of the public key infrastructure. You have a private key which only you know and keep, and a public key that you give out that people can use to encrypt files send to and by you. It sounds weird, but it does work.

--

QUOTE (Rotbart van Dainig @ Dec 31 2009, 07:29 AM) *
Which can lead to disaster as well due to inflexibility: The protocol for encryption is slow and rigid, and everything that is too much hassle will stay plain unencrypted, before failing in the field.
This is what caused the drones to transmit video uncrypted, which in turn was captured and used by the opposition.


In my opinion, that was a mistake that could have become a significant intelligence tool. They fouled it up by reporting it.

What they should have done was increase the drone fleet by about 25% with new drones using encrypted transmission and convert about 25-33% of the existing fleet to using encrypted transmissions.

Basically, we knew that they knew what we knew about them, but they didn't know that we knew that they knew what we knew. We had the upper hand and frivolously wasted it away by publicizing it. We could have used it for misinformation. Send the unencrypted drones over targets we consider low priority and use encrypted drones over high priority targets. So while they're looking once way, we get to kick them in the ass.
Rotbart van Dainig
QUOTE (StealthSigma @ Dec 31 2009, 03:27 PM) *
That's the foundation of the public key infrastructure.

Not quite, as that is asymmetric encryption.

The suggestion is about symmetric encryption, which only has one key that needs to be kept secret - and the equivalent would be to give away your private key in asymmetric encryption.
StealthSigma
QUOTE (Rotbart van Dainig @ Dec 31 2009, 09:38 AM) *
Not quite, as that is asymmetric encryption.

The suggestion is about symmetric encryption, which only has one key that needs to be kept secret - and the equivalent would be to give away your private key in asymmetric encryption.


Perhaps you had read symmetric encryption, but I saw nothing that specified symmetric. Just that to easily break encryption you go after the key. That's a weakness that is shared between symmetrical and asymmetrical encryption.

Symmetric encryption should never be utilized for data in transit, only for data at rest and only for a single machine, unless you can secure the transmission of the key itself, and even then only between a small number of machines. The strength of asymmetric and symmetric encryption is identical, with a noted exception that you require a large keysize in asymmetric to get the same level of effectiveness.

There are technology deficiencies that also affect symmetric vs asymmetric key size, but those are beyond the strength of the actual encryption and boil back to the fact that data at rest is far easier to protect than data in transit.
Rotbart van Dainig
QUOTE (StealthSigma @ Dec 31 2009, 03:49 PM) *
Perhaps you had read symmetric encryption, but I saw nothing that specified symmetric.

One-Time-Pads are symmetric.
QUOTE (StealthSigma @ Dec 31 2009, 03:49 PM) *
Symmetric encryption should never be utilized for data in transit, only for data at rest and only for a single machine, unless you can secure the transmission of the key itself, and even then only between a small number of machines.

WPA2 uses symmetric encryption. There are schemes that use asymmetric encryption to negotiate a symemetric session key, too.
Sengir
QUOTE (Rotbart van Dainig @ Dec 31 2009, 03:33 PM) *
WPA2 uses symmetric encryption. There are schemes that use asymmetric encryption to negotiate a symemetric session key, too.

...for example the key exchange methods used by WPA and WPA2 wink.gif
Even when using a pre-shared key, this key is only used for authentification. The actual key for encrypting the data stream is negotiated between the client and the AP every time the client connects.


Also there seems to be some confusion about quantum cryptography, so here's a quick rundown on it:
The idea of quantum cryptograhpy is not to transmit any data over quantum states, the idea is to produce two identical sets of random numbers on both sides of the line. These numbers would then be used as a key to encrypt the actual data, and because any evasdropping along the line will inevitably change a significant ammount of those numbers, every attempt to sniff the key would be noticed.
After the key has been exchanged, the data is encrypted with this key and an arbitrary cryptosystem and sent over any conventional channel you like, from fiber wires to pigeon carriers.



In short, the problem with every kind of cryptography is the secure and trusted exchange of keys. Even public-key systems do not solve that problem, because how do you know for sure that the public key you got is really the one of the person you want to communicate with? An evasdropper could just have sent you his own public key, then he can decrypt your messages, encrypt them with the real key of the intended sender and pass them on. You could of course have other people vouch for the correctness of the keys, but how do you know you can trust those people...wink.gif
Rotbart van Dainig
QUOTE (Sengir @ Dec 31 2009, 05:38 PM) *
In short, the problem with every kind of cryptography is the secure and trusted exchange of keys. Even public-key systems do not solve that problem, because how do you know for sure that the public key you got is really the one of the person you want to communicate with?

Apart from out-of-band-verfification, one approach is a Web of Trust with key-signing, the other is the Socialist millionaire method.
Sengir
QUOTE (Rotbart van Dainig @ Dec 31 2009, 04:51 PM) *
Apart from out-of-band-verfification, one approach is a Web of Trust with key-signing, the other is the Socialist millionaire method.

Web of Trust is the method I described, including the problems...you need a "starting point". Out-of-band simply shifts the problem to another medium, and the socialist millionaire problem is just a name for very similar problem (which means that the possible solutions and their weaknesses [man-in-the-middle attacks] are also quite similar) wink.gif
Earlydawn
I'm trying to follow (not completely comprehend) this back-and-forth, but I was never a math / mathematical applications guy, so I'm going to ask a couple questions because I find it interesting. First of all, the difference between symmetric and asymmetric encryption is the symmetry between the keys that both parties use, right? So in a symmetric scheme, you and I have the same, or a related key, but in asymmetric, I have one key to encode / encrypt (proper terminology?), whereas you have a unrelated key to decode / decrypt? By their nature, is one naturally more secure then the other, or does it depend on specific schemes?
Rotbart van Dainig
QUOTE (Sengir @ Dec 31 2009, 06:20 PM) *
[...] you need a "starting point".

That's not a problem of encryption, though, but a general one. wink.gif
QUOTE (Sengir @ Dec 31 2009, 06:20 PM) *
Out-of-band simply shifts the problem to another medium,

Which helps a lot to start a WoT. wink.gif
QUOTE (Sengir @ Dec 31 2009, 06:20 PM) *
the socialist millionaire problem is just a name for very similar problem (which means that the possible solutions and their weaknesses [man-in-the-middle attacks] are also quite similar)

Used correctly, it prevents MitM attacks, as done in Off-The-Record messaging.
tete
QUOTE (kzt @ Dec 31 2009, 02:00 AM) *
The NSA and the various signal security commands in the military branches are extremely hard-core about the design of the equipment they buy, how they buy it, how they control it and how they control the keying material. They have no sense of humor about accidents. Very few commercial organizations have any possibility of being able to do this as effectively.


/agree, I'd like to add that some of the NSA documentation is INSANE about how to secure a system. I mean unless your only using that terminal once it would be unusable on day to day use. For example taking plugging the time into a math formula in a script that renames everything on your linux install (including commands) and gives one print out of the system changes that you then store in a secure safe and then removes all printing functionality from the OS. This system (while secure by being obscure) is unusable on a day to day level!

[edit] I've seen some very interesting ways of handling computer security over the years both in government and private sectors. Some are good some are terrible. One of the most interesting was in the private sector where everyone had a wireless devices that you received all your passwords on every day (passwords changed daily). The device passwords changed monthly and you had 5 chances to get it right or it wiped the device. If you lost your device all you had to to was call a phone number and they scrubbed it remotely. You also had to call a number if your device ever lost its network connection for any reason, so you could reconnect.
nezumi
QUOTE (Earlydawn @ Dec 31 2009, 11:25 AM) *
symmetry between the keys that both parties use, right? So in a symmetric scheme, you and I have the same, or a related key, but in asymmetric, I have one key to encode / encrypt (proper terminology?), whereas you have a unrelated key to decode / decrypt? By their nature, is one naturally more secure then the other, or does it depend on specific schemes?


Correct. By their nature, asymmetric is USUALLY considered preferred because it allows certain other functionality (such as digital signatures). PKI, Public Key Infrastructure, is a form of asymetric encryption, where I have a super-secret encryption key (my private key), and I can send the same public key to whoever I want to be able to read my messages. Every message I send is 'signed' by me, and it allows me to maintain several encrypted lines of communications without requiring I generate a slew of different key pairs for each one.
JoelHalpern
I strongly recommend not trying to insert technical explanations for the SR4 Encryption rules. The Devs are trying (not too effectively, but they are stuck) to match the sense that hacking and data stealing are achievable. But they still need to have some way to protect things like electronic currency. So they have thrown a large quantity of technical handwavium at it.
Do what you think works for your game. (For example, one game I am in has declared that slow encryption can not be used on nodes which are actually in use. even though the rules seem to say it is okay. Because otherwise it would itnerfere with the game.)

Yours,
Joel

PS: There was recently a demonstration of how tap an untappable Quantum encryption. Thiinks are rarely as simple and clear cut as they seem.
kzt
QUOTE (StealthSigma @ Dec 31 2009, 06:49 AM) *
Symmetric encryption should never be utilized for data in transit, only for data at rest and only for a single machine, unless you can secure the transmission of the key itself, and even then only between a small number of machines. The strength of asymmetric and symmetric encryption is identical, with a noted exception that you require a large keysize in asymmetric to get the same level of effectiveness.

It typically far more CPU intensive to use a public key system to do encryption. AFAIK all the public key system approaches in common use use a public key system to do an initial negotiation, which incules setting up the symmetric keys they then use for the rest of the transaction.

If you already know who you are talking to you can just skip the public key stuff and just use a symmetric key system. IIRC, that's how encrypted radio voice traffic works, as there is no negotiation process possible.
ZeroPoint
But the root of the issue is this.

If any encryption can be broken in a matter of seconds, it servers no purpose. Its simply security through obscurity, no better than using a hash. Which means anything that is transmitted would be treated by security as if it was plain text. No sensitive information would ever be transmitted across any channel that isn't PHYSICALLY secure.

Which means Encryption by RAW just doesn't work. It either needs to be harder to crack or you might as well pretend it doesn't exist.
kzt
QUOTE (Earlydawn @ Dec 31 2009, 09:25 AM) *
I'm trying to follow (not completely comprehend) this back-and-forth, but I was never a math / mathematical applications guy, so I'm going to ask a couple questions because I find it interesting. First of all, the difference between symmetric and asymmetric encryption is the symmetry between the keys that both parties use, right? So in a symmetric scheme, you and I have the same, or a related key, but in asymmetric, I have one key to encode / encrypt (proper terminology?), whereas you have a unrelated key to decode / decrypt? By their nature, is one naturally more secure then the other, or does it depend on specific schemes?

The most common use for an asymmetric key system is a public key system.

If Joe wants to world to be able to talk to him he creates two keys, one secret that he keeps and one public that he widely distributes. These are mathamtically related such that data encrypted with one key can only be decrypted with the other. If Tina uses Joe's public key to encrypt a message only Joes secret key can decrypt it. Once Joe gets Tina's message he can use his secret key to send her a response that she can decrypt using his public key. However so can everyone else, but it proves that it came from someone with Joe's secret key.

In a perfect world when Tina sent a message to him she would also have included her public key, so Joe can use his secret key and her public key to encrypt the response so that Tina knows it came from Joe and only Tina can read it.

This all works great in theory, as there is, in theory, a universally trusted completely secure central repository that everyone keeps their keys at. The real world problem is that this doesn't exist and never will, so ensuring that the key you get for Joe is really Joe's key is a big issue. For example, if Steve gave out his public key in place of Joe then when Tina sent a message to Joe Steve could decrypt Tina's message and then encrypt it using Joe's real public key. So now you have a man in the middle who can see all the "secret" data.

If you want to go into more detail "Applied Cryptography" will tell you more about this than you ever wanted to know, and google can find lots of examples too.

Generally people believe that you need longer keys with asymmetric keys than you do with symmetric keys. For exemple, NIST says that a 3072 bit public key is similar in security to a 128 bit symetric key. Essentially it is easier to cleverly solve the asymmetric key math than the math underlying a symmetric key system. However asymmetric keys also require a lot more CPU cycles to do encryption/decryption than do symmetric keys.
Draco18s
QUOTE (ZeroPoint @ Dec 31 2009, 03:21 PM) *
But the root of the issue is this.

If any encryption can be broken in a matter of seconds, it servers no purpose. Its simply security through obscurity, no better than using a hash. Which means anything that is transmitted would be treated by security as if it was plain text. No sensitive information would ever be transmitted across any channel that isn't PHYSICALLY secure.

Which means Encryption by RAW just doesn't work. It either needs to be harder to crack or you might as well pretend it doesn't exist.


This is one of my biggest complaints about ShadowRun:

If it really is secure, then hacking it takes forever.

On the other hand, then hacking it isn't fun.
Earlydawn
Thanks for the rundown, guys. How would you guys with a background in this alter the rules while still keeping them playable?
Draco18s
You can't. Either things are easy enough to hack that when used against the players things might as well be unencrypted (likewise they'll find little resistance to their own hacking). Or things are so difficult to hack as to make doing so pointless from the player's point of view.

Basically, the difficulty threshold should be that the hacker can move around in the system fairly easily, but will take some damage for doing it, keeping him on par with the other characters (fights are fast and deadly, but not many of them), but the rules don't support this. And even if they did, it'd be really boring. The matrix doesn't have a "I dodge behind cover" action, it's call "oh, I have a program that does that. Automatically. Every time. I don't even have to think about it."

There's a tiny little computer game out there called Decker, which (using its own rules) appears very much like 1st or 2nd edition matrix rules (the maps, the programs, etc). Every time I've played it--including the highly advanced character who's actually managed to survive for more than 20 minutes--it basically came down to Stealth, Stealth, and more Stealth. If the system went to red alert (i.e. combat) I'd log out. Combat was so deadly that even with 4 or 5 ranks higher than each IC you'd still take damage, which was VERY EXPENSIVE to heal, if you had too much you did more poorly at all things, and if you took more you up and died (save file erased).

It was far less detrimental to fail a mission than it was to get into combat. Failing a run lost me 24 hours (a mission generally lasted 2 to 4 days, giving you 2 to 4 chances), failing a mission lost me the time I spent on it for the money it would have gained me (and sometimes I still had paydata that I could sell). So I never had any attack programs, kept stealth, spoof, and hide at the highest rating I could, then got smoke and silence to keep the node from triggering an alert if I was doing something sensative. I still kept armor though as if an alert triggered, IC got to go first.
kzt
QUOTE (Earlydawn @ Dec 31 2009, 05:03 PM) *
Thanks for the rundown, guys. How would you guys with a background in this alter the rules while still keeping them playable?

To be honest I think the hacking rules in SR4 suck. They suck less than the previous editions, but they are still essentially dumb and unusable.

That being said, here are some ideas.

1) If you hack a system and get an admin account file encryption doesn't matter. Nobody carries around a little black book filled with thousands of file names and passwords, it is all handled by the OS. Once you own the OS it will automatically do all the decryption for you, so who cares about encryption?

Encryption really matters when you steal a computer that is turned off or a backup tape. With effectively done encryption it's essentially impossible to break via brute force if the person setting up knows what they are doing. This doesn't mean it's unbreakable, see #2 & #5.

2) All the technology in the world doesn't help if the person setting it up is an idiot. And a lot of people with technology act as if they are idiots. I'd assume a lot of people don't set up decent passwords/passphrases/crypto variables. These can be broken in a trivial amount of time. No matter how good the encryption is if you set it to password, dragon, your birth date, you dogs name, etc it doesn't work.

3) Running good encryption is expensive, painful, and gets in the way of doing work. People need to be willing to spend quite a lot of money to have really secure encryption, hire good people to run it and allow it to be an inconvenience from time to time. So many people are sloppy. Sloppy encryption can produce serious issues. For example see the Verona Project, where the US/UK broke the 'invincible one time pad' because the KGB was sloppy.

4) Having encrypted data does not prevent it from being recorded. You may not be able to do anything with it right now, but you can record it and hope to later get the keys. And you can still do traffic analysis of the messages and eventually find interesting stuff or locate weaknesses in the encryption.

5) The best way to attack good encryption is to get the keys. This is also a lot more interesting from an role-playing game then having one guy rolling "decryption dice", as it allows the players to do stuff and the break into places, con people and do various things to get the keys. In SR, never forget the power of Rubber-hose cryptanalysis.

edit: forgot the "good" in point 5
Draco18s
QUOTE (kzt @ Jan 1 2010, 12:02 AM) *
5) The best way to attack encryption is to get the keys. This is also a lot more interesting from an role-playing game then having one guy rolling "decryption dice", as it allows the players to do stuff and the break into places, con people and do various things to get the keys. In SR, never forget the power of Rubber-hose cryptanalysis.


Don't forget Black Bag Crytanalysis. wink.gif
kzt
QUOTE (Draco18s @ Dec 31 2009, 10:11 PM) *
Don't forget Black Bag Crytanalysis. wink.gif

True. And more fun than having the hacker spend another hour rolling decryption dice.
Heath Robinson
QUOTE (Draco18s @ Jan 1 2010, 05:11 AM) *
Don't forget Black Bag Crytanalysis. wink.gif

Related: Evil Maid Attack.
Rotbart van Dainig
QUOTE (kzt @ Jan 1 2010, 07:02 AM) *
To be honest I think the hacking rules in SR4 suck. They suck less than the previous editions, but they are still essentially dumb and unusable.

Nope, they are usable by being dumb - that's the whole point of them, actually.

Strong cryptography means strong identification, having severe implications for the whole setting - say goodby to Fake SINs, for starters.
Smokeskin
QUOTE (Rotbart van Dainig @ Dec 31 2009, 12:29 PM) *
No, it's about the system being broken-by-design. Handing over both the key and your plaintext to a trusted third party defeats the whole idea of encryption.


You're obviously not getting the point. People in SR don't have alternative effective encryption.

You have two choices

A) transmit your data with extremely weak encryption
B) transmit your data with encryption that is unbreakable unless the opposition manage to break into your one-time pad provider's severs and lift their entire data storage.

A is much, much worse than B, the single option of failure for B is far above the full-time failure of A. You could even argue that it would take much greater resources to hack and lift extremely much data from the OTP provider than from hacking your machine directly, which means it isn't actually a weakness.

PS: Why are you assuming you give your plaintext to the trusted third party? There's no reason not to apply the standard encryption before using the one-time pads. s
Rotbart van Dainig
QUOTE (Smokeskin @ Jan 1 2010, 05:31 PM) *
A is much, much worse than B

See, there your mistake - let me fix it for you:
QUOTE
B is much, much worse than A

Simply because B doesn't even give you the short protection of option A, once you are a target.
In fact, B means that as soon as someone secretly aquires your pad, your future communication will be compromised as well.
nezumi
There are reasons why one-time pads are not used in the real world. You could use it for setting up your radio network or your drone network (maybe), but not for normal decking operations.
tete
QUOTE (Earlydawn @ Jan 1 2010, 01:03 AM) *
Thanks for the rundown, guys. How would you guys with a background in this alter the rules while still keeping them playable?


I would like the time to be more realistic (dont get me wrong it can be a bit movie like by not taking years or being impossible to break in, but no hacking the pentagon in 30 seconds). I'm not talking about having a dungeon crawl. For example the hacker needs to control the security cameras, we'll say there is no encrypted tunnel but there is a key needed to get on. So the Hacker tells everyone it will be 30 min for a common phrase dictionary attack. He can still move around and do other things, the software is doing the work and will notify him when it completes or gets on but now if they are inside the building the team has to stay hidden for 30 min.


QUOTE (kzt @ Jan 1 2010, 06:02 AM) *
5) The best way to attack good encryption is to get the keys. This is also a lot more interesting from an role-playing game then having one guy rolling "decryption dice", as it allows the players to do stuff and the break into places, con people and do various things to get the keys. In SR, never forget the power of Rubber-hose cryptanalysis.


I like that a lot to.
Tymeaus Jalynsfein
QUOTE (ZeroPoint @ Dec 31 2009, 01:21 PM) *
But the root of the issue is this.

If any encryption can be broken in a matter of seconds, it servers no purpose. Its simply security through obscurity, no better than using a hash. Which means anything that is transmitted would be treated by security as if it was plain text. No sensitive information would ever be transmitted across any channel that isn't PHYSICALLY secure.

Which means Encryption by RAW just doesn't work. It either needs to be harder to crack or you might as well pretend it doesn't exist.



In game, however, Encryption is not meant to be something that stops a hacker... it is merely a speed bump, meant to slow them down... and in this regard, it works out well... if a random burst transmission lasts for exactly 3 seconds, and it is randomized as to repetition, then the chances of actual interception and decryption is very low (due to Scan/Sniffer and Decryption Intervals)...

If the data stream is constant, then you are not generally securing your system via Encryption (In Game Remember), you are probably using a DataBomb on the access port that will catch anyone that hacks the port without checking the port (very useful that, as you can attach databombs to devices, and if you have a chokepoint that everyone must pass through, requiring verification, then it will tend to catch many hackers unaware... Always check the Port before accessing it is a mantra that should be used by all hackers) and the interior of the node is protected by IC and Spiders... the more hardened the system the more IC involved... and the ultimate level of protection being a system that is not even on the Matrrix, but is a secured and offline system, necessitating a physical intrusion to actually obtain access to the system...

That is how the game handles this... Is it factual?... Not in any way that simulates what the world looks like today, but that is okay... it is a game, and works for what it does... The key is that you just need to not worry that it is not accurate... once you can get past that, everything else works out fine...

Keep the Faith
kzt
QUOTE (nezumi @ Jan 1 2010, 10:49 AM) *
There are reasons why one-time pads are not used in the real world. You could use it for setting up your radio network or your drone network (maybe), but not for normal decking operations.

The requirement that the one-time pad is as large as the traffic being sent makes one-time pads kind of annoying for applications like something sending a continuous video stream.
kzt
QUOTE (tete @ Jan 1 2010, 11:01 AM) *
I would like the time to be more realistic (dont get me wrong it can be a bit movie like by not taking years or being impossible to break in, but no hacking the pentagon in 30 seconds). I'm not talking about having a dungeon crawl. For example the hacker needs to control the security cameras, we'll say there is no encrypted tunnel but there is a key needed to get on. So the Hacker tells everyone it will be 30 min for a common phrase dictionary attack. He can still move around and do other things, the software is doing the work and will notify him when it completes or gets on but now if they are inside the building the team has to stay hidden for 30 min.

Cameras and security hardware need a power feed. Hence they are logically not connected via wireless unless the site being protected is a giant microwave oven. In which case the team is going to have some very serious issues in a few minutes.....
Sengir
QUOTE (Rotbart van Dainig @ Dec 31 2009, 06:05 PM) *
That's not a problem of encryption, though, but a general one. wink.gif

Sure, essentially you are just asking a friend (who can relay that question to another friend) "do you know that guy and think he's legit?".
RunnerPaul
QUOTE (kzt @ Jan 1 2010, 03:22 PM) *
The requirement that the one-time pad is as large as the traffic being sent makes one-time pads kind of annoying for applications like something sending a continuous video stream.


Ah, but remember, this is SR4, the edition that said you've always got enough storage for everything! ohplease.gif
Smokeskin
QUOTE (nezumi @ Jan 1 2010, 06:49 PM) *
There are reasons why one-time pads are not used in the real world. You could use it for setting up your radio network or your drone network (maybe), but not for normal decking operations.


The reason one-time pads aren't used in the real world is because public key encryption is practically unbreakable. That isn't true for SR.


QUOTE (kzt @ Jan 1 2010, 09:22 PM) *
The requirement that the one-time pad is as large as the traffic being sent makes one-time pads kind of annoying for applications like something sending a continuous video stream.


Want to transmit 10 hours of encrypted video feed? Your one-time pad takes up as much storage as the 10 hours of video would. Which is completely trivial in SR.
kzt
QUOTE (Smokeskin @ Jan 1 2010, 02:42 PM) *
Want to transmit 10 hours of encrypted video feed? Your one-time pad takes up as much storage as the 10 hours of video would. Which is completely trivial in SR.

Want to manage 300 cameras that transmit continually, and are on drones you want to control? You need at least 600 one-time pads, and you need to be able to get physical access to the drones to install the pads. Not to mention that resynch can be real bitch when you have a dropped byte...
Draco18s
QUOTE (Rotbart van Dainig @ Jan 1 2010, 07:30 AM) *
Strong cryptography means strong identification, having severe implications for the whole setting - say goodby to Fake SINs, for starters.


Fake SINs are neigh impossible for a PC to make (takes an extended test measured in 3 month intervals, IIRC), but buying one takes an interval of weeks (and cost only a few grand--it is in fact cheaper to get 10 rating 6 SINs than it is to buy a car).

There's already a disconnect there as to how the people who make fake SINs manage to do so while the PCs can not. The cost and interval implies that takes a few days to a couple weeks for these organizations to crank out a new SIN for someone (would you charge $4000 for 9 months worth of highly illegal work? No. Would you charge $4000 for a week's worth of highly illegal work? Hell yeah you would).

You can implement strong cryptography without breaking SINs:

The organizations that make the SINs have a near-permanent backdoor or en/decryption keys they can use to the dozens of institutions that hold SIN record data. The reason it takes them days to weeks to generate a new SIN is because they still have to be cautious when entering those nodes to create the false data, the number of institutions the implant the data in, as well as insuring that if they have to get a new key/backdoor because the one they had stopped working, they have the time.
Sengir
QUOTE (Smokeskin @ Jan 1 2010, 10:42 PM) *
The reason one-time pads aren't used in the real world is because public key encryption is practically unbreakable. That isn't true for SR.

OTPs would be superior to other forms of encryption in any way. Faster (just shifting letters), provable secure, usable as stream or block cipher depending on what you need...


There is exactly one reason why OTPs are not used, the already discussed problem of exchanging (and storing) keys which are the same size as the data you want to transmit. In practice, this means using OTPs requires good advance planning, because creating and exchanging an OTP once you already have something to transmit would be completely pointless. If there is a safe channel to transmit the pad, you might just as well transmit the data over that channel, since both are exactly the same size. Similarly, if the OTP used to encrypt a file can be stored safely, that storage might as well be used for the original file.

If we ever got around those problems (quantum cryptography offers some hope), that would be the holy grail of cryptography.
tete
QUOTE (kzt @ Jan 1 2010, 09:24 PM) *
Cameras and security hardware need a power feed. Hence they are logically not connected via wireless unless the site being protected is a giant microwave oven. In which case the team is going to have some very serious issues in a few minutes.....


It was just an example not meant to be a rule and I think that all I can say without being really careful with my words.
Smokeskin
QUOTE (kzt @ Jan 1 2010, 11:37 PM) *
Want to manage 300 cameras that transmit continually, and are on drones you want to control? You need at least 600 one-time pads, and you need to be able to get physical access to the drones to install the pads. Not to mention that resynch can be real bitch when you have a dropped byte...


I don't see drones being a problem - they'd need refuelling way more often than they run out of storage for OTPs. Something dumb and remote like a camera would be problematic.
Smokeskin
QUOTE (Sengir @ Jan 2 2010, 12:51 AM) *
OTPs would be superior to other forms of encryption in any way. Faster (just shifting letters), provable secure, usable as stream or block cipher depending on what you need...

There is exactly one reason why OTPs are not used, the already discussed problem of exchanging (and storing) keys which are the same size as the data you want to transmit.


You can twist it around all you want. There is exactly one reason OTPs aren't used, and that's because public key cryptography is secure enough. In SR, that sort of encryption can be broken easily.

The people in SR have two choices: accept the hassle of OTPs, or run with effectively no encryption.

If you all want to continue arguing that security-conscious people would rather run with protocols open to any newbie hacker than bother with securely exchanging some files with random data, then go ahead. But you have to admit, it is a pretty damn unrealistic approach. "Yeah, the runners got away with our prototype because they compromised our drones. But what do you want us to do, load a one-time pad into each of them once a day?"

Sengir
QUOTE (Smokeskin @ Jan 2 2010, 11:07 AM) *
The people in SR have [tl]two[/lt] three choices: accept the hassle of OTPs, or run with effectively no encryption, or use the magic SR encryption.

Fixed wink.gif

QUOTE
If you all want to continue arguing that security-conscious people would rather run with protocols open to any newbie hacker than bother with securely exchanging some files with random data, then go ahead. But you have to admit, it is a pretty damn unrealistic approach. "Yeah, the runners got away with our prototype because they compromised our drones. But what do you want us to do, load a one-time pad into each of them once a day?"

...and half an hour before the end of the drone's duty cycle some runners come in and the resident spider realizes he can't jump into the drone because the OTP is nearly "drained". Ooops.
I might also point out the Unwired section on simsense, which says that raw simsense recordings are HUGE and require "expensive storage", so putting sufficiently large pads into every drone and maglock would be complicated to say the least.
Draco18s
QUOTE (Sengir @ Jan 2 2010, 07:45 AM) *
...and half an hour before the end of the drone's duty cycle some runners come in and the resident spider realizes he can't jump into the drone because the OTP is nearly "drained". Ooops.


Or you have a week's worth at one time and every day you add on another days worth to the end.

Fixed.

Also, what "magic SR encryption"? The SR Encryption we have is option 1: effectively no encryption at all.
Rotbart van Dainig
QUOTE (Draco18s @ Jan 2 2010, 02:54 PM) *
Or you have a week's worth at one time and every day you add on another days worth to the end.

A weeks worth of what? Raw, hot simsense? Don't think so, see Unwired.
QUOTE (Draco18s @ Jan 2 2010, 02:54 PM) *
The SR Encryption we have is option 1

Nope, see SR4A and Unwired: Said encryption needs to be beaten before a transmission can be recorded, a file downloaded, or a device accessed.
Draco18s
QUOTE (Rotbart van Dainig @ Jan 2 2010, 08:04 AM) *
A weeks worth of what? Raw, hot simsense? Don't think so, see Unwired.


A week's worth of one-time pads.

A OTP's size is equivalent to the data being encrypted, therefore, all you need is 48 hours of "normal use" + 24 hours of "intense use" stored in the drone at any one time which will cover your ass for....

You guessed it. 24 hours.

And if you're adding onto the back what was used off the front every 24 hours, you'll always have 24 hours above your intended cycle.

QUOTE
Nope, see SR4A and Unwired: Said encryption needs to be beaten before a transmission can be recorded, a file downloaded, or a device accessed.


Doesn't matter if the encryption takes minutes to break. If it takes minutes then you might as well not be doing it (or doing something trivial like bit shifting, for a real world comparison). Encryption works only when it takes hundreds upon hundreds of times more energy to decrypt it than to destroy the Earth (several hundred million-billion-billion joules).
Sengir
QUOTE (Draco18s @ Jan 2 2010, 02:42 PM) *
A week's worth of one-time pads.

...which, as you said, has exactly the same size, and, as Unwired says, requires giant ammounts of memory. Far more than the "enough for everyday use" umbrella rule provides...

QUOTE
Doesn't matter if the encryption takes minutes to break.

In play it often does.
Draco18s
QUOTE (Sengir @ Jan 2 2010, 09:14 AM) *
In play it often does.


No, it really doesn't. If you're hitting a place you're hacking in before you hit it. Admin level access to security, which includes the drones. You set up your back door, you hit the place, the rigger tries to hop into the drone and your hacker fights him for control of the network before he can.

Done, done, and done.
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