StarDestroyer.Net BBS

So, can I respond to your little diplomatic fleet.

I am looking forward to some gunboat diplomacy. Quite literally, my gunboats are going to be diplomats. Woo-hoo!

Dark Hellion wrote:So, can I respond to your little diplomatic fleet.

I am looking forward to some gunboat diplomacy. Quite literally, my gunboats are going to be diplomats. Woo-hoo!

As long as they actually talk, fine. Consider this a "Get Out Of Annihilation Free" card.

Of course they are going to talk. I mean my ships are the crew/crew are the ships. Don't expect diplomatic grace, but they have more processor power than anything else I field, so they will deal appropriately.

Hopefully nt01jones and I will finnish and de-retcon (recon?) that speechy post from the 'retconned posts' thread. Since no one else heard what was said there it isn't relevant to anyone else's plotlines.

Beowulf wrote:it may take a while before they can manage to break the encryption.

If we're being realistic, you can't. I know it gives things a nice WWII feel to have naval encryption susceptible to codebreaking, but this is a non-issue for even contemporary military forces unless there's a serious operator error. For conventional encryption brute-force times get steadily worse as computing power increases (because encrypt/decrypt is roughly linear with key length whereas breaking keys is exponentinal with key length) - and current consumer-grade encryption (e.g. AES-256) is already unbreakable by all the world's computers operating for the predicted lifespan of the universe.

But no military users are even going to bother with that for comms between friendly forces - one-time pads are unbreakable even with infinite computing power, because there is an equal probability of the message decrypting to every possible message of the same length. This applies for all spacegoing powers using technological communication - though you can still do traffic analysis (in this case, potentially work out where the signal was targetted at). This is already practical for the average contemporary civillian if you can exchange USB keys with the person you want to communicate with prior to using the untrusted channel - you can send data up to the size of your one-time pad before theoretical unbreakability starts to errode. Military ships will do the equivalent of this every time they dock.

If you want to read comms, infiltrate your spies into the enemy power and steal their keys or subvert their comms network. This is fairly plausible for diplomatic comms, but pretty tricky for naval comms; it's equivalent to the USSR trying to break the ELF system the US uses to communicate with SSBNs. If we're blatantly ignoring reality, I'd suggest that only powers with points in 'comms analysis' get magic encryption breakers - in WWII the British only managed to defeat Enigma with a major, unprecedented comittment of personnel and resources. I can only assume the Kitaka are still using 1970s DES for religious reasons and that they will be unpleasantly surprised to discover that the rest of the galaxy is being sensible and using OTPs.

That said it won't make any difference in this case since you can easily guess what the message content was.

Um, one time pads are just that, one time. Simply giving them new keys at dock won't work, because you'll only have HQ to ship comms (or one ship to another). There are ways to do one time pads on the fly without being detected (lasers in the void), but it's still a bit of a hassle to communicate between several ships. Remember, transmission of the key is the weakness of the one-time pad.

Hotfoot wrote:Um, one time pads are just that, one time. Simply giving them new keys at dock won't work, because you'll only have HQ to ship comms (or one ship to another).

No, that works fine. In a simple system you generate one OTP per transmitting node. You hand that out to all nodes in the network. Every time a node transmitts, it prefixes the transmission with an index into its OTP. Until it runs out of OTP bits, everyone in the network can decode stuff coming from that node. In practice this is complicated by the fact you don't want one captured ship to compromise your whole network - but then you can have a unique pair of pads for every possible node pairing in a one thousand node network with only twice as much storage per-node and a million times as much initial entropy. With moderately futuristic storage tech, this is practical for even huge comms volumes (if you can log it, you can OTP-secure it using an equivalent amount of storage). Key distribution when ships keep putting into port at different times is still hassle, but manageable hassle; you just have a sequence of pads per nodes with known expiry dates. This is basic encryption theory - and yes I have designed and implemented plenty of software encryption systems, though not nontrivial encryption algorithms (I'm not a professional cryptographer after all).

There are ways to do one time pads on the fly without being detected (lasers in the void),

If you mean laser-based quantum cryptography, that's probably a non-issue militarily as it isn't FTL and at tactical ranges you can probably be sure no one is directly between your ships to pick up the signal.

Remember, transmission of the key is the weakness of the one-time pad.

The /only/ weakness. The way to break a OTP system is to compromise the keys, which have to be distributed by military couriers. Of course it is pretty trivial to encrypt with a conventional symmetric block cypher (or indeed, several pipelined cyphers, paranoid people already do this) and then use an OTP as the final stage - if you're really paranoid, you'll do that and use diverse distribution mechanisms for the keys for each stage. People who put points into 'comms security' might represent that, though having their comms not give away ship positions and not have a verifiable direction would be a lot more useful.

While we are talking about Hacking and codes...

What are the feleings on Hacking whole starships? I'm soon going to have a ship coming out with 40% of its internal space devoted to a computer system designed to attack and take control over other Vessels. RUDI himself IS a computer and can 'hack' faster then virtually anyone else in the game.

Crossroads Inc. wrote:While we are talking about Hacking and codes...

What are the feleings on Hacking whole starships? I'm soon going to have a ship coming out with 40% of its internal space devoted to a computer system designed to attack and take control over other Vessels. RUDI himself IS a computer and can 'hack' faster then virtually anyone else in the game.

No.

Aw your kidding.. No? What about slightly disabled ships? Crippled shis? Near death ships?

Crossroads Inc. wrote:What are the feleings on Hacking whole starships? I'm soon going to have a ship coming out with 40% of its internal space devoted to a computer system designed to attack and take control over other Vessels. RUDI himself IS a computer and can 'hack' faster then virtually anyone else in the game.

Hah, IMHO this one probably is realistic, in that software designed by typical organic sapients is monstrously awful by AGI standards and probably quite trivial to penetrate. However if we had realistic seed AI the galaxy would long since have been taken over by an Agressive Hegemonizing Swarm Entity (to use the Culture term ).

Crossroads Inc. wrote:Aw your kidding.. No? What about slightly disabled ships? Crippled shis? Near death ships?

Do you want to consider me applying this evenly, when I point out that the Wanderers are supremely powerful Psychics who can interface with machine intelligences?

Really folks, no intelligently designed ship will be vunerable to this.

SirNitram wrote:Really folks, no intelligently designed ship will be vunerable to this.

For a realistic treatment of this, see the opening chapter of A Fire Upon the Deep by Vernor Vinge - the humans know their software can be trivially penetrated by strong AI, and only get as far as they do by turning off all their sensors and comms while they run away. They still die, because a sensor monitoring subroutine had already been compromised by the AI before they realise it's hostile. That universe has accurate seed AI, and it only has human-comprehensible species and plotlines because a) the author invokes magic physics to make it impossible for (seriously) transhuman intelligences to enter the galaxy's habitable zone and b) the author invokes writer fiat to restrict the lifetime of extragalactic Powers.

But clearly that level of realism isn't appropriate for a setting where the main objective is to have fun and we have coal-powered battleships flying around firing off magical tuning-fork cannons. I only objected to the breakable encryption because it contradicts real life and basic logic, not esoteric physics and AI theory.

The problem with OTP is that you really need to have a pad for each pair of transmission nodes. This increases the number of keys required in a factorial progression. This becomes a nightmare of security and management as the number of recipients gets large enough. Using asymmetric cryptography and well developed PKI, you can greatly simplify the problem to control of the private key. With a sufficiently large key, you can make it effectively unbreakable. By doing so, you can even manage to have secure comms down to the individual level, which would be effectively impossible with a OTP solution. It would also allow authentication that a given individual actually wrote a given message.

Beowulf wrote:The problem with OTP is that you really need to have a pad for each pair of transmission nodes. This increases the number of keys required in a factorial progression.

The number of unidirectional links in a fully connected network is n * (n-1). This is a quadratic progression, not a factorial one. The later would be unmanageable, but the former is quite manageable up to thousands of nodes for long multimedia messages, millions for short text messages only (without assuming molecular storage, which may well make it practical for all personal communication).

Using asymmetric cryptography and well developed PKI, you can greatly simplify the problem to control of the private key.

Asymmetric cryptography may be useful in distributing symmetric key updates to ships, but it's restricted by the fact that there are no real-time connections here, just packetised communication with multi-hour latencies. Symmetric cryptography with sensible key management is probably better, but both these techniques are vulnerable to being broken by quantum computers (though generally you need a plaintext encrypted on the same key unless you invoke near-literally magical computers). Back in reality we're still not sure if quantum computing on that scale is physically possible, but in a universe where telekinesis and magic tuning fork guns exists I'd go with a system that's unbreakable by basic logic rather than merely needing a near-infinite* amount of computing power.

* Strictly an oxymoron of course.

By doing so, you can even manage to have secure comms down to the individual level, which would be effectively impossible with a OTP solution.

For literally unbreakable and verifiable personal-scale comms you'd layer the individual-scale encryption and signing on top of the ship or base's OTP stream.

Starglider wrote:No, that works fine. In a simple system you generate one OTP per transmitting node. You hand that out to all nodes in the network. Every time a node transmitts, it prefixes the transmission with an index into its OTP. Until it runs out of OTP bits, everyone in the network can decode stuff coming from that node. In practice this is complicated by the fact you don't want one captured ship to compromise your whole network - but then you can have a unique pair of pads for every possible node pairing in a one thousand node network with only twice as much storage per-node and a million times as much initial entropy. With moderately futuristic storage tech, this is practical for even huge comms volumes (if you can log it, you can OTP-secure it using an equivalent amount of storage). Key distribution when ships keep putting into port at different times is still hassle, but manageable hassle; you just have a sequence of pads per nodes with known expiry dates. This is basic encryption theory - and yes I have designed and implemented plenty of software encryption systems, though not nontrivial encryption algorithms (I'm not a professional cryptographer after all).

First off, any encryption system worth a damn doesn't give a shit if you get one key, or if you even know the encryption method. Standard public key encryption stands pretty damn well even if you scale it up, the need for one time pads is nonexistant for 99% of in-game transmissions. Add to that the fact that public key encryption can authenticate transmissions from being from a specific source, something very useful when people are trying to do all manner of sneaky things.

Meanwhile, one time pad transmissions over interstellar distances between multiple individual points is, well, not smart. First off, if someone misses a transmission, or accidentally uses a key to something they thought was a transmission, they're out of sync and effectively out of communication if they are under orders to only communicate on a "secure" channel. Meanwhile, it makes two-way conversation virtually impossible, unless you have every ship somehow using a different assigned frequency or some such bullshit.

Bottom line, it's so laughably easy to disrupt your proposed comms system that it would likely have never survived the design stage. But hey, that's cool, if you want a comms network that can be disrupted with a few bogus messages back and forth on the right frequency, feel free. I'm not about to stop people from making ill-advised decisions.

If you mean laser-based quantum cryptography, that's probably a non-issue militarily as it isn't FTL and at tactical ranges you can probably be sure no one is directly between your ships to pick up the signal.

Yes, but it's still only ship-to-ship comms, which is fantastic, but largely useless in certain situations, like when you need to transfer large amounts of data quickly over very long distances. One Time Pads are of very limited utility because of the difficulty in keeping the keys secret and in order. At close ranges (direct line of sight), sure, no problem, but over interstellar distances? Hah, yeah right.

The /only/ weakness. The way to break a OTP system is to compromise the keys, which have to be distributed by military couriers. Of course it is pretty trivial to encrypt with a conventional symmetric block cypher (or indeed, several pipelined cyphers, paranoid people already do this) and then use an OTP as the final stage - if you're really paranoid, you'll do that and use diverse distribution mechanisms for the keys for each stage. People who put points into 'comms security' might represent that, though having their comms not give away ship positions and not have a verifiable direction would be a lot more useful.

No, not the ONLY weakness, just the biggest one. The other problems are making sure that each party is using the same key at the same time and that the parties don't break the code by using the key again (like the Russians did back in the late fourties).

Bottom line, as far as I'm concerned, is this: Nobody has the ability to decrypt encrypted comms traffic in realtime. Period. Not even if you have 1500 points in Intel and the other guy has an Intel penalty. Certain things, like comms between ships in a formation with each other, secure facilities communicating internally, defense network signals to the command center, etc, are all likely encrypted via one time pad and cannot be spoofed externally. Use of one time pads over interstellar distances only really makes sense for intelligence agents and other such very important things, not for general comms traffic between ships in a fleet. This means that no, you don't get to put ALL your transmissions in one-time pad format, even if you've got 1500 points in counter-intel. If you don't want people finding out what you're saying, be more careful in how you say it, or just make plans that will be enacted faster than anyone could reasonably break your codes. It's not a difficult concept.

Obviously, human intelligence is still important, because that is the only way you will know what some transmissions contain. After all, how do you think a bug gets into an endpoint of a transmission? Be it one time pad or public key encryption, it hardly matters, because if you have the plaintext, you don't need to brute-force it.

Remember though, folks, that points in intel and counter-intel doesn't just mean progressively more badass encrypt and decrypt abilities, intel is much, much more than that.

As far as hacking ships...no. We've done the ship bonuses as is, that's it. Besides which, it's a retarded concept. As Nitram said, no intelligently designed ship would have ship-critical systems hooked directly to their communications sytems. Or have control systems that would accept some sort of crazy external commands from outside the ship. Much less computers that could hack enemy computer systems on the fly. We're not allowing realtime decryption, what makes you think you can manage a much more complicated task in realtime?

Feel free to waste your points on ships that do absolutely nothing though

Oh, and one more thing, if you seriously are suggesting having each node have the keys for legit transmissions to EVERY OTHER NODE, you've just created a massive security risk. All someone has to do is sneak into one node, compromise it, and viola, your network is fucked. Once you realize you've been compromised, you've got to completely replace ALL of your keys, period.

Meanwhile, with public key encryption, you just mark off one key as compromised, make a new one, and continue on with your life.

Starglider wrote:

Beowulf wrote:The problem with OTP is that you really need to have a pad for each pair of transmission nodes. This increases the number of keys required in a factorial progression.

The number of unidirectional links in a fully connected network is n * (n-1). This is a quadratic progression, not a factorial one. The later would be unmanageable, but the former is quite manageable up to thousands of nodes for long multimedia messages, millions for short text messages only (without assuming molecular storage, which may well make it practical for all personal communication).

Err... oops? Still, the point is that PKI requires only O(n) keys to be distributed, and which can itself be done in a distributed fashion, as opposed to O(n^2) keys.

Using asymmetric cryptography and well developed PKI, you can greatly simplify the problem to control of the private key.

Asymmetric cryptography may be useful in distributing symmetric key updates to ships, but it's restricted by the fact that there are no real-time connections here, just packetised communication with multi-hour latencies. Symmetric cryptography with sensible key management is probably better, but both these techniques are vulnerable to being broken by quantum computers (though generally you need a plaintext encrypted on the same key unless you invoke near-literally magical computers). Back in reality we're still not sure if quantum computing on that scale is physically possible, but in a universe where telekinesis and magic tuning fork guns exists I'd go with a system that's unbreakable by basic logic rather than merely needing a near-infinite* amount of computing power.

* Strictly an oxymoron of course.

Uh? You use the asymmetric crypto to encrypt a symmetric key which is used to encrypt one message, and attach the encrypted key to the message. You can double encrypt the key if you need to authenticate who it's coming from as well as make it only decryptable by the recipients. You don't need to distribute the symmetric cipher keys. It also makes a chosen plaintext/ciphertext much harder, because it's nearly impossible to end up with two ciphertexts encoded with the same key. Combine with certain stenographic techniques, and you can make it such that any arbitrary number of plaintexts are actually possible. The only messages that need to be transmitted for key management are key revocation messages.

By doing so, you can even manage to have secure comms down to the individual level, which would be effectively impossible with a OTP solution.

For literally unbreakable and verifiable personal-scale comms you'd layer the individual-scale encryption and signing on top of the ship or base's OTP stream.

So, now you've distributed your base level keys to all your platoon leaders(or lower). How the heck are you going to secure them? That's quite possibly millions of key holders. It may even number in the tens of millions.

Well shit, I am going to apologize for the miscommunication on who I was declaring war on. For some odd reason (probably because I was posting on no sleep) I thought InnocentBystander was an NGTO member. Wow that was dumb.

I need to sleep a ton more and reread the current events. I've been noticing a bunch of mistakes I didn't see a couple days ago.

Note on my last post; this is getting a bit out of sync with the events going on down in Polish space, but I wanted to follow up on Crossroad's post implying the message has got to central NGTO space.

Beowulf wrote:Uh? You use the asymmetric crypto to encrypt a symmetric key which is used to encrypt one message, and attach the encrypted key to the message.

This is usually relevant in the sense of decreasing computing power requirements on current computers. Due to codebreaking compute power requirements scaling faster than encrypt-decrypt requirements with key length that likely is not irrelevant at this point of technological development, but there's the usual chained-algorithm improvement anyway, /if/ mathematically secure asymmetric algorithms are still available In general though asymmetric systems are nowhere near as theoretically secure as symmetric systems, so I would not rule out a total break of all viable asymmetric systems in a sci-fi settings.

However since you already have to distribute the private keys from the central source anyway, or send the public keys twice as far, the gains are marginal in a military application.

You can double encrypt the key if you need to authenticate who it's coming from as well as make it only decryptable by the recipients.

As opposed to connection-specific symmetric keys that require no additional effort to authenticate, though again military applications will have redundant authentication as well.

You don't need to distribute the symmetric cipher keys.

Distributing symmetric keys is no harder than distributing public ones if you have a secure channel to the ships at some point (which you will, with base-to-base comms). Using an asymmetric system of highly dubious theoretical security (which all known ones are, long term) and provable breakability given a moderate sized quantum computer and a plaintext is highly inadvisable in a universe containing apparently arbitrarily high and implausible levels of technology.

Combine with certain stenographic techniques, and you can make it such that any arbitrary number of plaintexts are actually possible.

All encryption systems have a number of possible plaintexts equivalent to the number of possible keys. The various ways (that I know of) of messing about with chaining and embedding to finess this work on any algorithm.

For literally unbreakable and verifiable personal-scale comms you'd layer the individual-scale encryption and signing on top of the ship or base's OTP stream.

So, now you've distributed your base level keys to all your platoon leaders(or lower).

No you would not, because the final stage encryption (and first stage decryption) occurs at the comms nodes interfacing to the inner network.

Hotfoot wrote:Meanwhile, one time pad transmissions over interstellar distances between multiple individual points is, well, not smart. First off, if someone misses a transmission, or accidentally uses a key to something they thought was a transmission, they're out of sync and effectively out of communication

This is literally nonsensical. You prefix every transmission with an index into the one-time pad. Why on earth would you rely on other nodes to keep track of where you are in your own pad? Or are you assuming everyone is sharing one giant pad, for no apparent reason and despite the express description stating otherwise?

Meanwhile, it makes two-way conversation virtually impossible, unless you have every ship somehow using a different assigned frequency or some such bullshit.

Say what? How are you coming up with this random nonsense? I'd already implemented OTP programs (using a floppy full of 'random' numbers no less - not for any real application of course) that didn't have these problems when I was 14.

Oh, and one more thing, if you seriously are suggesting having each node have the keys for legit transmissions to EVERY OTHER NODE, you've just created a massive security risk. All someone has to do is sneak into one node, compromise it, and viola, your network is fucked.

No, they have only gained the ability to impersonate that node and read messages addressed to that node - exactly what they would be able to do with an asymmetric system. Assuming you use link-specific unidirectional keys of course, which is the sane thing to do.

Starglider wrote:This is literally nonsensical. You prefix every transmission with an index into the one-time pad. Why on earth would you rely on other nodes to keep track of where you are in your own pad? Or are you assuming everyone is sharing one giant pad, for no apparent reason and despite the express description stating otherwise?

Hey dipshit, let's look at a real example: I get a legitimate transmission from ComSat A. The transmission is garbage. Now, am I using the right key now? Or did I miss a transmission earlier? Or, maybe, the transmission itself was disrupted by ECM, stellar radiation, or just a general computing error. Since your system relies entirely on using exactly the right key at exactly the right time, you are now fucked, and have to rely on other forms of encryption. Meanwhile, with a public key system you can simply ask for the transmission again without having to use an entirely new key every time. Let's ALSO remember that one time pads are really only 100% effective when the key is just exactly as long as the message. Otherwise, you get a crackable cipher, so now you're not dealing with just a set string of codes, but a ridiculously long cipher that is used in bit with each transmission, which of course makes being on the same page even more crucial.

Say what? How are you coming up with this random nonsense? I'd already implemented OTP programs (using a floppy full of 'random' numbers no less - not for any real application of course) that didn't have these problems when I was 14.

Kid, I don't give a shit what you did when you were 14. Unless you built a widespread encryption system that worked as you described, you can just shut the fuck up. Ten bucks your little project involved a single Alice and Bob, not multiples, am I right? Because you certainly don't seem to understand the actual limitations of the one time pad. Again, point to point, one time pads are fantastic, but widespread over a network? It's ridiculous. Especially given that obtaining the key in this instance will completely fuck the entire method of encryption on a level you don't seem to comprehend.

No, they have only gained the ability to impersonate that node and read messages addressed to that node - exactly what they would be able to do with an asymmetric system. Assuming you use link-specific unidirectional keys of course, which is the sane thing to do.

Except the work to fix the problem is massively larger with the one time pad method than the open key encryption method. You have to generate a new massive key for EACH NODE IN YOUR NETWORK. That's HOW many thousands, millions, or billions of nodes, exactly? By the way, how the fuck are you distributing these keys? Are you sending out a fucking ship to every god damned node in the network every time one of them uses up a key? Yeah, that's fantastically secure, isn't it? If you're transmitting them, guess what, Eve can listen in. Unless you're somehow transmitting them with ANOTHER one time pad, which is on the face of it retarded. The turtles do not go all the way down.

Meanwhile, the solution for fixing it in an open key encryption network involves a simple signal: blacklist all transmissions with key X. You don't even need to worry about further attempts at listening.

Starglider wrote:You prefix every transmission with an index into the one-time pad.

Hotfoot wrote:Hey dipshit, let's look at a real example: I get a legitimate transmission from ComSat A. The transmission is garbage. Now, am I using the right key now? Or did I miss a transmission earlier?

Missing a transmission has no effect.

Starglider wrote:You prefix every transmission with an index into the one-time pad.

Hotfoot wrote:Or, maybe, the transmission itself was disrupted by ECM, stellar radiation, or just a general computing error. Since your system relies entirely on using exactly the right key at exactly the right time,

No it does not.

Starglider wrote:You prefix every transmission with an index into the one-time pad.

Hotfoot wrote:you are now fucked, and have to rely on other forms of encryption.

No you do not. Your mental model is broken and you refuse to see it.

Meanwhile, with a public key system you can simply ask for the transmission again without having to use an entirely new key every time.

Which you can and would do here. For encryption purposes each part of the pad acts like a new key, but for management purposes you're continuing to use the same key until it expires.

Let's ALSO remember that one time pads are really only 100% effective when the key is just exactly as long as the message.

No, the one time pad needs to be equal longer than all the messages you want to send with it combined. Your mental model is broken twice. In practice you generate a petabyte or so of random bits from atomic decay, hand one copy to each node in a link and mark it as 'expires in 3 months'. As long as neither node is compromised (which will break any system) and they don't need to send more than a petabyte, communication will be perfectly secure. If you like you can implement a bidirectional connection by having one pad and each node start using it from a different end.

Unless you built a widespread encryption system that worked as you described, you can just shut the fuck up.

No, you can shut the fuck up as you are spouting nonsense and clearly haven't built any kind of large scale, in-production encrypted comms system at all, whereas I have.

Because you certainly don't seem to understand the actual limitations of the one time pad.

This is quite pathetically ironic.

Again, point to point, one time pads are fantastic, but widespread over a network?

They are not practical or worth it for point-to-point civillian communications. They work fine for up to thousands of nodes, given large capacity compact storage devices that can be securely distributed, or a completely secure backbone network.

Especially given that obtaining the key in this instance will completely fuck the entire method of encryption on a level you don't seem to comprehend.

Again with the blatantly wrong and tragically ironic. You either genuinely have no clue what you're talking about, or your mental model of how the technique is being applied is completely out of sync with all of the above descriptions and general common sense.

Except the work to fix the problem is massively larger with the one time pad method than the open key encryption method. You have to generate a new massive key for EACH NODE IN YOUR NETWORK.

You simply advance to the next key in the schedule. It is true that you can't locally generate and start using new OTPs, but if the situation is that bad you can simply revert to a less demanding cryptosystem. Yes, not having the ability to do this would be stupid, but no military ship is going to have that problem.

That's HOW many thousands, millions, or billions of nodes, exactly?

Thousands. I expressly noted that the system is impractical to implement to maximum single-node-compromise tolerance past about 1000s of nodes. You ignored that along with just about everything else.

By the way, how the fuck are you distributing these keys? Are you sending out a fucking ship to every god damned node in the network every time one of them uses up a key?

Keys need to be regularly supplied in advance, every few months should be adequate. When this isn't possible, that node can use a more space-efficient algorithm.

If you're transmitting them, guess what, Eve can listen in.

Which you wouldn't, because it's pointless, /unless/ you have a physically unbreakable channel to do so (for example a quantum encrypted fibre link in the real world - there may or may not be FTL equivalents in a given sci-fi universe). But if you can't get a briefcase securely from your fleet headquarters to your ships you have more serious problems.

Meanwhile, the solution for fixing it in an open key encryption network involves a simple signal: blacklist all transmissions with key X.

Which is exactly what you do with a symmetric system, OTP or otherwise. The only operational advantage of asymmetric encryption is that if the node's entire key schedule is compromised, then the node is recovered and sanitised, secure communications can resume without needing a new key supply - but of course this will exist as a backup mode in any milspec secure comms system, so is irrelevant as a reason not to use OTPs in critical applications.

Starglider wrote:

Starglider wrote:You prefix every transmission with an index into the one-time pad.

Missing a transmission has no effect.

Well gosh, I guess you're right. No effect at all. Unless you use the "please resend transmission" code to, oh, I don't know, break the cipher. How? "Resend transmission sent X time using index Y." "Resend transmission sent time Z using index Y." I will conceed that I missed that part of your previous posts and that it would solve the good old "where were we" problem on the face of it. Unless, of course, the prefix was corrupted in any way. In which case you're still fucked for that message. Remember that reusing the same place in the key IS A BAD IDEA. The Russians made that mistake once and ended up paying for it in the Cold War.

Which you can and would do here. For encryption purposes each part of the pad acts like a new key, but for management purposes you're continuing to use the same key until it expires.

That's fair, though you certainly did not make that clear in your initial posts. You still haven't dealt with the transmission problem, however.

No, the one time pad needs to be equal longer than all the messages you want to send with it combined. Your mental model is broken twice. In practice you generate a petabyte or so of random bits from atomic decay, hand one copy to each node in a link and mark it as 'expires in 3 months'. As long as neither node is compromised (which will break any system) and they don't need to send more than a petabyte, communication will be perfectly secure. If you like you can implement a bidirectional connection by having one pad and each node start using it from a different end.

Wow, way to pick nits. Nice backpedalling from "give out lots of keys", by the by. Yes, a massively long key will work, but you still have key transmission problems. Add to that you're sending out a ridiculous number of keys to a silly number of nodes, what, every three months now? Jesus, even if it was once a year, you're talking about a massive HUMINT security risk. Yes, compromising a node will break any system, but with your magical little system it's much harder to FIX, and the act of fixing it is itself another security risk. THIS IS THE PROBLEM WITH ONE TIME PADS. You have such a hard on for the fact that they're mathematically impossible to break that you've completely ignored the human element.

No, you can shut the fuck up as you are spouting nonsense and clearly haven't built any kind of large scale, in-production encrypted comms system at all, whereas I have.

Fantastic, good for you. Where's your magic one time pad system? Whatever else you've done doesn't mean shit here, pal, because this discussion isn't about whatever else you've done. By the way, did you, you know, build the entire thing? Like, by yourself? Did you? Or were you one of several specialist on a project who focused on his own specific task?

This is quite pathetically ironic.

Blah blah blah. Look, I can make useless one line posts too. Your transmission system is fundamentally flawed.

They are not practical or worth it for point-to-point civillian communications. They work fine for up to thousands of nodes, given large capacity compact storage devices that can be securely distributed, or a completely secure backbone network.

Securely distributed is perhaps the most glaring problem you have. You are describing a system in which the codes have to be physically transported from a central location to thousands of other points across interstellar space. Thousands, if not tens or hundreds of thousands of people are involved in this process.

Again with the blatantly wrong and tragically ironic. You either genuinely have no clue what you're talking about, or your mental model of how the technique is being applied is completely out of sync with all of the above descriptions and general common sense.

Oh, so you're saying that if you find out, two days after your latest code update that you've got a tapped line, that you DON'T need to send out thousands of ships to update the keys?

Because everything described says you DO.

You simply advance to the next key in the schedule. It is true that you can't locally generate and start using new OTPs, but if the situation is that bad you can simply revert to a less demanding cryptosystem. Yes, not having the ability to do this would be stupid, but no military ship is going to have that problem.

So...if the network is tapped...you just move to the next key in the system...from a set of keys that has been compromised? Or are you actually talking about sending out thousands of ships to fix the compromised node and then insert new keys?

By the way, I love how all of this is somehow some trivial thing, as though mobilizing thousands of starships to do maintenance on your comm network is this just massively trivial thing.

Thousands. I expressly noted that the system is impractical to implement to maximum single-node-compromise tolerance past about 1000s of nodes. You ignored that along with just about everything else.

I'm saying that even with thousands of nodes, it's impractical. What, are you going to call in your fucking fleets every time one node might be compromised? Or do you have a massive civilian fleet that mobilizes when you do this? If you have passable regular encryption, why waste massive amounts of money on this system?

Keys need to be regularly supplied in advance, every few months should be adequate. When this isn't possible, that node can use a more space-efficient algorithm.

That doesn't answer the fucking question. HOW DO YOU DISTRIBUTE THE MOTHERFUCKING KEYS?

Which you wouldn't, because it's pointless, /unless/ you have a physically unbreakable channel to do so (for example a quantum encrypted fibre link in the real world - there may or may not be FTL equivalents in a given sci-fi universe). But if you can't get a briefcase securely from your fleet headquarters to your ships you have more serious problems.

No, a single fucking briefcase does not magically refresh thousands of nodes, most of which are in deep fucking space acting as god damned relays. Try again.

Which is exactly what you do with a symmetric system, OTP or otherwise. The only operational advantage of asymmetric encryption is that if the node's entire key schedule is compromised, then the node is recovered and sanitised, secure communications can resume without needing a new key supply - but of course this will exist as a backup mode in any milspec secure comms system, so is irrelevant as a reason not to use OTPs in critical applications.

The difference here is this:

In an open key system, a satellite, one, can be looked at and fixed, the private key generated on the satellite and the public key sent back to the network. Now everything's hunky-dory again. One crew, one fix, no big deal.

Meanwhile, in order to fix YOUR system, you have to send out THOUSANDS of individual updates that have to be physically brought to each node, a process that has to happen with incredible efficiency in order to keep the network downtime from getting out of control.

Dark Hellion wrote:Well shit, I am going to apologize for the miscommunication on who I was declaring war on. For some odd reason (probably because I was posting on no sleep) I thought InnocentBystander was an NGTO member. Wow that was dumb.

I need to sleep a ton more and reread the current events. I've been noticing a bunch of mistakes I didn't see a couple days ago.

So thats why I thought you were declaring war on the Coalition...

Starglider wrote:lots of stuff

Unless someone proves P=NP, asymmetric keyed ciphers are not going to be intrinsically insecure. It's currently generally thought by computer scientists (though not proved) that P != NP. Their downside is that the keys generally have less entropy than symmetric ciphers. This doesn't matter much if a thumb sized device can hold billions of bytes. The beauty of PKI is that you don't actually need to distribute very many keys from a central source. You can use a distributed architecture to distribute them. Also, you don't need to keep the public keys secure. Revelation of the public keys does not hurt the security of the system as a whole at all. Thus, anyone outside the system can securely send a message to anyone inside, though not necessarily with authenticatability.

The problem with OTP is that you need to distribute O(N^2) keys initially, and then O(N) keys whenever a compromise is discovered, and then O(N^2) keys periodically. All of this needs to come from a central source. And needs to get to everyone securely. With PKI and asymmetric ciphers, you need to distribute O(N) keys initially, and O(1) keys when a compromise is discovered. There's no need to distribute keys periodically, though that is possible to do. Only half of the keys need to be securely transmitted, and only 1 key needs to be securely transmitted in a compromise.

The point I was getting with the arbitrary number of plaintext isn't just that you can have any number of plaintexts, but the stronger property of that the arbitrary plaintext look like valid plaintexts, which is not the case for choosing a random decryption key.

If you don't distribute keys down to the platoon level, then their comms suffer either from needing to have a symmetric key to communicate with base (and everyone else), or from being inherently insecure.

As far as quantum computers go, any of sufficient size as to be able to break an asymmetric cipher is also of sufficient size as to be able to break a symmetric cipher. See the previous point about lower entropy of asymmetric keys.

A further problem with OTP, as your describing your system, is that you can't remote authenticate. Alice sends a message to Bob. Bob wants to prove to Charlie that Alice really did send the message. To do so, he has to either say "Just trust me" or reveal the key.

Oh, and since when have you actually built a large scale cryptosystem? A OTP system that you use with your friends that was made when you were 14 doesn't count.