As The Key Size Is 128 The Secret Key Should Be 16 Characters Long

0 views

Skip to first unread message

Janne Desir

unread,

Aug 3, 2024, 4:08:18 PM8/3/24

to downparumo

If I'm using HS512 as a signing method the secret should have a length of 512 bits as far as I understand and I imagine that 512 bits are 64 characters (of 1 byte) because the secret is a string, as far as I understand.

But what I noticed Is that I could use any length I want for the secret, 1 character, 100 characters... It doesn't seem to affect anything outside the fact that bruteforcing 100 characters is way more difficult than bruteforcing 1 character.

Yes, the keys are keys in one sense. You can think of secrets as BINARY or OCTET STRING, but not as a text string. Most modern cryptography is designed to work on messages consisting of bits (theoretically) and bytes (practically).

Of course, those are hard to read from screen and hard to type using a keyboard, so usually these are represented using e.g. hexadecimals if they need to be displayed. In that case each 2 hex characters represents one byte.

Only in the sense that it may trigger the secret to be pre-hashed while that is unnecessary. However, a 512 bit key would give you 512 bits of security for HMAC, which is well over the maximum security of 256 that we commonly aim for. .

A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm. (Thisrequirement is based on Section 5.3.4 (Security Effect of the HMACKey) of NIST SP 800-117 [NIST.800-107], which states that theeffective security strength is the minimum of the security strengthof the key and two times the size of the internal hash value.)

The HMAC SHA-256 MAC is generated per RFC 2104, using SHA-256 asthe hash algorithm "H", using the JWS Signing Input as the "text"value, and using the shared key. The HMAC output value is the JWSSignature.

i found a source for android encryption..its using AES 128 Bit encryption..but the number of secret key is fix to 16character..can anyone tell me how to change the number secret key as our wish..i don't want limit the character for secret key..

Most symmetric encryption algorithm operate with blocks of fixed length and with keys of fixed length. For AES it's 16-byte block with 128-bit, 192-bit or 256-bit key. You can't have a different key length.

Now the key must ideally be 128-bit, not just "16 characters" (if you mean text symbols). 16 characters in ASCII alphabet is much less "meaningful" bits than 128. So to have 128 full-weight bits in encryption key you need to take a longer passphrase (at least 22 ASCII characters for 128-bit key), then apply one of key derivation functions (BCrypt, PBKDF) to your passphrase to get a key of the needed length.

The next thing to take into account is that you are now looking at low-level encryption where you will need to deal with cipher modes, padding etc. . If you are not well-acquainted with cryptography it makes sense to take a look at higher-level encryption standards which hide the low-level complexities from you. For example OpenPGP does surprisingly good job in encrypting the data using passphrases.

This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at

These guidelines provide technical requirements for federal agencies implementing digital identity services and are not intended to constrain the development or use of standards outside of this purpose. These guidelines focus on the authentication of subjects interacting with government systems over open networks, establishing that a given claimant is a subscriber who has been previously authenticated. The result of the authentication process may be used locally by the system performing the authentication or may be asserted elsewhere in a federated identity system. This document defines technical requirements for each of the three authenticator assurance levels. This publication supersedes corresponding sections of NIST Special Publication (SP) 800-63-2.

This table contains changes that have been incorporated into Special Publication 800-63B. Errata updates can include corrections, clarifications, or other minor changes in the publication that are either editorial or substantive in nature.

The ongoing authentication of subscribers is central to the process of associating a subscriber with their online activity. Subscriber authentication is performed by verifying that the claimant controls one or more authenticators (called tokens in earlier versions of SP 800-63) associated with a given subscriber. A successful authentication results in the assertion of an identifier, either pseudonymous or non-pseudonymous, and optionally other identity information, to the relying party (RP).

This document provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various Authenticator Assurance Levels (AALs). It also provides recommendations on the lifecycle of authenticators, including revocation in the event of loss or theft.

This technical guideline applies to digital authentication of subjects to systems over a network. It does not address the authentication of a person for physical access (e.g., to a building), though some credentials used for digital access may also be used for physical access authentication. This technical guideline also requires that federal systems and service providers participating in authentication protocols be authenticated to subscribers.

The strength of an authentication transaction is characterized by an ordinal measurement known as the AAL. Stronger authentication (a higher AAL) requires malicious actors to have better capabilities and expend greater resources in order to successfully subvert the authentication process. Authentication at higher AALs can effectively reduce the risk of attacks. A high-level summary of the technical requirements for each of the AALs is provided below; see Sections 4 and 5 of this document for specific normative requirements.

To satisfy the requirements of a given AAL, a claimant SHALL be authenticated with at least a given level of strength to be recognized as a subscriber. The result of an authentication process is an identifier that SHALL be used each time that subscriber authenticates to that RP. The identifier MAY be pseudonymous. Subscriber identifiers SHOULD NOT be reused for a different subject but SHOULD be reused when a previously-enrolled subject is re-enrolled by the CSP. Other attributes that identify the subscriber as a unique subject MAY also be provided.

Cryptographic authenticators used at AAL1 SHALL use approved cryptography. Software-based authenticators that operate within the context of an operating system MAY, where applicable, attempt to detect compromise (e.g., by malware) of the user endpoint in which they are running and SHOULD NOT complete the operation when such a compromise is detected.

Communication between the claimant and verifier (using the primary channel in the case of an out-of-band authenticator) SHALL be via an authenticated protected channel to provide confidentiality of the authenticator output and resistance to man-in-the-middle (MitM) attacks.

Periodic reauthentication of subscriber sessions SHALL be performed as described in Section 7.2. At AAL1, reauthentication of the subscriber SHOULD be repeated at least once per 30 days during an extended usage session, regardless of user activity. The session SHOULD be terminated (i.e., logged out) when this time limit is reached.