LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   What is the best cryptographic algorithm? (https://www.linuxquestions.org/questions/linux-security-4/what-is-the-best-cryptographic-algorithm-303954/)

Linux.tar.gz 03-20-2005 01:00 PM

What is the best cryptographic algorithm?
 
Sorry for this noobish question!

cylix 03-20-2005 01:08 PM

Bit rot 13

=)

TruckStuff 03-21-2005 01:45 PM

Re: What is the best cryptographic algorithm?
 
Quote:

Originally posted by Linux.tar.gz
What is the best cryptographic algorithm?
Define "best." If you are looking for strength, i.e. amount of time needed to break a cypher, AES (Rijndaehl) is usually considered the "best" alogorythm that is publicly available in this country. If you want speed and simplicity, ROT13 would work just as well as any. ;)

Linux.tar.gz 03-21-2005 03:14 PM

I mean strongest. The one even God can't decrypt ^^.

backroger 03-21-2005 07:26 PM

I thought either AES or 3DES...


or probably "Project Mercury" (Movie Mercury Rising)....but you have to kill the child first...j/k.

soulstace 03-21-2005 08:16 PM

XOR Encryption using a One-Time Pad is perfectly secure.

;Ƒ~dɬ-I$/c

:cool:

Linux.tar.gz 03-22-2005 03:36 AM

What is a One-Time Pad?
Thx for replies.

penguinlnx 03-22-2005 02:53 PM

Best cryptographic algorithm...
 
Unbreakable is the goal, right?

An encryption method also depends upon other security factors in order to be effective.

(1) What is the nature of the data?

(a) Is it really encryptable? Is it already potentially accessible to the public or the anti-target?
(b) Is it simple information, or a communication that must be delivered in a timely manner?
(c) Is it the kind of information that can be guessed at or discovered independently or inductively?
(d) Does the data really need un-encrypting? can it be destroyed?

(2) Who are you trying to stop?

(a) accidental discoverers?
(b) parties who know they have a vested interest in uncovering the data?
(c) people with more resources or better resources than the person entrusted with the data?

(3) What resources have I got to invest in protecting this data?

(a) What is the data worth? and how much of that worth can be expended protecting it?
(b) What tools and technology are available or appropriate for the case in question?
(c) What extra risks are introduced by various choices made?

(4) What vulnerabilities exist in the entire chain from encoding to decoding?

(a) are there transportation vulnerabilities?
(b) problems identifying or ensuring what parties should be involved in translating or receiving it?
(c) problems training or ensuring proper use of the encryption methods used?
(d) problems with active hostile forces attempting to defeat the process of encryption/transport?

penguinlnx 03-22-2005 03:05 PM

PS: a one time pad is:
 
almost anything can be used as a one-time pad:

You could arrange for you and your friend beforehand to buy next week's newspaper.

Neither of you knows what will be in it. No one else knows you are going to use it.

On the key day, a letter arrives from your friend...(or is it a fake?)

It is encrypted with a one-time pad: (the newspaper you agreed to use beforehand!)

He bought it before incrypting the note: He simply XORed his message with the first ten words on page 7, arranged by you both beforehand.

You wander into a coffee shop and pick up any copy of the newspaper, and pretend to glance at it, then memorize the first ten words on page seven.

Now you reverse the encryption using the key you agreed upon.
The note reads: "Excellent! our prearranged one-time pad worked! Next time we'll use Friday's paper, only start on page 5, and use every OTHER letter." .

Magsol 03-22-2005 03:23 PM

What about Blowfish and its 448-bit encryption key? ;)

TruckStuff 03-22-2005 03:35 PM

No encryption algorythms are perfectly secure. Many are more resistant to systematic attacks, but they are all succeptable to the "dumb luck" attack where an attacker stumbles upon the key.

gaffel 03-22-2005 04:48 PM

The list of questions that Penguinlinux gave pretty much covers your decision process in selecting an encryption algorithm.

It basically boils down to: How much is the data worth versus the cost of accessing it?
If your information loses it value in 4 days (e.g. business info about a bid) and it would take 40 days using a brute force attack to access it then it is adequately secure for your needs.

(of course the 40 days is a statistic, as Truckstuff pointed out the attacker could just get lucky on the first attempt)

And if you want security equivalent to a One time pad, but ridiculously secure - without the problem of distributing the pad, use quantum cryptography (encodeing the data using polarised photons). Only works for optical comunication channels. If you eavesdrop on a quantum cryptography channel you alter the message by observing it, so both the transmitter and receiver know they are being listened to. weird stuff - read about it Admittedly it is more of a key exchange system, but it is really being used.

penguinlnx 03-22-2005 05:53 PM

Nobody gets 'lucky' twice:
 
If you do more than one layer of encryption, getting 'lucky' is pretty much eliminated.
If the cracker gets lucky once and decodes a layer, he has no reason to know it.
the result is still 'encoded' and looks no different than the original encrypted message.
There is no clue to stop and keep the result, and then try to decode the next layer.
Probability for each successive decoding process quickly multiplies to a ridiculously unlikely number.

If under a multi-layer encoding process your security is breached,
It is unlikely a cracker got 'lucky'. Your security has been breached on another level.
Start looking for moles and holes.

Quantum coding is just a variation on an old theme: the random number generator.
You can't guess a code that hasn't been decided yet.
You can't outsmart or spy on an encoder that doesn't itself know what the encoding key will be yet.

But keep in mind that what is encoded can be determined other ways.
You can for instance often successfully predict an opponent's chess move because it may be the only good move. Similarly, a courier with a briefcase running from the Kremlin may only have the answer to one relevant question in his pouch: Do we launch an attack? "YES". No need to crack that.
When an army lined the border of Kuwait, even footsoldiers could guess the plan.

Few people know that even the MiniMax strategy in Game Theory can easily be beaten under normal circumstances, even though it is supposed to be the best solution to a game matrix.

Linux.tar.gz 03-24-2005 05:35 AM

Thanks all for replies! This is very interesting. I've done a little guide here:
http://www.linuxquestions.org/questi...hreadid=305423

penguinlnx 03-25-2005 09:36 PM

one more reply to clarify:
 
Quote:

If you do more than one layer of encryption, getting 'lucky' is pretty much eliminated.
If the cracker gets lucky once and decodes a layer, he has no reason to know it.
the result is still 'encoded' and looks no different than the original encrypted message.
There is no clue to stop and keep the result, and then try to decode the next layer.
Probability for each successive decoding process quickly multiplies to a ridiculously unlikely number.

If under a multi-layer encoding process your security is breached,
It is unlikely a cracker got 'lucky'. Your security has been breached on another level.
Start looking for moles and holes.
This is only an idealized case: The cracker doesn't even know the method of encryption for each layer, the number of layers, or even whether each layer is a cipher or a code (look those words up), and the length of the text encrypted (a password for instance) is usually too short to analyze statistically for clues. (In English for instance, the frequency of occurance of letters is known, i.e., "ETOIWANSHRDLU" . Thus if 'x' occurs in the message with the frequency of 'e', we know the 'x' is really an 'e' everywhere in the message, in a fixed cipher).

If one knew that each layer was a simple cipher or an XOR operation against a guessable key, one might with enough time crack the password like one solves a chess game, by crawling along a tree, and looking for a result that matched a likely easy-to-remember word. It might be an unknown number of layers, or 'look-ahead', but a program could pound away. The point is, it could take months or years to crack the password.

The problem is however, that each possible case would have to be checked to see if it worked, without alerting the gatekeeper! Imagine a military base, where you approach the sentry, and you want to try the next three possible passwords. You give the wrong one, and the guard shoots you dead. Oh well, wasn't as easy as it looked!

In reality, passwords on the internet are already compromised beyond belief before you start: which is why it is possible for crackers to find them out and use them.

(a) 1st, a cracker doesn't guess passwords, he hijacks them! Even though they are encrypted, the cracker knows the basic methods used, and possesses 'hash tables' to quickly apply against large dictionaries of likeliest passwords. He finds a match that corresponds to an encryption of 'donkey' or whatever, and then he just uses it.

(b) 2nd, often the cracker doesn't need to break the password's encryption. He just sends it encrypted, in the form expected, and it works without him even needing to know it.

(c) 3rd, a cracker gets inbetween the sender and receiver, and simply lets the sender gain access for him, then uses the system himself.

(d) 4th in many situations, a hacker can try to logon over and over again with password after password, and the gatekeeper will just happily let him keep trying.

The internet idea of security is so far away from ordinary real-world security situations that it is a joke. This is why the idea of encryption is secondary, and rather mute or moot compared to other aspects of the security problem.


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