Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
MD5 encryption 15
- Thread starter elibb
- Start date
>This method might totally suck
Sadly it does, unless your 'password' is as long as (or longer) than the text you are encrypting, at which point what you have is a one-time pad, which is generally acknowledged as being unbreakable through normal cryptoanalysis (as long as the 'password' is genuinely random, and different for every message transmitted). The big problem with one-time pads is key exchange...
Sadly it does, unless your 'password' is as long as (or longer) than the text you are encrypting, at which point what you have is a one-time pad, which is generally acknowledged as being unbreakable through normal cryptoanalysis (as long as the 'password' is genuinely random, and different for every message transmitted). The big problem with one-time pads is key exchange...
-
1
- #22
Like strongm says -- if your key is shorter than your data, you end up making it much easier to break.
[tt]
Data: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Key: abcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh
[/tt]
If you notice, "a" from the key is used to encrypt every 8th letter. Since the data is the same in all positions, this results in a repeating pattern in the encrypted text. Ooops!
While this is a contrived example with worst-case input data, it's a proven code-breaking technique. If a code breaker can force a pattern into the source text, he then has more information about the key that was used to encrypt it. This was used to good effect several times during World War II, where the allies would intentionally fly some planes over a city they didn't intend to bomb. The ground observers would dutifully report the sighting to higher headquarters, including the time they saw the planes. Since the codebreakers knew the time would be part of any message sent, that gave them insight into the key in use that day.
To OP: My advice is to spend your time selecting the correct algorithm for your needs, and depend on the Crypto API for the implementation of that algorithm. The CAPI is used by many people besides internally at Microsoft, and is well-tested.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
[tt]
Data: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Key: abcdefghabcdefghabcdefghabcdefghabcdefghabcdefgh
[/tt]
If you notice, "a" from the key is used to encrypt every 8th letter. Since the data is the same in all positions, this results in a repeating pattern in the encrypted text. Ooops!
While this is a contrived example with worst-case input data, it's a proven code-breaking technique. If a code breaker can force a pattern into the source text, he then has more information about the key that was used to encrypt it. This was used to good effect several times during World War II, where the allies would intentionally fly some planes over a city they didn't intend to bomb. The ground observers would dutifully report the sighting to higher headquarters, including the time they saw the planes. Since the codebreakers knew the time would be part of any message sent, that gave them insight into the key in use that day.
To OP: My advice is to spend your time selecting the correct algorithm for your needs, and depend on the Crypto API for the implementation of that algorithm. The CAPI is used by many people besides internally at Microsoft, and is well-tested.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
Homersim2600
Technical User
In reply to ChipH,
Have you seen the movie "Enigma"? It gives a very similar example to what you have mentioned about the planes flying over without any intent. Very cool movie for the crypto-dude.
LF
"As far as the laws of mathematics refer to reality, they are not certain; as far as they are certain, they do not refer to reality."--Albert Einstein
Have you seen the movie "Enigma"? It gives a very similar example to what you have mentioned about the planes flying over without any intent. Very cool movie for the crypto-dude.
LF
"As far as the laws of mathematics refer to reality, they are not certain; as far as they are certain, they do not refer to reality."--Albert Einstein
dilettante
MIS
Nonethless an MD5 hash can be useful with passwords.
A common headache involves passwords stored in a database. Here storing the hashed value ads a modicum of security.
An assumption is that what is really being protected is the users' identity. After all, if a hacker gets the database, he or she has all the current data.
The identity is only protected in the sense that hashed passwords can't be used to authenticate as an existing user when operating against the database via the production application. The assumption here is that feeding in a hashed password will simply cause the application to "rehash" it, which will not match the stored value.
Even if the application code and database are stolen, the only way to impersonate users based on the hashed passwords would be to alter the application code to stop hashing on authentication (or provide a non-hashing back door logon). Then the crook would have to put the altered code back into production on the machines hosting the application logic.
If a bad guy can do that, passwords may be the least of your troubles.
A brief discussion of this can be found at MD5 and passwords.
Some web applications even accept passwords client-side, concatenate these with the user name and other junk, then take the MD5 hash and send that back to the server without a plain-text user name. The little concatentation dance is a small attempt to defeat dictionary attacks, because just hashing the password makes it easy to probe with a hashed dictionary of likely password text.
Since the risk of collisions in 128 bits is small but possible, some applications hash the user name and the password (or password + user name) and send the server 64 hex digits (2 MD5 hashes) as the authentication string. This reduces the potential for collisions a bit more.
In any case, this provides a modest shield against sniffing when not using secure authentication or SSL. Even then the application at the server generally hashes this stuff yet again to store it in the database or before comparing it with what's in the database. This 2-level hash does 2 things: modest "sniffer shielding" as well as the stolen database identity protection described earlier.
Protecting the data in the event the database gets stolen is another subject though, and MD5 isn't much help there as others have eloquently pointed out.
A common headache involves passwords stored in a database. Here storing the hashed value ads a modicum of security.
An assumption is that what is really being protected is the users' identity. After all, if a hacker gets the database, he or she has all the current data.
The identity is only protected in the sense that hashed passwords can't be used to authenticate as an existing user when operating against the database via the production application. The assumption here is that feeding in a hashed password will simply cause the application to "rehash" it, which will not match the stored value.
Even if the application code and database are stolen, the only way to impersonate users based on the hashed passwords would be to alter the application code to stop hashing on authentication (or provide a non-hashing back door logon). Then the crook would have to put the altered code back into production on the machines hosting the application logic.
If a bad guy can do that, passwords may be the least of your troubles.
A brief discussion of this can be found at MD5 and passwords.
Some web applications even accept passwords client-side, concatenate these with the user name and other junk, then take the MD5 hash and send that back to the server without a plain-text user name. The little concatentation dance is a small attempt to defeat dictionary attacks, because just hashing the password makes it easy to probe with a hashed dictionary of likely password text.
Since the risk of collisions in 128 bits is small but possible, some applications hash the user name and the password (or password + user name) and send the server 64 hex digits (2 MD5 hashes) as the authentication string. This reduces the potential for collisions a bit more.
In any case, this provides a modest shield against sniffing when not using secure authentication or SSL. Even then the application at the server generally hashes this stuff yet again to store it in the database or before comparing it with what's in the database. This 2-level hash does 2 things: modest "sniffer shielding" as well as the stolen database identity protection described earlier.
Protecting the data in the event the database gets stolen is another subject though, and MD5 isn't much help there as others have eloquently pointed out.
No, but I've read the book the movie was based on. The other "Enigma" movie, U-571 is based on some real events (capture of U-110 & U-559 by British forces, U-505 by US forces), and is covered in "Seizing the Enigma" by David Kahn.
A good one is Cryptonomicon, by Neal Stephenson. It's fiction, but still a good read, involving Japanese gold hidden in the Phillipines and modern digital currencies.
For some non-fiction, try "Most Secret War" by Dr. R.V. Jones. He was the head of British Scientific Intelligence during WW-II, and he writes about their use of RADAR (it's an ancronym, you know) and "Window", the code-word for what we now call chaff.
Chip H.
____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first
Great discussion in this thread.
I wonder...Has anyone heard or used the password encryption tool from a now-defunct company called MicroHelp Encryption X-potents? If so, are there any websites supporting this product? My company has some legacy tools and I need to know the logic in how it works to encrypt and decrypt a password.
Or would it be better to paste the code segment contained in this thread above and use it instead?
Thanks,
Gregoriw
I wonder...Has anyone heard or used the password encryption tool from a now-defunct company called MicroHelp Encryption X-potents? If so, are there any websites supporting this product? My company has some legacy tools and I need to know the logic in how it works to encrypt and decrypt a password.
Or would it be better to paste the code segment contained in this thread above and use it instead?
Thanks,
Gregoriw
They claim they still support Encryption IT, which they bought off Microhelp 8 years ago
If anyone is interested, I have code for the Rijndael encryption algorithm (in several variations) in both Javascript and PHP that I would be happy to share. It shouldn't be TOO difficult to translate it into VB.
Tracy Dryden
Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.![[dragon]](/data/assets/smilies/dragon.gif "[dragon] [dragon]")
Tracy Dryden
Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.
- Status
Similar threads
- Locked
- Question
