Package com.codename1.security
package com.codename1.security
The part of the client's cryptography a server shares with it: the portable Java digests and message authentication codes, and the one-time passwords built on them.
Otp-- RFC 4226 and RFC 6238 one-time passwords: the codes an authenticator application shows. Being the same class the client runs, a code made on a device is the code a server expects.Base32-- the encoding an authenticator's shared secret travels in.Hash/Hmac-- MD5, SHA-1, the SHA-2 family, SHA3-256 and Keccak-256 (Ethereum's hash), and HMAC over each, written in Java. They are whatOtpcomputes with.Secp256k1-- ECDSA over the curve of Bitcoin and Ethereum: key derivation, deterministic low-S signing, verification and public key recovery. A server can sign a chain transaction, or check the signature a wallet made on the device, with the class the device used.SchnorrandEd25519-- BIP-340 signatures (Bitcoin's Taproot) and RFC 8032 signatures (Solana and many protocols beside).Pbkdf2-- the key derivation behind a BIP-39 recovery phrase.CryptoBatch-- many verifications or hashes in one call: the deposits of a block an exchange scans. Each entry gets the single call's answer.CertificateRequest-- PKCS#10 certificate signing requests. A headless device enrolls for its mutual TLS client certificate with it, signing throughCrypto.
Where native kernels are compiled in -- a packaged ParparVM server -- the
curves, the hashes and the batches run in C through CryptoEngine, a
batch on every core; the bytes are the same as the Java implementation's.
A server reaches for these to verify a second factor and for little else.
What a request path computes -- a password hash, a token's signature, a
digest of something large -- goes through
Crypto, which is OpenSSL in a packaged server and
several times faster.
The client has more in this package -- ciphers, signatures, key storage -- which a server does not: see the client API reference.
-
ClassDescriptionBase32 encoder/decoder per RFC 4648.A PKCS#10 certificate signing request (RFC 2986): what a device sends a certificate authority to get the client certificate it then presents over mutual TLS.Signs the encoded request body with the private key matching the request's public key, using
CertificateRequest.getSignatureAlgorithm().Many signature verifications or hashes in one call: the deposits of a block an exchange scans, the transactions an indexer checks, the leaves of a Merkle tree.The answer of an asynchronous batch.The seam through which a platform supplies faster implementations of the compute-heavy cryptography in this package.Thrown by classes in this package when a cryptographic operation fails.Ed25519 signatures (RFC 8032): the signatures of Solana, Cardano, Stellar, Tezos, SSH keys and many protocols beside.Streaming and one-shot cryptographic hash (message digest) functions.HMAC-based key derivation (HKDF), per RFC 5869.Keyed-hash message authentication (HMAC, RFC 2104) on top of any hash algorithm supported byHash.TheCryptoEngineof the ParparVM targets (iOS, macOS, native Windows and Linux, and the backend): secp256k1, Schnorr, Ed25519 and Keccak run in the linked C kernels, everything else goes to the engine it wraps.Counter-based (HOTP, RFC 4226) and time-based (TOTP, RFC 6238) one-time password generators.PBKDF2 (RFC 8018) with HMAC-SHA-256 or HMAC-SHA-512: the password hash of key stores and vaults, and with SHA-512 and 2048 iterations the seed of a BIP-39 mnemonic.BIP-340 Schnorr signatures over secp256k1: the signatures of Bitcoin's Taproot (key-path spends, P2TR) and of Nostr events.A private key with its x-only public key, derived once, for signing many messages; the counterpart of libsecp256k1'ssecp256k1_keypair.ECDSA over the secp256k1 curve, the signature scheme of Bitcoin and Ethereum, written in portable Java so a wallet can sign on the device and a server can verify or sign with the same class.An ECDSA signature:randsas 32-byte big-endian integers, and the recovery id a signer knows and a verifier does not need.