Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
One Time Pads wouldn't be suitable for tunneling software. Generating random data isn't trivial and you need to distribute the random data to the recipient ahead of time. If you can do that securely, why not use that method in the first place. Another problem is that you need to generate unique one time pads for any two users who need to communicate.
An ssh tunnel uses a psuedo random sequence to xor with the data. The public and private keys are used for authentication and to agree on the RC4 sequence to use.
If you can do that securely, why not use that method in the first place.
Because that method requires one physical exchange of keys, whereas tunneling is for daily use over and over and over until all of the pad has been used.
This is classic "cryptographic snake-oil." Keep your hands, and your wallet, firmly in your pocket.
There are already two very well-established, peer reviewed protocols for sending consumer-grade cryptographically secured messages: the S/MIME protocol that's probably built-in right now to any e-mail program you might encounter; and GPG, which might be a plug-in.
The downfall of "one-time pad" is quite simple: you have to have a secure way to distribute the pad, which must be at least as long as the total amount of message that you intend to send. And if you could do that, you wouldn't need cryptography at all: just use whatever perfectly-secure means of transport you had for the pad, to send the message instead. There is of course also the additional problem that, if the pad ever did get stolen, anyone could not only read your message but forge them.
If you use S/MIME or GPG with digital certificates, and perhaps also if you use an internal-only email network with servers that are connected using VPN tunnels (which are also secured using certificates ...), you're using well-understood, peer-reviewed methods and protocols which are pragmatically workable under real-world conditions. You can securely send and receive messages from people you've never met. All of that "other stuff" has been worked-out for you.
And, very importantly, nothing's secret, except the key. Everyone knows absolutely everything about how the ciphers work, about how key-generation and key-exchange works, and so on. There is no "security through obscurity."
You get three benefits:
Concealment: ... if you want it.
Message Integrity: the message received is identical to the message tendered.
Provenance: the message did come from the person who claimed to have sent it.
No, you're not going to keep out the mysterious organizations with three-letter acronyms for names. But, since you're not breaking the law, you're not interesting to them anyway.
Last edited by sundialsvcs; 07-17-2012 at 09:15 AM.
This is classic "cryptographic snake-oil." Keep your hands, and your wallet, firmly in your pocket.
I agree that the linked product appears to be making dubious claims of security: in particular they have a nice graphic of the encryption process which explains how they made up their own Cipher-block chaining mode (Rule#1 of Cryptography: Don't invent your own algorithm) and how the one time pad is used for encryption but no explanation of how the pad gets to the other side for decryption...
Quote:
The downfall of "one-time pad" is quite simple: you have to have a secure way to distribute the pad, which must be at least as long as the total amount of message that you intend to send. And if you could do that, you wouldn't need cryptography at all: just use whatever perfectly-secure means of transport you had for the pad, to send the message instead.
You could transfer a few GB of random bytes on a USB stick just once by hand which should be enough for a lifetime of text messages.
Quote:
There is of course also the additional problem that, if the pad ever did get stolen, anyone could not only read your message but forge them.
That's true for any secret key (eg: a private GPG key).
if the pad ever did get stolen, anyone could not only read your message but forge them.
The pad is to be erased after use, little by little. If usb drive is stolen before being used, there is no security breach.
Quote:
Originally Posted by sundialsvcs
you have to have a secure way to distribute the pad, which must be at least as long as the total amount of message that you intend to send.
Point received, but where exactly did you read I want to send messages? I do not.
I want a tunnel for live telephone calls.
Quote:
And if you could do that, you wouldn't need cryptography at all: just use whatever perfectly-secure means of transport you had for the pad, to send the message instead
Sure, a single trip and meeting in person with someone across the world, is just as easy as daily trips to their country.
If anyone is interested in the shortcomings of standard methods for tunneling (such as trusting "trusted authorities" that include Israeli private companies, or weakness deliberately put in these methods) maybe we can open another topic for it.
In this topic here, please mention any tunneling software that uses a one-time pad. Call it snake-oil or whatever, free to say how bad it is.
I want a tunnel with a one-time pad where the key is physically given once in a usb drive to the person you want to have daily telephone conversations with. Whether physically giving a usb drive to a friend is less secure than trusting "trusted authorities" is too obvious, please do not discuss this.
Last edited by Charles Butler; 07-17-2012 at 04:34 PM.
Found this research software that implements a tcp tunnel using the one-time pad. But I do not see how the key is passed to the other end of the tunnel. Anyone see how?
Found this research software that implements a tcp tunnel using the one-time pad. But I do not see how the key is passed to the other end of the tunnel. Anyone see how?
I've got a better idea: just put your messages on that USB stick.
Real-world encryption has to send gigabytes of data every day, with a known key-management protocol and, really, predictable security for the information being passed.
The biggest vulnerability that needs to be guarded against is simply eavesdropping: crimes of opportunity, not some grand conspiracy. In a great many cases, the door does not have to be hermetically locked tight as long as it is locked.
Of equal importance to both sender and receiver ... in some cases, more important than concealment ... are the concerns of provenance and message integrity. I need to know that you're the who sent this, and I need to know that this is exactly what you sent. Even on a "routinely encrypted" tunnel link, and even on an unencrypted link, the business consequences of spoofing are often far more damaging than the consequences of codebreaking.
These are inferior, incomplete solutions ... when better, complete, peer-reviewed solutions are available (in open source-code form) for free. "'How to keep secrets well' is not a secret."
I've got a better idea: just put your messages on that USB stick.
The rest of your post is so sensible, I feel like you're just playing dumb here. You can't see the difference between meeting in person once to exchange a secret key, and meeting in person every time you want to pass a message? Hint: latency.
He's just reciting. Which is ok, we all do that now and then, whether we admit it or not. The Russian government is not using what is called peer-reviewed technology when communicating with their scientists in the Antarctic. Instead, last time a major discovery was made they sent a non-pc communication device holding software and a long key for, guess what. One-time pad.
A one time pad would be used for short text messages, not for encrypting network traffic. I suppose it could be used in some way to send a certificate to use to set up a regular VPN. Maybe you could use it to send a password to somebody. Imagine that you sent someone to deliver an encrypted drive. After the courier returns and you know it was delivered safely, you send the passphrase encrypted with a one time pad. The idea of using otp to encrypt network traffic is down right silly.
When you read about "one-time pads" in cryptographic papers, it's because this is a theoretical situation. If both parties possessed a sufficiently long, truly-random, identical sequence of data which would, with perfect reliability, only be used-once and then thrown away, then, yes, there would be nothing for a cryptographer to use. But these characteristics of the pad, let alone of its distribution and use, are not practical... and every cryptographic communication scenario must be practical.
A practical commercial-grade (or even military-grade) cryptosystem is indeed a system. It has looked at the entire requirement from all angles, including "what Mister SNAFU can and will do" in the real world. Every aspect of the system is public knowledge. Every bit of it is peer-reviewed ... and "those agencies with funny 3-character names" are among the reviewers and contributors. (They are publicly funded agencies with responsibilities both to the military and to the civilian sectors. Sometimes, as was the case with DES, they said, "you must do it this way and we cannot tell you why," and it turns out that years later the civilian sector found out why they had been right. They've also been known to say, "this approach is not acceptably secure for your purposes, and we cannot tell you why not.")
Last edited by sundialsvcs; 08-04-2012 at 01:27 PM.
When you read about "one-time pads" in cryptographic papers, it's because this is a theoretical situation. If both parties possessed a sufficiently long, truly-random, identical sequence of data which would, with perfect reliability, only be used-once and then thrown away, then, yes, there would be nothing for a cryptographer to use. But these characteristics of the pad, let alone of its distribution and use, are not practical... and every cryptographic communication scenario must be practical.
There are many practical uses for a one-time pad.
They are the only cypto system that is unbreakable forever. They allow a secret key to be exchanged ONCE by two trusted parties which will allow FUTURE communications to be made securely.
Who knows what kind of technology may be available to eventually crack current encryption standards. If your communication is intercepted it could be archived indefinitely and cracked when it's possible to do so.
Last edited by SuperJediWombat!; 08-08-2012 at 02:18 AM.
They are the only cypto system that is unbreakable forever. They allow a secret key to be exchanged ONCE by two trusted parties which will allow FUTURE communications to be made securely.
Who knows what kind of technology may be available to eventually crack current encryption standards. If your communication is intercepted it could be archived indefinitely and cracked when it's possible to do so.
This doesn't sound like a realistic plan of attack to me. The information will probably be irrelevant by the time current encryption schemes are cracked (if ever).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.