mirror of
https://github.com/luxfi/crypto.git
synced 2026-07-27 01:54:50 +00:00
Hanzo AI
4b3f96ab40
The user's call: "ethcrypto is not acceptable. It encodes the wrong domain. The fact that Keccak/ECDSA are used for EVM address derivation does not make the package Ethereum, and it definitely does not justify an eth* alias inside a repo trying to purge ETH naming. decomplect" Decomplecting (Rich Hickey: separate the value from the brand): 1. ecies/params.go: drop `ethcrypto "github.com/luxfi/crypto"` import alias. Replace with direct `"github.com/luxfi/crypto/secp256k1"` import — the file uses `S256()` (the secp256k1 curve), so it imports the curve provider directly. The "ethcrypto" alias was gratuitous branding; secp256k1 is a curve, not an Ethereum primitive. 2. secp256k1/keys.go: rename `EthAddress()` → `KeccakAddress()` on both PrivateKey and PublicKey. The derivation is "last 20 bytes of Keccak256(uncompressed_pubkey)"; that primitive predates and is consumed by every EVM chain (Lux C-Chain, Polygon, BSC, Partner EVM, Hanzo EVM, etc.). The "Eth" label braids the value with one brand. KeccakAddress names the VALUE; the docstring notes EVM-compatible chains consume it but no longer implies Ethereum-specificity. `EthAddress()` retained as a `// Deprecated:` alias delegating to KeccakAddress so downstream callers (node, cli, mpc) don't break in one wave. Linter will flag usages; downstream migrations land at their own pace. 3. Address() vs KeccakAddress(): the existing Address() returns the Lux native X-Chain / P-Chain format (SHA256+RIPEMD160 → ShortID). Both methods are now brand-neutral and describe the derivation, not the consumer. The banderwagon test seed "eth_verkle_oct_2021" is left as-is — it is an external constant from the Ethereum Foundation Verkle research, not a Lux naming choice; renaming would break the KAT invariant. Per CLAUDE.md x.x.x+1.
# NOTE
This implementation is direct fork of Kylom's implementation. I claim no authorship over this code apart from some minor modifications.
Please be aware this code **has not yet been reviewed**.
ecies implements the Elliptic Curve Integrated Encryption Scheme.
The package is designed to be compliant with the appropriate NIST
standards, and therefore doesn't support the full SEC 1 algorithm set.
STATUS:
ecies should be ready for use. The ASN.1 support is only complete so
far as to supported the listed algorithms before.
CAVEATS
1. CMAC support is currently not present.
SUPPORTED ALGORITHMS
SYMMETRIC CIPHERS HASH FUNCTIONS
AES128 SHA-1
AES192 SHA-224
AES256 SHA-256
SHA-384
ELLIPTIC CURVE SHA-512
P256
P384 KEY DERIVATION FUNCTION
P521 NIST SP 800-65a Concatenation KDF
Curve P224 isn't supported because it does not provide a minimum security
level of AES128 with HMAC-SHA1. According to NIST SP 800-57, the security
level of P224 is 112 bits of security. Symmetric ciphers use CTR-mode;
message tags are computed using HMAC-<HASH> function.
CURVE SELECTION
According to NIST SP 800-57, the following curves should be selected:
+----------------+-------+
| SYMMETRIC SIZE | CURVE |
+----------------+-------+
| 128-bit | P256 |
+----------------+-------+
| 192-bit | P384 |
+----------------+-------+
| 256-bit | P521 |
+----------------+-------+
TODO
1. Look at serialising the parameters with the SEC 1 ASN.1 module.
2. Validate ASN.1 formats with SEC 1.
TEST VECTORS
The only test vectors I've found so far date from 1993, predating AES
and including only 163-bit curves. Therefore, there are no published
test vectors to compare to.
LICENSE
ecies is released under the same license as the Go source code. See the
LICENSE file for details.
REFERENCES
* SEC (Standard for Efficient Cryptography) 1, version 2.0: Elliptic
Curve Cryptography; Certicom, May 2009.
http://www.secg.org/sec1-v2.pdf
* GEC (Guidelines for Efficient Cryptography) 2, version 0.3: Test
Vectors for SEC 1; Certicom, September 1999.
http://read.pudn.com/downloads168/doc/772358/TestVectorsforSEC%201-gec2.pdf
* NIST SP 800-56a: Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography. National Institute of Standards
and Technology, May 2007.
http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf
* Suite B Implementer’s Guide to NIST SP 800-56A. National Security
Agency, July 28, 2009.
http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf
* NIST SP 800-57: Recommendation for Key Management – Part 1: General
(Revision 3). National Institute of Standards and Technology, July
2012.
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf