SHA-3 | C # implementation of the SHA-3 algorithm | Cryptography library

Okay, now I know what you want I've looked into this, and unfortunately I think you're out of luck. First to clarify, for Ethereum you want the signature in DER and the key format can vary depending on your software, but for an Ethereum account address you do NOT want the key in DER. Specifically an address is computed by:

1. represent the publickey point as raw X,Y coordinates, with no metadata like DER or even a single byte like X9.62 and no encoding like base64 or hex

2. take a Keccak256 hash and take the last 20 bytes, which can be represented (e.g. displayed) in hex with 0x prefixed for a total of 42 characters

For step 1, the keys used by OpenSSL, and thus by php's builtin module, are PEM format, as you see in your example, which consists of an ASN.1 (DER or sometimes BER) body encoded in base64 with linebreaks and header/trailer lines. Specifically the publickey is in the format defined by RFC7468 section 13 whose content is the SubjectPublicKeyInfo structure defined by X.509 and PKIX i.e. RFC5280 4.1.2.7 whose contents for a particular algorithm is defined in other standards; the case here, X9-style EC, is defined in RFC3279 2.3.5 and simplified by RFC5480 2.2 which reference X9.62 and SEC1. (Whew!) While these standards allow several options, OpenSSL in PHP always uses X9.62-uncompressed point format and DER encoding, so for this curve the data you need for Ethereum is simply the last 64 bytes of the DER decoded from the PEM:

Nit: SHAKEn are actually Extensible Output Functions (XOFs) built on the Keccak sponge in the same way that the (fixed length) SHA3 hashes are; see https://en.wikipedia.org/wiki/SHA-3#Instances .

But the point you seem to have misunderstood is that the underlying sponge makes each/all of these deterministic -- a given instance (parameterization) produces the same output everytime for the same input, and is not affected by the output size as such. Thus SHA3-256(m) is not the first 256 bits of SHA3-512(m) because it has different parameters, while SHAKE128(m,256) is the first 256 bits of SHAKE128(m,512) but is not SHAKE256(m,256).

Yes, you can truncate any SHA3 hash (or SHA2 hash for that matter) to a size smaller than its normal size and get a smaller but otherwise equally good crypto hash (pseudo-random, irreversible and noncolliding for real data), and people have in fact been doing exactly this for decades. But you can't safely increase it, which you can with an XOF like SHAKE.

The salt that was randomly generated must be stored in the database and linked to the user that logged in. It could be simply added as another column in the user table.

In a typical setting, the salt and the password (or its version after key stretching) are concatenated and processed with a cryptographic hash function, and the output hash value (but not the original password) is stored with the salt in a database

Source: https://en.wikipedia.org/wiki/Salt_(cryptography) retrieved 19/02/21

The generation of the salt depends on which technology you are using. The following stack overflow answer has an example for PHP:

Can we use uniqid() to generate a unique Salt in PHP

The password should also never be sent in plain text to the server. This can be done via HTTPS for example

According to https://lapo.it/asn1js/ your private key in PEM encoding is still an encrypted one - directly visible with "-----BEGIN ENCRYPTED PRIVATE KEY-----":

Try to use this URL: http://timestamp.globalsign.com/scripts/timestamp.dll instead.

In your code: $oSignedCode.Timestamp("http://timestamp.globalsign.com/scripts/timestamp.dll")

The address is the last 20 bytes of the sha3-256 of 3059301306072a8648ce3d020106082a8648ce3d030107034200 + public_key_hex

In my example, take the last 160 bits (20 bytes) of "result" :

well i fiddled around with the Build.properties.default file

the download link for the current versions is in line 96 and the one for the archives is in 97 i do not know why the ant build doesn't try the archives if it fails at using the current version of the files but all it took was to replace the value of base-apache.loc.1 by the value of base-apache.loc.2

it's a hodgepodge and a mess of a solution to be honest but it worked so if anyone has this problem go ahead and try it

You can achieve SHA-3 256 Hashing with a SQL Server CLR integration

There is a project on GitHub that has most of the work done for you already and you could easily add SHA3 support to it.

https://github.com/sedenardi/sql-hashing-clr

There is no way of SHA3-256 hashing with pure dotnet core. I recommend you make use of BouncyCastle library (https://www.bouncycastle.org/csharp/index.html) that has a SHA3-256 support. There is a nuget library package that is a wrapper on top of BouncyCastle and could make SHA3-256 hashing relatively easy to achieve. https://www.nuget.org/packages/SHA3.Net/. You'll need to use this package and update HashUtil.cs

Pre Req: Build CLR .dll

I think I found the solution. It is described in appendix of FIPS 202 B.1 (starting on page 26). A hint on this topic is given on page 25:

The convention for interpreting hexadecimal strings as bit strings for the inputs and outputs of the SHA-3 examples is different from the convention for other functions on the examples page. The conversion functions between hexadecimal strings and SHA-3 bit strings are specified in Sec. B.1. For byte-aligned messages, the hexadecimal forms of the padding for the SHA-3 functions are described in Sec. B.2.

There is a good explanation on how to circumvent this issue on cryptologie.net.