edg-l/ddnet
1
0
Fork 0
mirror of https://github.com/ddnet/ddnet.git synced 2024-11-14 03:58:18 +00:00
Code Issues Packages Projects Releases Wiki Activity
ddnet/src/base/hash_openssl.cpp

43 lines
777 B
C++
Raw Normal View History

Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#if defined(CONF_OPENSSL)
#include "hash_ctxt.h"
Ignore openssl deprecation warning for now (fixes #5597)
2022-07-10 22:19:01 +00:00
#ifdef __GNUC__
// EVP requires heap allocations, let's postpone the replacement for now
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#endif
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
void sha256_init(SHA256_CTX *ctxt)
{
SHA256_Init(ctxt);
}
void sha256_update(SHA256_CTX *ctxt, const void *data, size_t data_len)
{
SHA256_Update(ctxt, data, data_len);
}
SHA256_DIGEST sha256_finish(SHA256_CTX *ctxt)
{
SHA256_DIGEST result;
SHA256_Final(result.data, ctxt);
return result;
}
Use OpenSSL md5 if it is available Fixes #1582.
2019-04-06 00:46:56 +00:00
void md5_init(MD5_CTX *ctxt)
{
MD5_Init(ctxt);
}
void md5_update(MD5_CTX *ctxt, const void *data, size_t data_len)
{
MD5_Update(ctxt, data, data_len);
}
MD5_DIGEST md5_finish(MD5_CTX *ctxt)
{
MD5_DIGEST result;
MD5_Final(result.data, ctxt);
return result;
}
Use more secure hash function for map downloads SHA256 was chosen because it is reasonably standard, the file names don't explode in length (this rules out SHA512) and it is supported by basically all versions of OpenSSL (this rules out SHA512/256 and SHA3). The protocol is changed in a backward compatible way: The supporting server sends the SHA256 corresponding to the map in the `MAP_DETAILS` message prior to sending the `MAP_CHANGE` message. The client saves the SHA256 obtained from the `MAP_DETAILS` message until the next `MAP_CHANGE` message. For servers not supporting this protocol, the client falls back to simply opening maps like in the previous scheme. Remove the `map_version` tool, it is not being used and would have been a little bit effort to update. Use the OpenSSL implementation of SHA256 if it is supported, otherwise fall back to a public domain one. Fix #1127.
2018-06-05 19:22:40 +00:00
#endif
Reference in a new issue Copy permalink