Secure communications?

[SpaceBadger]

We just had a bit in SBRD in which the characters on shipboard are arranging for laser communication with a character on a moon 12 million km away, to keep their discussions secure.

After posting that, it occurred to me that with laser beam spread over that distance, it might not be too difficult for someone else to also have a receiver in the path of the beam, so to make it actually secure they need encryption.

Problem is, these people have been out of touch for some period of time, so would not have been able to share any encryption keys.

Would someone more knowledgeable than I about public/private key encryption answer a couple of questions for me?

1) Would it work for them to just exchange their public keys in the clear, then be able to encrypt from that point forward, or would that also allow any listener to decrypt as well?

2) Would it work for everyone just to use their commcode as their public key, so no need to even exchange? Or is there some other component that must be exchanged other than the public key?

 

[Lycanorukke]

1) Would it work for them to just exchange their public keys in the clear, then be able to encrypt from that point forward, or would that also allow any listener to decrypt as well?

When a 'public' key is generated, at the same time a 'private' key is generated.
A transmission is encrypted using the public key, and (theroetically) only the person with the matching private key and decrypt it.

Fred generates a public/private key pair.
Fred transmitts public key to Sue
Evil villian can see the public key.
Sue writes a message and encrypts it using Freds public key.
Sue transmits the message.
Evil villian intercepts message.
Fred decodes the message using his private key
Evil villian cant decrypt the message as he doesn't have Freds private key
Sue can't decrypt the message once she has sent it, even though she wrote it. Only Freds private key can do that

The main catch is that the system can be brute forced cracked, and with high tech computers you could crack simple keys very fast. There are also other mathematical tricks which can be used but they tend to be specific to certain types of encryption program.

Of course if they are using a common standard bit of software 'out of the box' it is possible it has already been 'cracked' by someone. Or if they are clever they arrange a 'man in the middle' attack (villian captures the public key transmission, makes his own keys, and re-transmits so Fred and Sue think they have the others public keys, but in reality the villian is 'relaying' the messages). That way the villian interepts the message, reads it, re-encrytps and transmits it on.

2) Would it work for everyone just to use their commcode as their public key, so no need to even exchange? Or is there some other component that must be exchanged other than the public key?

No other components need be exchanged. However I doubt a public com number would suffice as a key. The prevent easy brute force attacking you need long numbered keys. Current PGP is around 256 bits are people are looking at 512, so with H-tech massively parallel computers you would need massively long numbers. I doubt even spacers could remember a multi-mega bit "phone number".

On edit: My party used something like a book cipher. They all kept an old ratty copy of 'The scouts manual' or 'Tourists guide to Regina' (or some other obscure boring book) and then transmitted strings of numbers corresponding to words in the book. Unless evil villian knew about the books they couldn't decrypt the number strings. A dedicated crypto computer could probably crack it (one pre loaded with common books to compare with), but in emergencies against ordinary opponents it was fine.

 

[SpaceBadger]

OK, so if I understand your example, the answer to Q1 is Yes, but with a few weaknesses?

So they could just exchange public keys in their first comm, then after that use encrypted comms over the public system. Using the laser to restrict the signal is just an added bit of security to limit potential listeners.

Thanks!

 

[tjoneslo]

OK, so if I understand your example, the answer to Q1 is Yes, but with a few weaknesses?

So they could just exchange public keys in their first comm, then after that use encrypted comms over the public system. Using the laser to restrict the signal is just an added bit of security to limit potential listeners.

Thanks!

If you are using a computer controlled communications system, the "first comm" to transmit (and acknowledge) the public keys and establish the secured communication channel can be automated. If you assume this, there are several complex processes regarding establishing secured communications which ensure both people at either end are talking to the people they intend to. And not any bad guys.

The term you are looking for is called a "man in the middle attack" in the security realm. This is a well studied problem in secured communications over a channel (like a radio) which may have others listening in.

I generally assume by the 57th century, establishing a secure, encrypted channel over a pair of communicators is a solved problem.

 

[Lycanorukke]

OK, so if I understand your example, the answer to Q1 is Yes, but with a few weaknesses?

So they could just exchange public keys in their first comm, then after that use encrypted comms over the public system. Using the laser to restrict the signal is just an added bit of security to limit potential listeners.

Thanks!

Sorry for rambling on, it is a painfully mathematically complicted subject under the hood.

But if they are worried about Joe Public, the KeyStone Kops, or Billy Bob the pirate listening in, the keys would be fine. If they are worried about a spook agency listing in, it could be more problematic.

The other is the tech difference. If they are using a TL 10 encryptor, someone with a TL15 decryptor woud probably laugh at them. If they use a T-15 encryptor, I doubt a T-10 decryptor would crack it in a 100 years.

 

[Vladika]

Cyphers can, sooner or later, be broken. Codes can not. In the above example, the scout manual was used as a "one time pad". These are still considered one of the safest methods. It is random and even can have successive substitutions within. It requires both parties to have identical copies.

This can be a problem but both parties can use a "code" based on a shared common experience or understanding to mutually establish what common text to use. It isn't hard to do if both have even a rudimentary understanding of the process.

Also, does it have to hold up for a few days, hours, weeks, months, years or forever? If it doesn't matter if it is cracked after a certain time then no real problem.

 

[aramis]

OK, so if I understand your example, the answer to Q1 is Yes, but with a few weaknesses?

So they could just exchange public keys in their first comm, then after that use encrypted comms over the public system. Using the laser to restrict the signal is just an added bit of security to limit potential listeners.

Thanks!

just remember: the more often given key is used, the more data is available to analyze, and the more likely they can crack it.

Also, you don't want to make the public key public, either. Given the public key, interceptor guy can run certain known samples, analyze the output, and engjneer a private key from it.

 

[tjoneslo]

just remember: the more often given key is used, the more data is available to analyze, and the more likely they can crack it.

Also, you don't want to make the public key public, either. Given the public key, interceptor guy can run certain known samples, analyze the output, and engjneer a private key from it.

Right, with an automated system the connection protocol encrypts a seed value, then the comm system at either end generates an symmetric key based upon the seed value using a different encryption scheme. And then automatically generates a new key periodically. For the truly paranoid you would do this for every packet of data sent. And each encrypted packet contains updated values for encryption key seed generated from a true random number generator.