MD5 hashes are now considered broken, because collision might happen. Is this problematic for HTTP digest authentication?
MD5 is known to be vulnerable to collision attacks.
HTTP Digest does not require collision resistance from the hash function. It uses the hash to verify both parties poses the same secret plaintext without exposing it en route.
If in doubt, just add HTTPS :-)
MD5 hashes are now considered broken, because collision might happen
Wrong.
The probability of accidental collisions was known when md5 was written. What has changed is that techniques are now available to reduce the amount of effort required to generate a specific hash.
If HTTP digest auth is currently adequate for your purposes then continue to use it; there are other far more serious / exploitable vulnerabilities in digest authentication.
This is all described on Wikipedia
Related
Which of these methods of hashing passwords will be most secure and most hard to find hash collisions?
MD5 only
SHA1 only
MD5 over SHA1
Neither of these should be used for password hashing they have been proven to be insecure:
MD5 from Wikipedia:
The security of the MD5 has been severely compromised, with its weaknesses having been exploited in the field, most infamously by the Flame malware in 2012. The CMU Software Engineering Institute considers MD5 essentially "cryptographically broken and unsuitable for further use".
SHA1 from Wikipedia:
SHA-1 is no longer considered secure against well-funded opponents. In 2005, cryptanalysts found attacks on SHA-1 suggesting that the algorithm might not be secure enough for ongoing use,[3] and since 2010 many organizations have recommended its replacement by SHA-2 or SHA-3.[4][5][6] Microsoft,[7] Google[8] and Mozilla[9][10][11] have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017.
Much more secure hashing algorithms exist such as SHA-2 or 3 which should be considered.
I am trying to use asymmetric encryption to encrypt firmware. The bootloader will decrypt and update the flash. This is on a embedded device with 32 bit CPU executing at 60MHz.
I want to use ECC due to its varies advantages. I am new to encryption and my understanding os ECC as implemented in ECIES is to use ECC for the key generation and use AES for actual data encryption. Due to code and ram size, I cannot support multiple encryption algorithms.
Is there a implementation of ECC that can be used just like AES. All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
Thanks.
I'm not sure that you completely understand what ECIES consists of:
http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
That's quite a bit of work, and it requires a whole lot of primitives, including at least one symmetric primitive, it seems to me. That might as well be AES.
Let's start from the last sentence of the question:
All I am looking for is to use a "Private key" to encrypt firmware and the bootloader uses "Public Key" to decrypt it.
There's some confusion in terminology here. Private keys are used to decrypt (or sign) and public keys are used to encrypt (or verify). If I understand correctly, what you want is for the bootloader to verify a signature on the firmware so that only a firmware that was properly signed by yourself will be accepted by the bootloader.
There are various asymmetric signature schemes which can be used for this purpose, including some which are based on eliptic curve cryptography. For example you could use the OpenSSL implementation of ECDSA (see http://www.openssl.org/docs/crypto/ecdsa.html).
I'm afraid there's not enough information in the question to properly choose the best signature scheme (and possibly an encryption scheme as well if there is a need to keep the firmware secret). In any case, good cryptography is not enough to make a system secure and other considerations such as secure implementation are no less important.
If this is is something that is important for you to protect and that you are worried that hackers may try to break, I would strongly advise procuring the services of a security professional. Using cryptography correctly is a very tricky business that requires a full understanding of the system - otherwise you may find yourself in a situation like this
If you look for "authentication" you have to use asymmetric algorithm like EC, this usually done because if the user or process want to update the "firmware" he should identify him self to the bootloader by his "signature" to check who request this update.
After that is done, the bootloader will load the symmetric key from a secure memory to decrypt what you want to do.
So, you have a symmetric key for encryption (AES), and asymmetric two keys for authentication (=Who are you?).
Note: there is no advantages of EC on 32 bit CPU executing at 60MHz for Encryption, unless your application need asymmetric for Encryption NOT authentication, this happen due to line between the user and bootloader is not secure.
Therefore, you could use bootloader's "public key" to encrypt firmware and the bootloader uses its "private Key" to decrypt it, however, the implementation cost a lot due to the high computing for asymmetric algorithm.
Look for "lightweight cryptography", it is typical for your application.
I have a program that I am reverse engineering for learning purposes about protocols (and to sharpen my assembly skills). I have reversed the whole protocol, and know where encryption takes place and all. The program uses an CBC(chain block cipher) but the packets keep going through an MD5 Hash before they are sent.
I know this is not possible(or is it?) I searched Google for a long time and couldn't find any information. So does anyone else know if a protocol like this is possible, and the name of it?
As a very obvious and well-known example, the SSL/TLS protocol uses MD5 (but not exclusively MD5).
Instead of spending a bunch of $$ on ssl, can I implement RSA on my own? (I don't care about proving the site's identity; I just want to encrypt a password between clients and the server to protect from man-in-the-middle attacks). I've read that any custom solutions are likely to be very insecure, but could someone read my plan and give a thoughtful response?
First I would create public and private keys. I would encrypt the client password with javascript by translating the letters of the password to ascii-values, and then multiply or add (any suggestions?) these ascii-values to get the "unencrypted message". I would then encrypt this message using javascript and the public key.
On the server, I would decrypt the secure message using the private key and end up with the sum/product of the password's ascii-values. Any tips on how to get the individual letters from that?
Edit: I've reached the conclusion that SSL is the best way to go. I was only looking at the client to server side of the deal (where all the client sends is a password). Of course, the information sent by the server to the client is valuable, and should not be vulnerable to MITM attacks. Thanks for the free SSL suggestions.
Thanks
There are a bunch of reasons not to roll your own encryption.
SSL gives the user confidence that the site is secure and that eavesdroppers cannot view the password on the wire. If you don't use SSL then the usual browser indications that the site is secure will not be present.
It's really hard to get RSA right (or any crypto algorithm for that matter). First off, using raw RSA is insecure and you need to have an appropriate padding mechanism and wotnot to make it actually secure. RSA can also only encrypt n-1 bytes of data, where n is the size of the key.
Leave crypto to the cryptographers. The first issue with your proposed system is that you're missing the point of using a secure transport: You don't need to do any special encoding of your data (the conversion to ascii and multiplying/summing or whatever part) because the secure transport means that eavesdroppers cannot see what's going past.
Your proposal does not protect against man-in-the-middle attacks. It (kinda) prevents eavesdropping, which is a different problem.
That said, you certainly can implement RSA in Javascript with a bit of effort, but just be aware that it is unlikely to be secure until you've had a bunch of cryptanalysts look at it and try to break it. You will make a mistake somewhere along the line, even if you are the best programmer in the world.
The user experience will also suffer because it will be very hard for the user to verify that they are, in fact, talking to your server.
SSL is a well known, well analysed, not-yet-broken protocol that can be free if you use a self-signed certificate (another poor user experience, but at least it's still fairly secure). Think very carefully before you decide to cheap out on the crypto, and make sure you weigh the cost of a certificate against your development time (it'll take you many hours to implement RSA) and the potential cost of leaking important customer information (their password). The cost of the certificate is likely to be insignificant compared to the rest of the project cost.
You can use a self-signed certificate on the server and trust it explicitly on the client (i.e. encode certificate parameters etc). So you don't need to reinvent the wheel. I would say more - depending on the library you can use PSK (pre-shared key) cipher suites and get rid of certificates completely.
I'm not sure you need SSL if you cannot afford a certificate. Obviously, your data you intend to protect does not have much value.
The public/private key system is best way to go. By the time you figure out how to roll your own and get your CA certificate included in all the major browsers and Operating Systems and become your own Certificate authority, I think you will find spending a few 100$ on cert is cheap.
If you are looking for SSL but not spending money use www.startssl.com as that will allow you to use SSL free. Creating your own solution will take time and if not done the correct way will be insecure.
Yes, it is possible to implement plain RSA "by hand" in this way. To create the unencrypted message, you can simply use the bits of the message. For example, if your password is cheese:
c h e e s e
0x63 0x68 0x65 0x65 0x73 0x65
The number to encrypt could then be simply 0x636865657365. You'll need to use math routines that can handle large integers (native Javascript numbers aren't big enough).
Standard warnings apply, your solution will have a fatal flaw in some way, etc etc.
I don't care about proving the site's identity; I just want to encrypt a password between clients and the server to protect from man-in-the-middle attacks)
That's exactly why you do care about proving the site's identity.
That in turn is why just using RSA without an authentication scheme isn't secure. It's no good having a secret conversation when you can't identify who you're talking to.
We are putting an HTTP RESTful interface into an embedded platform of ours. The hardware is too limited to support SSL, but we do use AES encryption for other things.
I'm thinking of using AES with a shared key to encrypt the data. Is there anything else that is at least a somewhat standard way of encrypting via HTTP?
The standard way of encrypting HTTP is SSL (or its successor TLS, nowadays) (this is then known as HTTPS).
As GregS asked in a comment, in what way is your platform too limited for SSL, but still allows AES? Does it have not enough computing power/memory to do modular exponentiation (which is used in RSA, DSA, Diffie-Hellman)?
Then you might be able to use a pre-shared key version of TLS. RFC 4279 defines cipher suites with pre-shared key authentication, where the TLS_PSK_WITH_AES_128_CBC_SHA looks like if needs only AES and SHA-1, no modular exponentiation.
Of course, you shouldn't use this if there is the danger that an attacker can get the secret (e.g. by cracking your device), since this allows also to read all previously registered connections (in contrast to Diffie-Hellman, which provides a new session key for each session).
Found this gem: Diffie-Hellman Key Exchange in 10 lines of C
http://www.cypherspace.org/rsa/dh-in-C.html