LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 04-06-2005, 02:29 PM   #16
almanegra
LQ Newbie
 
Registered: Apr 2005
Posts: 1

Rep: Reputation: 0
algorythm


My favourite one is Twofish. The only attack possible is by brute force, which at present requires enormous power and time (say decades at least)

AES seems secure, but it has theoretical vulnerabilities.

Almanegra
 
Old 04-28-2006, 12:38 PM   #17
dasy2k1
Member
 
Registered: Oct 2005
Location: 127.0.0.1
Distribution: Manjaro
Posts: 963

Rep: Reputation: 36
my porefered method is to use one method sa AES then encrypt the result with a differnt one say 3DES that way if teh firts layer is compramised, teh cahnce of teh second being compramised by the same method id much lower!
 
Old 04-30-2006, 03:24 AM   #18
primo
Member
 
Registered: Jun 2005
Posts: 542

Rep: Reputation: 34
The beauty of one-time pads is the fact that any output is possible from the ciphertext, meaning that you may arrange false key-pads to decrypt to the text you'd rather want big brother to see if they were to force you to "decrypt" that stuff. Explained, it means:

P ^ K = C, with P meaning Plaintext, K meaning Key, C meaning Ciphertext and ^ meaning XOR. Then you generate the alternate pads that big brother may see from the alternate meanings of your conspiracy that brought such a privacy need:

K2 = C ^ P2

I guess I'm not answering your question. You must take into account many variables to choose one. I personally prefer 448-bits Blowfish, Serpent and RC5 (RC4 in its right context) for their key length and for the fact that there are no public reports showing them vulnerable by design.
 
Old 05-02-2006, 08:28 PM   #19
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,635
Blog Entries: 4

Rep: Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931Reputation: 3931
Realistically, one-time pads are unrealistic.

Consider this: in order for the system to provide any security at all, you must have an absolutely secure method of distributing the one-time pad! And if you had that, why not simply use that method to distribute the messages? Why, you would have no need to use cryptography at all.

Furthermore, a one-time pad system is utterly defenseless against anyone who does, by some means, obtain a copy of the key. ("Lemme put it to you this way, pal... if you gimme a copy of that pad and keep ya mouth shut, you and your wife and kids all get to keep their fingers...") If the key ever slips out, anyone can not only decrypt every message you send, but they can forge new ones. You have no way to repudiate the stolen keys; no way to distribute a replacement; no way to detect a forged message; no way to stop the bleeding, or even to detect it!

There are serious operational problems, too. Heaven help you if the two of you ever get "out of sync" with respect to your place in the pad. Or if someone drops a letter out in transcribing a message from Morse code or whatever. Basically, if anything at all goes wrong, you're outa luck. And, "s**t happens." A one-time pad system is just as likely as a rattlesnake to turn against its intended users... utterly failing to meet their practical needs for communication under real-life conditions.

Remember that a practical cipher-system has to be able to reliably deliver hundreds of megabytes of information securely between two parties who may never meet each other. It must be able to do so assuming an not 100%-reliable communication channel, and to deliver the encrypted traffic at nearly the same speed as would be possible on an unencrypted channel. It must provide not only practical-security, but authentication, defense against forged messages, reliable detection of garbled or re-transmitted messages, detection of omissions and drop-outs .. the list goes on. And the whole thing should be invisible. When you jump to an "https://..." web-page somewhere, you don't think about just how secure that transmission actually is! But, it is.

---

As far as cipher algorithms go, then, there are plenty to choose from and it doesn't really matter which one you use, as long as you do not try to "roll your own!" If your system gets broken, it probably won't be because they penetrated the cipher-algorithm: it will be because of flaws in key-handling, or a stolen laptop, or a drunken sales-rep, or what have you.

The people who designed things like SSLv2, GPG, SSH, and so-on did their jobs very well, and what's more, they published everything openly for peer-review. Nothing is "secret," nothing is "obscure," nothing at all is concealed. All you need to do is to pick one and use it.
 
Old 05-02-2006, 08:54 PM   #20
primo
Member
 
Registered: Jun 2005
Posts: 542

Rep: Reputation: 34
Quote:
Originally Posted by sundialsvcs
Consider this: in order for the system to provide any security at all, you must have an absolutely secure method of distributing the one-time pad! And if you had that, why not simply use that method to distribute the messages? Why, you would have no need to use cryptography at all.
Not true. Quantum cryptography will be with us someday. You can transmit data and detect if there was an eavesdropper. And of course, if there was an eavesdropper, you wouldn't want him to read the message.

Quote:
Furthermore, a one-time pad system is utterly defenseless against anyone who does, by some means, obtain a copy of the key.
Any cryptosystem based on secret keys is vulnerable to this. Remember that the beauty of OTP's is alternate keys

Quote:
If the key ever slips out, anyone can not only decrypt every message you send, but they can forge new ones.
One-time pads are meant to be used only one time!

Quote:
You have no way to repudiate the stolen keys; no way to distribute a replacement; no way to detect a forged message; no way to stop the bleeding, or even to detect it!
There are schemes to detect forged messages that you may insert.

Quote:
There are serious operational problems, too. Heaven help you if the two of you ever get "out of sync" with respect to your place in the pad.
[...]
Remember that a practical cipher-system has to be able to reliably deliver hundreds of megabytes of information securely between two parties who may never meet each other. It must be able to do so assuming an not 100%-reliable communication channel, and to deliver the encrypted traffic at nearly the same speed as would be possible on an unencrypted channel. It must provide not only practical-security, but authentication, defense against forged messages, reliable detection of garbled or re-transmitted messages, detection of omissions and drop-outs .. the list goes on. And the whole thing should be invisible. When you jump to an "https://..." web-page somewhere, you don't think about just how secure that transmission actually is! But, it is.
It's not a problem with flow-control protocols such as TCP. If you make sure the intended recipient got the key securely (one way would be to send you a message encrypted with the first X bytes), then you may use that pad to send him data securely. Cryptography is not expected to handle flow-control details. There are protocols for that.

When used properly, OTP is not a rattlesnake in anyone's hands. It may be a good weapon.

Last edited by primo; 05-02-2006 at 08:59 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Knoppix Cryptographic software ed_homeLinux Linux - Software 3 10-17-2005 06:49 PM
kernel -cryptographic api denning Linux - Software 2 10-23-2004 03:33 AM
cryptographic pseudorandom function saajii Programming 1 09-16-2004 07:58 AM
Cryptographic Options for the Kernel larley Linux - General 5 08-16-2004 12:16 PM
Hardware cryptographic module for Linux? abrb220 Linux - Security 1 05-05-2004 11:54 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 05:13 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration