Migration of hashing from Baselibs to Crypto repo

### What

Summary + task for Baselibs to be cretaed..

Details of conversation with baselibs team in past from Slack (https://app.slack.com/client/T02MS1M89UH/dms)

Message 1:
Hello Andrey,

I am Sunil from ETAS and part of the Security team. I got your contact from colleague Oliver Heilwagen. I am reaching out to discuss about the Hash in Baselibs: https://github.com/orgs/eclipse-score/discussions/2390?sort=new#discussioncomment-16903198

Have some questions to get some more understanding:

1. What is the use case for hash? I mean which asset is being protected and the security property is integrity protection. or? .
2. Which all types of hash is being used? I mean SHA2-256, SHA2-224,...?.
3. If i get it right, there are two variants of hash implementation. and why are these two different implementations needed? .
a. sha256digest : one which has no dependency on OpenSSL and .
b. OpenSSL hash : another that is dependent on OpenSSL. or? .
4. And the version sha256digest was written exclusively for SCORE or its also part of some other open source software? .
5. I assume that this hashing to be done during run time or? .
6. How big is the data to be hashed? .
7. Is there any performance expectation? Say hash for 1kB shall be completed in 10ms or something like that. .
8. Should this be ASIL or QM quality level? .

Once again the background is to understand the use case and see how we can solve this with SCORE Crypto.

Message 2:
Hello @Sunilkumar Prasanchand, please find my answers bellow:
1. libHash is a generic library, so I cannot state all use-cases from all clients. Hash functions can be used on several contexts, to name but a few:
- Integrity & Verification
- Fast equality comparison
- Lookup tables
- Load balancing
- Error detection (on transmissions)
So it's foreseeable that it could be used for those, but we do not intend to use it for cryptographic purposes.
For the very first use-case on S-CORE, on Configuration Management, they will be used for integrity check only.

2. The supported algorithms can be seen at: https://github.com/eclipse-score/baselibs/blob/main/score/hash/code/common/algorithms.h#L44

3 and 8. The library is expected to be used on ASIL contexts, but then only this subset of algorithms can be used: https://github.com/eclipse-score/baselibs/blob/main/score/hash/code/core/factory/impl/safe_hash_calculator_factory_ieee.cpp#L26 (namely CRC32 and SHA256). That's the reason why the library provides its own implementation for those, as safety qualifying OpenSSL would be a dauting task, and thus we did not consider it worth for our use-cases. For the remaining algorithms, it just patches-them-through to OpenSSL.

4. Currently it's not being used on other open-source projects.

5. Yes, the library is intended for calculating hashes over runtime data, so it needs to calculate them on runtime.

6. I cannot answer that as it depends on the client's use-cases.

7. There are no performance expectations set on the library itself, as that would depend on factors not controlled by it, such as the toolchain and the hardware being used. What is usually the case is that the _applications_ for a _specific project_ have timing constraints, and then they test the library on their specific context (toolchain and HW) to assess if it meets the targets and is thus a viable solution, but again, this is context-specific, and therefore, would not be something that the library by itself can guarantee.

I hope I answered your questions properly, but if not, let me know and I can ellaborate further.

Message 3:
Hello @luiz.cordeiro

We had an internal discussion and have following points:

9. Firstly, we need to differentiate between Cryptographic hash and other hashes. In my understanding, Integrity objective for safety would need CRC but from security we would need hashing algorithms like SHA2 and SHA3. So the question here is about following hashing algorithms: SHA1, SHA256, SHA384, SHA512. Our recommendation is that all cryptographic hashes shall be supported only in security_crypto for following reasons:

1. One source: We have one place for all cryptographic use cases. To avoid confusion for SCORE users which API to be used Baselibs or security_crypto.
2. Hardware integration: Maybe some of these operations project would like to perform on the hardware (due to hardware accelerators and speed of operation) and we need to design the solution which can enable projects to achieve this. Hardware integration is one of the core part of security_crypto. .
3. Future extensions: There are other SHA algorithms as well like SHA3. There is also use case to support single shot apis (hashing done in one API call instead of three API calls). .
4. One OpenSSL library on target: Dependency on OpenSSL is in one place. we already have two more integration points for openSSL and we want to have only one openSSL libray on the target: https://github.com/orgs/eclipse-score/discussions/2839?sort=new#discussioncomment-16879873.

Other points:
10. If I get it right currently Baselibs support only SHA for hashing. other non cryptographic hashes are not supported like MurMurHash or?
11. Do we have FIPS certification for this implementation? Generally for cryptographic algorithm implementations most of the crypto library providers certify against FIPS certification.
12. Do we know if Configuration Management needed integrity for security use case or safety?
13. Sha1 is broken and is not recommended (at least from cryptographic purposes) and supporting this has a security risk that someone might use it without knowing that this should be ideally not used. Is there an explicit request why someone needs SHA1?. https://github.com/eclipse-score/baselibs/blob/main/score/hash/code/common/algorithms.h#L47

Message 4:
Hello @Sunilkumar Prasanchand,

We would have no problem to consolidate the algorithms under a crypto library, as long as the IEEE CRC32 and SHA-256/512 algorithms would be provided with ISO-26262 qualification, that is, that they can be used on safety-critical applications (FIPS is irrelevant for our context).
On Configuration Management our concern is only safety.
I'm not aware of any requirement for SHA1 support, but I don't have the full picture of all applications developed on our company either. We could add an obsoletion warning to it, and give a grace period before retiring it, no objections to doing so.

Message 5:
ok. now that we have alignment for medium term plan for moving SHA to crypto, we need to plan a step-wise migration transition. Migration proposal:

1. Inform in Baselib users that a migration is planned. .
2. Support Hashing algorithms SHA256, SHA384, SHA512 in security_crypto. .
3. Config management and other known users migrate from Baselib APIs to security_crypto APIs.
4. Remove these algorithms from Baselib. Update documentation that all cryptographic hashes are part of security_crypto. and in the same time we inform that SHA1 is depreciated. Major version update due to missing APIs? .

Some other points:
14. If the configuration management concern is safety, then, ideally they would need only CRC32. are they really using SHA as well and if yes why?
15. (in case we in security team decide) Is it possible that we move the current safety implementation to security_crypto? Background: there are also certain use cases/discussions where we might need to support hashing which is ASIL compliant, so that they can be directly part of the Crypto API and perform hashing faster. But when we use crypto libraries ex. OpenSSL, then, it becomes QM.
16. Currently this safety implementation is only for SHA256. if there is a need for other algorithm support SHA384, SHA512, SHA3, can we get support to implement this? Background: implementing this needs mathematical know how and generally in security team we integrate open source libraries and hardware's and not write algorithms on our own.

### Acceptance Criteria (DoD)

Migration of hashing functions from baselibs to crypto is completed

### How

_No response_