JSON makes an excellent format, and JSON-RPC has already figured out the RPC-ness of it. There is already a JSON::RPC::Common on cpan as well. One nice side effect of JSON is that it also makes it easy to web-ify things later since JSON is already spoken in the browser environment.

I'd like to assume that my non-privileged client has been completely hacked, so I want to make it as hard as possible for the baddies to crack open the privileged process. I want to pretend bad guys can send anything at all down the socket at my privileged process.

If the client has been completely hacked, what is to stop the bad person simply finding and copying whatever obfustication you are implementing ?

As far as the framing of each message is concerned, I would:

• have a message type field, so that you can change or improve things in future.

• pack the elements together using: $data = pack((n/a*)*, @elements). It's up to you whether you treat those as name/attribute pairs...

• prefix that packed data with its length and type, and append a 32-bit CRC (String::CRC32):

  $message = pack('n', $type) . $data ;
  $framed  = pack('N', length($message)) . $message . pack('N', crc32($message)) ;

if the CRC passes, it's likely your message is intact, and you can unpack it. In the unlikely event of a CRC failure... I'd log it and close the connection. If you wanted to get fancy, you could have an error message type, and send one before closing...

I guess you have some sort of password authentication when the client connection is established ? What I would do is as follows:

• add a NONCE to the message:

  $message = pack('Nn', $nonce, $type) . $data ;

  where the NONCE is a random 32-bit number.

• now for the authentication step I would send an authentication type message to the server, where the data portion is a TOKEN = MD5(password XOR NONCE).

  When the server responds to the authentication that message will also contain a NONCE. Both ends should compute and remember SEED = MD5(password XOR NONCE). The SEED is now a shared secret, based on the password.

• for each message I would take MD5(SEED XOR NONCE) XOR that with the $data part of the message after having taken the 32-bit CRC. (Of course, this step must be omitted for authentication messages.)

  This is by no means a strong encryption ! But it will take a lot more than casual interest to decrypt a message, and each one is XOR'ed with a different "key". However, in order to create a fake message, you need the current session's SEED... which is hard. The SEED changes for each session, so replay attach is also hard. (To protect against replay attack during a session you could introduce a sequence number in each message -- starting from a random value at the start of each session.)

  Because the CRC is taken before the "encryption", the CRC will fail if the data is incorrectly encrypted.

If the client is so completely hacked that a bad person can find the current SEED while a session is in progress... then you have a very serious problem. You could limit the damage by requiring periodic re-authentication -- which requires the password, which one assumes the bad person doesn't know. Beyond that... I don't know -- it looks like an almost impossible requirement (and I guess that requiring the password for every transaction would be ineffably tedious.)

Although this is worthy advice, soundly presented ... nothing whatsoever at all to disagree with here ... the overwhelming thought for me is:  this has got to be something that has been done before. Secure IPC transport mechanisms already exist. As time passes, I find myself more and more reluctant to “implement” anything new if I can possibly, possibly avoid it.

Vacuum CPAN first. Always.

Does this make sense?

Not really. The only differences between the encoded version and the unencoded version are:

• The characters you used as delimiters;

  '=' & "\n" versus ':' & "\n".

• The character values you can transmit.

  With the encoded version being far more restrictive, without really making anything more secure. It could also come back to bite you if you suddenly have the need to deal with data elements that contain punctuation.

  Eg c:\... or firstname.lastname@someplace.com and many others.

• The time you spend encoding and decoding.

Is there a better way to do this?

1. If you are looking to hide your stuff from the bad guys, use proper encryption.
2. If you're looking for a reliable protocol, prefix your transmissions with a count value.

   This has many advantages. Being able to read a set number of bytes to get the count that tells you how many bytes to wait for on the next read can be a real boon to timelyness.

   Look at the n/a* pack template for one way to do that.

I think you missed the part where the keys and values are base64'd as part of the serialization. Which actually increases the things that can be transmitted easily, and improves robustness because the payload can't be confused with the framing.

So while I agree with the principle of not reinventing wheels, especially when security is on the line, pileofrogs isn't as misguided as all that.

Now you point it out, you're right++.

I got hung up on the "64 characters" bit and completely forgot that the input to the encoding process can contain any byte values.

That said, I still much prefer length prefixing (via pack 'n/a*' etc.) which also allows the data packet to contain all byte values, but has the added advantages of:

• 4(or 2 or 1)-bytes/per packet transmission overhead rather than 37%.
• Negligible encoding/decoding overhead.
• The ability to read for just what is required rather than rely on buffering and buffer management.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

-sam

1. The client gets hacked
2. Someone listens on your network
3. Someone hacks the storage on your server
4. Someone hacks the server app itself

Risk 1 is minimized through strong authentication methods, and minimizing the amount of data that the client actually receives.

Risk 2 is minimized by encrypting traffic between systems; see Crypt-SSLeay

Risk 3 is minimized by encrypting the data store. I'm not enough of an expert to suggest a specific solution.

Risk 4 might be minimized by using a compiled language, and including code that checksums the binary when it first runs.

Personally, I think that the risk of 4 is so low, that everyone but government spy agencies can probably ignore it -- and they should be using a secure operating system that does that kind of thing automatically. For us mortals, risk #2 is the highest; if you are legitimately scared enough that you need to do more than #1 and #2, you probably shouldn't be using uncompiled Perl because of the risk that someone would read the source code and be able to reverse-engineer your data.

My general take is:   “dictum ne agas:   do not do a thing already done.”

You need to be able to avail yourself of CPAN, all the way. JSON (or XML..SOAP) is a good, reliable way to freeze and thaw a message. Encryption (public or private key) is also readily available. What you really want here is “an encrypted transport layer,” presumably in the form of a Perl object, that provides all the rest of your application with reliable, authenticated message-passing while concealing all of the plumbing behind a nice sheetrock™ wall. I'm sure that this has been done before.

Basically, “this is yet-another RPC requirement, nothing more.” Yeah, it's gotta be secure but “ hey, there's nothing new about that, either.” So you're looking at research-time, not coding time:   “finding the right shelf.”

There is a term for what you are attempting:

Security through Obscurity

...and it doesn't work. It's not even a halfway good idea; there is no partial payoff for partial effort. By making it difficult for a human to read you are simply setting up an interesting (or not-so-interesting) challenge for a would-be hacker. Without actual encryption, authentication, certification, etc. you gain absolutely no security from this approach.

However the statements you made are a bit confusing:

>I'd rather do something more secure.
>(note: I'm not encrypting. I'm trying to make it really hard for the privileged process to miss-interpret the message it receives.)

Perhaps security is not what you are after at all?

If you are only trying to prevent malformed commands from causing your application to crash, there is a very simple rule: don't execute anything sent in the command. Define all actions the application can perform in the server side code and simply allow the remote commands to trigger those actions in safe, meaningful sequences. If you need data from the user, don't use it directly, translate it into something pre-defined and use that. Read about taint mode for more about how to not execute anything that came from that dirty/evil/hacked outside world. The basic concept of taint mode is "There is no five-second rule." If it has ever touched the outside world, wrap it in a napkin and throw it away.