This content has been marked as final. Show 21 replies
I suggest you google for something like "encrypted UDP". You're surely not the first person to want to do something like this.
I think there are TLS implementations on top of UDP. Or as a primitive, worst-case, Q&D approach, you could just encrypt the data in each packet. That would surely be more secure than randomizing the order.
And as for "Self-devised encryption" in general, keep this in mind: Many brilliant minds--PhDs in mathematics and computer science--have dedicated their lifes' work over decades to develop better encryption, and flaws are still being found. Any "Self-devised encryption" you (or I, or any other amateur) can come up with will be no more than a toy at best. If you're not worried about serious attacks, and don't want to bother with the overhead of real encryption, just pick something simple that an 8-year-old isn't likely to guess, and be done with it. Don't waste time trying to make it better.
There's home-grown cr@p, and then there's state-of-the-art commercial grade and above. There really isn't much middle ground where you're likely to be able to plant your flag.
sabre150 wrote:Yeah, I meant that mostly facetiously, and was talking about the code itself, not the execution of it.
jverd wrote:There is not much overhead with standard symmetric encryption (AES, Blowfish etc). The network delays will probably dominate. Key management will be the main problem.
, and don't want to bother with the overhead of real encryption, j
There can be a bit of a learning curve, and if you start getting into certs and whatnot it can get painful, but if he just wants bytes in → encrypted bytes out, then, yeah, there really isn't much to it.
The voice is carried on a UDP channel; the key (i.e. the packet (re-)ordering) would be sent over TCP on a separate SSL connection. The diffculties with the algorithm would be accessing the "packet array" at a high enough speed to re-establish correct order without introducing latency and losing QOS, whilst making it difficult for a reasonably competent, real-time permutational resolver to overcome the randomness and "decrypt" the stream. (As to the 'inevitable loss of UDP packets', the programme works smoothly now and it already suffers from lost packets, so that would not be a problem per se).
To jverd : there is encryption for UDP and it's called DTLS (which is in the search terms for this question if you'd looked). But that requires going into JNI, and, before I would do that, I want to exhaust the possibilities in pure Java first. I don't know why you lecture me about maths brains etc - you have no idea who I am for a start, and secondly, even if you did, such a comment doesn't begin to be an answer to this question. Which brings me on to my other point, the one you make about amateurism: what I am proposing is not, in itself, true encryption, as the data is not subject to a keyed transformation. Instead, (as I also already indicated but you haven't noticed afaics), a randomised packet sequence amounts to a one-time pad for **plaintext**, since it would be just about impossible to render a completely correct parallel stream from continuously randomly ordered packets, any appreciably valuable number of times. The random sequence would be generated over a write-ahead,-read-ahead SSL stream, which, I admit, is a slight challenge, ensuring, for one thing, that the TCP stream kept ahead of the game over the UDP payload.
895583 wrote:I never look at those. Never found them to be useful.
To jverd : there is encryption for UDP and it's called DTLS (which is in the search terms for this question if you'd looked).
I don't know why you lecture me about maths brains etcI'm not lecturing you, just pointing out some realities that you may not be aware of.
- you have no idea who I am for a startObviously not. All I have to go by is what you've posted here. To wit: A subject line that indicates exactly the kind of thing that people who don't understand encryption often try to do, and fail miserably at; and a suggested approach that seems horribly naive and broken from the get-go. From this, it is reasonable to assume that you're pretty uninformed about encryption.
, and secondly, even if you did, such a comment doesn't begin to be an answer to this question.100% wrong. Pointing out to you things that you appear not to know about the limitations of your attempted approach is in fact a very useful answer.
895583 wrote:You admit it is not an encryption algorithm, then why title it "Self-devised encryption"?
...what I am proposing is not...true encryption, as the data is not subject to a keyed transformation. Instead,...[it is] a randomised packet sequence[r and] amounts to a one-time pad for **plaintext**...
Anyway, since all you are doing is re-ordering UDP packets (and sending the ordering sequence over a standard SSL session), this really does not amount to a question on cryptography - probably more on network performance. Perhaps you might want to post this topic (with a more appropriate title) on a different forum? As far as I can tell, there is no crypto question to answer here.
P.S. I would refrain from calling it a "one-time pad for plaintext" on the other forum, since an OTP does involve keyed-transformation.
P.S. I would refrain from calling it a "one-time pad for plaintext" on the other forum, since an OTP does involve keyed-transformation.I was referring to the fact that the sequence of the packets would be generated by a random function; in that sense, those keys are a one-time pad.
I don't think I'll bother asking the question on another forum under any other title or description, as I equally think I won't be bothering asking any more questions on this one either. But thanks for your attempt at an answer.
If I understand your protection scheme, I believe it goes something like this:
1) If the data-flow has 100-packets, rather than send them in the order they are created - 1, 2, 3,... - the Sequencer module generates a random numbering scheme - for example, 14, 39, 72, 27, ... and so on;
2) The Sequencer sends this random numbering scheme to the recipient over an SSL-protected channel, at least, just slightly ahead of the plaintext channel;
3) The VoIP software now sends plaintext packets in the order of the numbering scheme, over an unencrypted channel;
4) The recipient reassembles the data-stream from the randomly-ordered packets into an orderly sequence (based on the order it received from the SSL-channel) and sends it up the stack for processing.
If this is the case, I'm not sure where the one-time pad comes into play. There is no cryptographic key; there is no transformation that occurs with a key that is the same length as the plaintext; so I'm not sure how you can define it as an OTP (https://en.wikipedia.org/wiki/One-time_pad).
Assuming there is sufficient randomness in the Sequencer,you could call it a "one-time sequencer" if you wanted to; but unless you are using a True Random Number Generator, you would be making the assumption that it is a "one-time" sequencer. Software RNGs use the same randomization algorithm and must, therefore, be seeded to start at a different place every time to achieve Pseudo RNG. And even then, depending on how you get your seed, you might still be making the assumption that it is a "one-time" sequencer - you can't guarantee it unless your did have a TRNG source that guaranteed true randomness. (I'm sorry about going off tangentially, but this stuff does get complicated once you start going down the rabbit-hole - can be stimulating or discouraging depending on your point-of-view).
I would not be discouraged from asking questions anywhere - in the end, questions help us all learn something. A useful quote about group discussions I make a point of remembering, goes as follows: "If you are right, you have no need to be angry; if you are wrong, you have no right to be angry". It has helped me find perspective on many occasions.
[Me] > pseudo-encrypt the stream
I'm not saying it's a 1-2-1 technical OTP - I'm using the term with (probably unwarranted licence) latitude. Anyway . . .
1) 2) 3) 4)That's correct.
If this is the case, I'm not sure where the one-time pad comes into play. There is no crySo's that.
you could call it a "one-time sequencer"Let's use this concept as the new starting point then.
The net effect of what I describe is intended to be a jumbled (if you like) sequence order that is itself encrypted (via SSL). Assuming that SSL does its job, and protects that ordering, it would appear to be onerous and irksome for an intercept to re-render the packets (VoIP) into a meaningful or intelligible stream.
Running a prototype using 7 bytes (representing what would be the packets' sequence), results range from a handful up to more than 20,000 attempts, using just math.random(). That's quite a mess to sort out.
In practice, this scheme likely wouldn't work particularly well for voice packets, given that they are highly perishable.