TWI811514B - Computer program product, computer system and computer implement method for compute digital signature authentication sign instruction - Google Patents

Abstract

A single architected instruction to produce a signature for a message is obtained. The instruction is executed, and the executing includes determining a sign function of a plurality of sign functions supported by the instruction to be performed. Input for the instruction is obtained, and the input includes a message and a cryptographic key. A signature is produced based on the sign function to be performed and the input. The signature is to be used to verify the message.

Description

Computer program product, computer system and computer implementation method for calculating digital signature authentication mark instructions

One or more aspects relate generally to facilitating processing within a computing environment, and specifically to facilitating the generation and verification of digital signatures used to authenticate messages transmitted within the computing environment.

Digital signatures are used to verify the authenticity of digital messages. The sender of the message marks the message with a digital signature and sends the marked message to the receiver. The recipient uses the digital signature to verify the sender of the message and confirm that the message has not been modified.

To generate and/or verify digital signatures, authentication technology is used. Example authentication technologies include Elliptic Curve Digital Signature Algorithm (ECDSA), Edwards Curve Digital Signature Algorithm (EdDSA), and other technologies. Each authentication technology is based on mathematical constructs. For example, the Elliptic Curve Digital Signature Algorithm and the Edwards Curve Digital Signature Algorithm use elliptic curves to generate and/or verify digital signatures.

Algorithms are implemented in software programs used to generate and/or verify digital signatures. The software program includes a number of primitive software instructions for generating a digital signature, and/or a number of primitive software instructions for verifying the digital signature.

Overcome the shortcomings of prior technologies and provide additional advantages by providing computer program products for facilitating processing within a computing environment. A computer program product includes a computer-readable storage medium that can be read by processing circuitry and stores instructions for performing a method. The method includes obtaining instructions for generating a signature for the message. This directive is a single architectural directive. The instruction is executed, and the execution includes determining a tagged function of a plurality of tagged functions supported by the instruction to be executed. Input for the command is obtained, and the input includes the message and password key. Generate a signature based on the tagged function to be executed and the input. This signature is used to verify the message.

By using a single architected instruction, a significant subset of the primitive software instructions used to execute a function is replaced by a single architected instruction. Replacing these primitive instructions with a single architectural instruction reduces program complexity and eliminates the need to include code to optimize the primitive instructions. Overall performance is improved. Additionally, by using a single command, intermediate results are encrypted, thereby enhancing security.

In one example, the message is a hashed message.

Furthermore, in one instance, the signature is represented by a plurality of values. The plurality of values includes, for example, a first integer and a second integer between zero and the degree of the curve for the labeling function to be performed. As a specific example, the marking function is an Edwards Curve digital signature algorithm marking function, and the plurality of values includes compressed points and integers.

In another example, the input further includes random numbers.

Furthermore, in one embodiment, the execution includes testing that the random number is between the first value and the second value; and performing signature generation based on the random number being between the first value and the second value. As an example, the first value is zero, and the second value represents the order of the base point on the curve for the labeling function to be performed.

In one example, a plurality of labeled functions include complex numbers for a plurality of prime numbers. Several elliptic curve digital signature algorithm marking functions. Complex prime numbers include, for example, the National Institute of Standards and Technology (NIST) prime number P256, the NIST prime number P384, and the NIST prime number P521. In another example, the plurality of marking functions includes a plurality of Edwards Curve digital signature algorithm marking functions for a plurality of prime numbers. The complex prime numbers include the Edwards curve prime number Ed25519 and the Edwards curve prime number Ed448.

Computer-implemented methods and systems related to one or more aspects are also described and claimed herein. In addition, services related to one or more aspects are described and may be advocated herein.

Additional features and advantages are achieved through the techniques described in this article. Other embodiments and aspects are described in detail herein and are considered a part of the claimed aspects.

10:Computing environment

12: Native central processing unit (CPU)

14:Memory

16:Input/output device/interface

18:Bus

20:Native temporary register

22: Emulator code

30:Object command

32: Instruction extraction routine

34: Instruction translation routine

36:Native instructions

40: Simulation control routine

50:Cloud computing environment

52:Cloud computing node

54A: Personal Digital Assistant (PDA)/Cellular Phone

54B:Desktop computer

54C:Laptop

54N:Automotive computer system

60:Hardware and software layer

61:Large computer

62: Server based on reduced instruction set computer (RISC) architecture

63:Server

64: Blade Server

65:Storage device

66: Network and network connection components

67:Web application server software

68: Database software

70:Virtualization layer

71:Virtual server

72:Virtual storage

73:Virtual network

74:Virtual Applications and Operating Systems

75:Virtual client

80:Management

81: Resource deployment

82:Measurement and Pricing

83:User Portal

84:Service level management

85: Service Level Agreement (SLA) Planning and Implementation

90:Workload layer

91:Map mapping and navigation

92:Software development and life cycle management

93:Virtual classroom education delivery

94:Data analysis and processing

95: Change processing

96: Marking/verification processing

100:Computing environment

102: Processor

104:Memory

106: Input/output (I/O) device/interface

108:Bus

120: Instruction extraction component

122: Instruction decoding unit

124:Instruction execution component

126:Memory access component

130: Write back component

136: Marking/validating components

155: Facility bits

200: Central Electronics Complex (CEC)

202: Memory/main storage

204: Processor/Central Processing Unit (CPU)/Physical Processor Resources

206: Input/output subsystem

208: Logical partition

210:Super manager

212:Processor firmware

220:Object operating system

222: Different programs

230: Input/output control unit

240: Input/output (I/O) device

250:Data storage device

252:Program

254: Computer readable program instructions

260: Marking/validating components

300: Computed Digital Signature Authentication (KDSA) command

302:Operation code field

304: First register field (R ₁ )

306: Second register field (R ₂ )

309: General register 0

312: Function code field

313: Function code 0

314: General register 1

315: Function code 1

316: Logical address

317: Function code 2

319: Function code 3

321: Function code 9

323: Function code 10

325: Function code 11

326: General register R ₂

327: Function code 17

328: Address of the second operand

329: Function code 18

330: General register R ₂ +1

331: Function code 19

332:The length of the second operand

333: Function code 32

335: Function code 36

337: Function code 40

339: Function code 44

341: Function code 48

343: Function code 52

400: Parameter block

401: Status word

402: Parameter block

403:Signature(R)

404:Signature(S)

405: Hash message H(msg)

406: Public cryptographic key (K)

407: Reserved save area

408: Parameter block

409:Signature(R)

410:Signature(S)

411: Hash message

412: Public cryptographic key (K)

413: Reserved save area

414: Parameter block

415:Signature (R)

416:Signature(S)

417: Hash message

418:Public cryptographic key

419: Reserved save area

420: Parameter block

421:Signature (R)

422:Signature(S)

423: Hash message

424: Private password key in plain text

425: random number

426: Reserved save area

427: Parameter block

428:Signature(R)

429:Signature(S)

430: Hash message

431: Private password key in plain text (K)

432: Random number

433: Reserved save area

434: Parameter block

435:Signature (R)

436:Signature(S)

437: Hash message

438: Private password key in plain text

439: Random number

440: Reserved save area

441: Parameter block

442:Signature(R)

443:Signature(S)

444: Hash message

445: Encryption private cryptographic key (WK _a (K))

446: Random number

447:AES wrapped key verification pattern (WK _a VP)

448: Reserved save area

449: Parameter block

450:Signature (R)

451:Signature(S)

452: Hash message

453: Encryption private cryptographic key (WK _a (K))

454: Random number

455:AES wrapped key verification pattern (WK _a VP)

456: Reserved save area

457: Parameter block

458:Signature (R)

459:Signature(S)

460: Hash message

461: Encryption private cryptographic key (WK _a (K))

462: Random number

463:AES wrapped key verification pattern (WK _a VP)

464: Reserved save area

468: Parameter block

469:Signature (R)

470:Signature(S)

471: Public cryptographic key (K)

472: Reserved save area

473: Parameter block

474:Signature (R)

475:Signature(S)

476: Public cryptographic key (K)

477: Reserved save area

478: Parameter block

479:Signature(R)

480:Signature(S)

481: Private password key in plain text (K)

482: Reserved save area

483: Parameter block

484:Signature (R)

485:Signature(S)

486: Private password key in plain text (K)

487: Reserved save area

488: Parameter block

489:Signature(R)

490:Signature(S)

491: Encryption private cryptographic key (WK _a (K))

492:AES wrapped key verification pattern (WK _a VP)

493: Reserved save area

494: Parameter block

495:Signature (R)

496:Signature(S)

497: Encryption private cryptographic key (WK _a (K))

498:AES wrapped key verification pattern (WK _a VP)

499: Reserved save area

500: steps

502:Query

504: Step

506: Step

508:Step

510: Steps

512:Step

514:Step

516:Step

600: Steps

602:Query

604: Step

606: Step

608: Step

610: Steps

612:Query

614: Step

616: Steps

618:Query

620: Steps

622: Steps

700: Steps

702: Step

704: Step

706: Step

708:Step

710: Steps

800: Step

802: Step

804: Step

806: Step

808:Step

810: Steps

812: Steps

814: Steps

816: Steps

818: Steps

820: Steps

1000: steps

1002: Steps

1004: Steps

1006: Steps

1008: Steps

1010: Steps

1012: Steps

1014: Steps

1016: Steps

1018: Steps

1019: Steps

1020: Steps

1022: Steps

1024: Steps

1026: Steps

1028: Steps

1030: Steps

1032: Steps

1034: Steps

One or more aspects are specifically pointed out and distinctly claimed as examples in the patent claims at the end of this specification. The foregoing content and objectives, features and advantages of one or more aspects of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: Figure 1A depicts a computing environment incorporating and using one or more aspects of the invention. One example; Figure 1B depicts additional details of the processor of Figure 1A according to one or more aspects of the invention; Figure 2 depicts another example of a computing environment incorporating and using one or more aspects of the invention; Figure 3A depicts a format of a Computational Digital Signature Authentication (KDSA) instruction according to one aspect of the invention; Figure 3B depicts an implicit register (general purpose register 0) used by the instruction according to one aspect of the invention. ); FIG. 3C depicts an example of a function code supported by an instruction according to an aspect of the invention; FIG. 3D depicts an implicit register used by an instruction according to an aspect of the invention. (An example of the fields of the general register 1); FIG. 3E depicts an example of the contents of the register R _{2 specified by the computational digital signature authentication command according to one aspect of the present invention; FIG. 3F depicts an example of the contents of the register R 2} specified by the computational digital signature authentication command according to one aspect of the present invention; An example of the contents of the register R ₂ +1 used by the computational digital signature authentication command according to one aspect of the invention; Figures 4A to 4P depict the contents of the computational digital signature authentication command according to one aspect of the invention. Examples of the contents of parameter blocks used by various functions; Figure 5 depicts an example of processing associated with verifying a signature using an elliptic curve digital signature algorithm in accordance with an aspect of the present invention; Figure 6 depicts an example of a signature in accordance with an aspect of the present invention. An example of processing associated with generating a signature using an elliptic curve digital signature algorithm, according to one aspect of the invention; Figure 7 depicts processing associated with verifying a signature using an Edwards curve digital signature algorithm, according to one aspect of the invention. An example of processing; Figure 8 depicts an example of processing associated with generating a signature using an Edwards curve digital signature algorithm according to an aspect of the present invention; Figure 9 depicts a process for generating a signature according to an aspect of the present invention; Example key lengths and displacements of functions that calculate digital signature authentication instructions; Figures 10A-10B depict an example of facilitating processing within a computing environment according to an aspect of the present invention; Figure 11A depicts the implementation and use of the present invention Another example of one or more aspects of a computing environment; Figure 11B depicts additional details of the memory of Figure 11A; Figure 12 depicts an embodiment of a cloud computing environment; and Figure 13 depicts an example of an abstract model layer.

According to an aspect of the invention, a capability is provided to facilitate processing within a computing environment. As one example, a single instruction (eg, a single architected hardware machine instruction at a hardware/software interface) is provided to perform an operation, such as computing a digital signature authentication operation. The instructions are part of a general-purpose processor instruction set architecture (ISA) that is scheduled by a program (eg, a user program) on a processor, such as a general-purpose processor.

In one example, a command called a Computational Digital Signature Authentication command (KDSA) is used to generate a signature that is used to mark a message for transmission and to verify the authenticity of the message upon receipt. The instruction is, for example, the Information Security Auxiliary Extension (eg, Information Security Auxiliary Extension 9) of the z/ ^{Architecture®} hardware architecture provided by International Business Machines Corporation of Armonk, New York. Facilities section. The message security auxiliary extension supports elliptic curve cryptography authentication of messages, elliptic curve key generation and scalar multiplication. The Computational Digital Signature Authentication command supports elliptic curve marking and verification. The functions provided by this command include, for example: KDSA-query, KDSA-ECDSA-verify-P256, KDSA-ECDSA-verify-P384, KDSA-ECDSA-verify-P521, KDSA-ECDSA-mark-P256, KDSA-ECDSA- Mark-P384, KDSA-ECDSA-Mark-P521, KDSA-Encrypt-ECDSA-Mark-P256, KDSA-Encrypt-ECDSA-Mark-P384, KDSA-Encrypt-ECDSA-Mark-P521, KDSA-EdDSA-Verify-Ed25519, KDSA-EdDSA-authenticate-Ed448, KDSA-EdDSA-mark-Ed25519, KDSA-EdDSA-mark-Ed448, KDSA-encrypt-EdDSA-mark-Ed25519, and KDSA-encrypt-EdDSA-mark-Ed448. In addition to query functions, these functions are used to tag and validate messages using various techniques using different National Institute of Standards and Technology (NIST) primes.

One embodiment of a computing environment in which one or more aspects of the present invention are incorporated and used is described with reference to FIG. 1A. For example, computing environment 100 includes processor 102 (eg, central processing unit), memory 104 (eg, main memory; also referred to as system memory, main storage, central storage, storage), and one or A plurality of input/output (I/O) devices and/or interfaces 106, each of which is coupled to one another via, for example, one or more busses 108 and/or other connections.

In one example, processor 102 is based on the z/Architecture hardware provided by International Business Machines Corporation of Armonk, New York, and is part of a server such as an IBM ^Z® server, also provided by International Business Machines Corporation. Business Machines provides and implements the z/Architecture hardware architecture. One embodiment of the z/Architecture hardware architecture is described in the publication titled "z/Architecture Principles of Operation" (IBM Publication No. SA22-7832-11, 12th Edition, 2017 September), the publication is hereby incorporated into this article by reference in full. However, the z/Architecture hardware architecture is only one example architecture; other architectures and/or other types of computing environments may include and/or utilize one or more aspects of the present invention. In one example, the processor executes an operating system also provided by International Business Machines Corporation, such as the z/ ^OS® operating system.

Processor 102 includes a plurality of functional components for executing instructions. As depicted in FIG. 1B , these functional components include, for example, an instruction fetch component 120 for fetching instructions to be executed, and an instruction decoding unit 122 for decoding the fetched instructions and obtaining the operands of the decoded instructions. ; instruction execution component 124, which is used to execute the decoded instructions; memory access component 126, which is used to access the memory for instruction execution when necessary; and writeback component 130, which is used to provide the executed instructions the result. In accordance with one or more aspects of the invention, one or more of these components may include a marking/authentication process (or may use one or more aspects of the invention). or may be accessible to at least a portion of one or more other components used in other processes, as described herein. One or more other components include, for example, marking/validation component (or other component) 136 . By way of example, the marking/verification process includes generating a signature, transmitting the message via the signature, and/or using the signature to authenticate the received message and/or the sender.

Another example of a computing environment incorporating and using one or more aspects of the present invention is described with reference to FIG. 2 . In one example, the computing environment is based on the z/Architecture hardware architecture; however, the computing environment may be based on other architectures provided by International Business Machines Corporation or other companies.

Referring to FIG. 2 , in one example, a computing environment includes a central electronics complex (CEC) 200 . CEC 200 includes a plurality of components, such as memory 202 (also referred to as system memory, main memory, main storage, central storage, storage), which is coupled to one or more processors (also referred to as central storage). processing unit (CPU) 204 and input/output subsystem 206.

Memory 202 includes, for example, one or more logical partitions 208, a hypervisor 210 that manages the logical partitions, and processor firmware 212. One example of hypervisor 210 is the Processor Resource/System Manager (PR/SM ^™ ) hypervisor provided by International Business Machines Corporation of Armonk, New York. As used herein, firmware includes, for example, the microcode of a processor. This includes, for example, hardware-level instructions and/or data structures used to implement higher-level machine code. In one embodiment, this includes, for example, proprietary code, typically delivered as microcode that includes trusted software or microcode specific to the underlying hardware, and controls operating system access to the system hardware.

Each logical partition 208 can act as a separate system. That is, each logical partition can be independently reconfigured to run a guest operating system 220 such as the z/OS operating system or another operating system and operate with different programs 222 . An operating system or application running in a logical partition appears to have access to the complete system, but in reality, only a portion of it is available.

Memory 202 is coupled to a processor (e.g., CPU) 204 that is allocable to The physical processor resources of the logical partition. For example, logical partition 208 includes one or more logical processors, each of which represents all or a portion of the physical processor resources 204 that can be dynamically allocated to the logical partition.

Additionally, memory 202 is coupled to I/O subsystem 206 . I/O subsystem 206 may be part of or separate from the central electronics complex. It directs the flow of information between the main storage 202 and the input/output control unit 230 and input/output (I/O) devices 240 coupled to the central electronic device complex.

Many types of I/O devices can be used. One specific type is data storage device 250. The data storage device 250 may store one or more programs 252, one or more computer-readable program instructions 254, and/or data, etc. Computer readable program instructions may be configured to perform the functions of embodiments of aspects of the invention.

As one example, each processor 204 includes and/or has access to a marking/verification component (or other component) 260 that performs generating a signature for marking a message, transmitting the message using the signature, and/or or one or more of the verification of the digital signature (and/or other operations of one or more aspects of the invention). In various instances, there may be one or more components that perform one of these tasks. Many variations are possible.

Central electronic device complex 200 may include and/or be coupled to removable/non-removable, volatile/non-volatile computer system storage media. For example, it may include and/or be coupled to non-removable non-volatile magnetic media (commonly referred to as "hard drives"), for self-removable non-volatile disks (e.g., "floppy disks" ) disk drives that read and write to removable non-volatile disks (e.g., "floppy disks") and/or for removable non-volatile disks from such as CD-ROMs, DVD-ROMs, or other optical media. An optical disc drive that reads or writes removable non-volatile optical discs. It should be understood that other hardware and/or software components may be used in conjunction with central electronics complex 200. real Examples include but are not limited to: microcode, device drivers, redundant processing units, external disk arrays, RAID systems, tape drives, and data archiving storage systems.

Additionally, central electronics complex 200 may operate with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations suitable for use with central electronic device complex 200 include, but are not limited to: personal computer (PC) systems, server computer systems, thin clients, complex Clients, handheld or laptop computer devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, small computer systems, mainframe computer systems and other Distributed cloud computing environment of any file system or device, etc.

Although various examples of computing environments are described herein, one or more aspects of the invention may be used with many types of environments. The computing environments provided in this article are examples only.

According to one aspect of the invention, a computing environment such as computing environment 100 or central electronic device complex 200 employs an information security-assisted extension that provides a mechanism for generating digital signatures and/or verifying digital signatures. In one example, when the facility indicator is set to, for example, one, the Information Security Assistance Extensions facility (eg, the Information Security Assistance Extensions 9 facility) is installed in the system. As a specific example of z/Architecture hardware architecture, when a facility is installed in z/Architecture architectural mode, facility bit 155 is set to, for example, one. Facilities include, for example, computing digital signature authentication instructions, examples of which are described below.

One embodiment of a Computational Digital Signature Authentication (KDSA) instruction is described with reference to FIGS. 3A to 3F. In one example, the instructions are executed using a processor such as a general purpose processor (eg, processor 102 or 204). In the descriptions herein, a specific location, a specific field, and/or a specific size of a field (eg, a specific byte and/or bit) are indicated. However, other bits are available position, fields and/or size. Furthermore, although it is specified that a bit be set to a specific value such as one or zero, this is only an example. In other examples, the bits may be set to a different value, such as the opposite value or another value. Many variations are possible.

Referring to Figure 3A, in one example, a Computed Digital Signature Authentication (KDSA) command 300 is formatted in an RRE format representing registers and register operations with extended opcode (opcode) fields. As an example, the instruction includes: opcode field 302 (e.g., bits 0 to 15) having an opcode indicating a computed digital signature authentication operation; first register field (R ₁ ) 304 (e.g., Bits 24 to 27), which in one example are reserved and should include zero; and second register field (R ₂ ) 306 (e.g., bits 28 to 31), which designates a pair of general purpose registers device. The contents of the register specified by _R2 field 306 specify the location (in memory) of the second operand. The content of R ₂ +1 specifies the length of the second operand. In one example, bits 16 to 23 of the instruction are reserved and should contain zeros; otherwise, the program may not operate consistently in the future. As used in this article, a program is the program that issued the instruction. It may be a user program or another type of program.

In one embodiment, instruction execution includes the use of one or more implicit general purpose registers (ie, registers not explicitly specified by the instruction). For example, general purpose registers 0 and 1 are used to execute instructions, as described herein. In one example, general purpose register 0 contains various controls that affect the operation of the instruction, and general purpose register 1 is used to provide the location of the parameter block used by the instruction.

As an example, referring to Figure 3B, general register 0 (309) includes a function code field 312, which includes a function code. In one specific example, bit locations 57 to 63 of general register 0 contain the function code; in other embodiments, other bit locations may be used to contain the function code. Additionally, bits 0 to 31 of general register 0 are ignored, and bits 32 to 56 are reserved and should contain zeros; otherwise, the program may not operate consistently in the future. In one example, when bits of general register 0 A specification exception is recognized when 57 to 63 specify unassigned or uninstalled function code.

Figure 3C shows an example of a Computed Digital Signature Authentication (KDSA) command with assigned function codes, and includes, for example: function code 0 (313) indicating the KDSA-query function; indicating the KDSA-ECDSA-verify-P256 function. Function code 1 (315) of the formula; function code 2 (317) instructing the KDSA-ECDSA-verify-P384 function; function code 3 (319) instructing the KDSA-ECDSA-verify-P521 function; instructing KDSA - Function code 9 (321) for the ECDSA-mark-P256 function; Function code 10 (323) for the KDSA-ECDSA-mark-P384 function; Function code for the KDSA-ECDSA-mark-P521 function 11(325); Function code 17(327) indicating the KDSA-Encryption-ECDSA-Mark-P256 function; Function code 18(329) indicating the KDSA-Encryption-ECDSA-Mark-P384 function; Instructing the KDSA- Function code 19 (331) for the encryption-ECDSA-mark-P521 function; function code 32 (333) for the KDSA-EdDSA-verification-Ed25519 function; function code 32 (333) for the KDSA-EdDSA-verification-Ed448 function Code 36 (335); function code 40 (337) indicating the KDSA-EdDSA-mark-Ed25519 function; function code 44 (339) indicating the KDSA-EdDSA-mark-Ed448 function; indicating KDSA-encryption-EdDSA - Function code 48 (341) of the mark-Ed25519 function; and function code 52 (343) indicating the KDSA-encryption-EdDSA-mark-Ed448 function.

Each function uses a parameter block and the size of the parameter block depends on the function in an instance. The instance parameter block size used for the function, and the instance data block size (if applicable) are depicted in Figure 3C. In this example, no other function codes are assigned. Although example functions and function codes are described, other functions and/or function codes may be used.

The parameter block is specified by, for example, general purpose register 1. In one example, referring to Figure 3D, the contents of general register 1 (314) specify, for example, the logical address 316 of the leftmost byte of the parameter block in memory. For example, in the 24-bit addressing mode, the contents of bit positions 40 to 63 of general register 1 constitute the address, and the contents of bit positions 0 to 39 are ignored. in 31 bits In the addressing mode, the contents of bit positions 33 to 63 of the general register 1 constitute the address, and the contents of bit positions 0 to 32 are ignored. In 64-bit addressing mode, the contents of bit positions 0 to 63 of general-purpose register 1 constitute the address. In access register mode, access register 1 specifies the address space containing the parameter block. Additional details about parameter blocks for various functions are described further below.

Returning to Figure 3A, the _R2 field 306 specifies the even-odd pair of general-purpose registers, and will specify, for example, even-numbered registers other than general-purpose register 0; otherwise, a specification exception is recognized. As shown in Figure 3E, the contents of general register _R2 (326) indicate the second operand address 328. For example, depending on the addressing mode, the position of the leftmost byte of the second operand is specified by the contents of the _R2 general-purpose register. In one embodiment, in the 24-bit addressing mode, the contents of bit positions 40 to 63 of the general register R ₂ constitute the address of the second operand, and the contents of bit positions 0 to 39 are ignored; Bits 40 to 63 of the updated address replace the corresponding bits in the general register R ₂ , ignoring the carry output at bit position 40 of the updated address, and bit positions 32 to 39 of the general register R ₂ content is set to zero. In the 31-bit addressing mode, the contents of bit positions 33 to 63 of the general register R ₂ constitute the address of the second operand, and the contents of bit positions 0 to 32 are ignored; the bits of the updated address 33 to 63 replace the corresponding bits in general register R ₂ , ignore the carry output at bit position 33 of the updated address, and set the content of bit position 32 in general register R ₂ to zero. In the 64-bit addressing mode, the contents of bit positions 0 to 63 of the general register R ₂ constitute the address of the second operand; the updated address bits 0 to 63 replace the contents of the general register R ₂ content, and ignore the carry output from bit position 0.

The number of bytes in the second operand position is specified in general register R ₂ +1. As shown in FIG. 3F, the contents of the general register R ₂ +1 (330) are used to determine the length of the second operand 332. In one embodiment, in both 24-bit and 31-bit addressing modes, the contents of bit positions 32 to 63 of general register R ₂ +1 form a number specifying the number of bytes in the second operand. 32-bit unsigned binary integer; and the updated value replaces the contents of bit positions 32 to 63 of the general register R ₂ +1. In the 64-bit addressing mode, the contents of bit positions 0 to 63 of the general register R ₂ +1 form a 64-bit unsigned binary integer specifying the number of bytes in the second operand; And the contents of the general register R ₂ +1 are replaced with the updated value.

In the 24-bit or 31-bit addressing mode, the contents of bit positions 0 to 31 of the general registers R ₂ and R ₂ +1 remain unchanged. In access register mode, access register _R2 specifies the address space for the second operand. In one example, the Edwards curve operands are sorted byte-by-byte in little-endian format, and the second operand is also sorted within the second operand address space.

The Compute Digital Signature Authentication command supports multiple authentication technologies, including, for example, Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards Curve Digital Signature Algorithm (EdDSA). In addition, Weierstrass Curve supports three National Institute of Standards and Technology (NIST) prime number fields: such as P256, P384, and P521 using the ECDSA algorithm. ECDSA reference curve parameter values, including, for example, prime modulus, order, coefficients, base point Publication, Digital Signature Standard (DSS), released July 2013).

In addition, two prime number fields using the EdDSA algorithm are supported, which are called for example Ed25519 and Ed448. Similarly, code that uses EdDSA also uses curve standards (e.g., Edwards Curve Digital Signature Algorithm (EdDSA), Internet Research Task Force (IRTF), RFC-8032, January 2017) Curve parameter values.

The following is the definition of the modulus of these fields: P256=2 ²⁵⁶ -2 ²²⁴ +2 ¹⁹² +2 ⁹⁶ -1 P384=2 ³⁸⁴ -2 ¹²⁸ -2 ⁹⁶ +2 ³² -1 P521=2 ⁵²¹ -1 Ed25519= 2 ²⁵⁵ -19 Ed448=2 ⁴⁴⁸ -2 ²²⁴ -1

Selected primes are suggested by various standards and provide better performance than other primes such as random primes.

Mark and verify code using the ECDSA algorithm on NIST prime numbers (e.g., 1, 2, 3, 9, 10, 11, 17, 18, and 19) ignoring the contents of general registers R ₂ and R ₂ +1 . In one example, these functions utilize a fixed-size hashed message contained in a parameter block.

In one example, the Edwards curve functions: KDSA-EdDSA-authenticate, KDSA-EdDSA-mark, and KDSA-encrypt-EdDSA-mark (e.g., function codes 32, 36, 40, 44, 48, and 52) use the EdDSA algorithm method, and the encrypted message is not pre-hashed. Operand 2 is the encrypted message and is addressed using general register R ₂ and its length is given by R ₂ +1. Curves Ed25519 and Ed448 support PureEdDSA variants. Other and/or different curves may be supported in other embodiments.

When executing the calculation digital signature authentication command, the function specified by the function code in general register 0 is executed. Each of the supported functions is described below:

KDSA-query (function code 0)

Query functions provide a mechanism for indicating the availability of other functions. For the query function, the contents of general registers R ₂ and R ₂ +1 are ignored.

An example of a parameter block used by a query function is described with reference to Figure 4A. As shown, in one example, parameter block 400 includes a 128-bit status word 401. Bits 0 to 127 of this field respectively correspond to function codes 0 to 127 of the digital signature authentication command. When the bit is For example, once, the corresponding function is installed; otherwise, the function is not installed.

As an example, condition code 0 is set when execution of the KDSA-query function completes; condition codes 1, 2, and 3 do not apply to this function.

；被稱為n的

之階數等。此等屬性中之一或多者用於執行函式，如下文所描述。 In addition to query functions, the Compute Digital Signature Authentication command supports various verification and marking functions. The verification function checks the validity of the signature of the message (e.g., the hashed message) and reports whether the certificate is valid via a condition code; and the marking function creates the signature for the message (e.g., the hashed message). The various validation and marking functions are described below. Each function is represented by a function code that provides an indication that the curve is being used. Curves have various properties associated with them, including but not limited to curve parameter values and/or other properties such as generating points

; called n

The order, etc. One or more of these properties are used to execute the function, as described below.

KDSA-ECDSA-verification function

In one embodiment, three KDSA-ECDSA-verification functions for Weierstrass curves with NIST primes are supported, and the corresponding function codes are provided below:

KDSA-ECDSA-verification-P256 (function code 1)

KDSA-ECDSA-verification-P384 (function code 2)

KDSA-ECDSA-verification-P521 (function code 3)

The locations and addresses of the operands used by each of these functions are shown in Figures 3D-3F. The parameter block for each function described below contains the operands used by the KDSA-ECDSA-verify function and is addressed by general purpose register 1.

KDSA-ECDSA-verify command checks the validity of the tagged message. The sender of the message has a public key that can be used to see if the signature matches the message (e.g., the hashed message). The signature includes, for example, two integers in the prime number fields designated by R and S. The sender and receiver agree on the hash scheme used to create the signature. KDSA-ECDSA-verify command pair parameters The operation is performed on the message represented by H(M) in the block, such as the message that has been hashed (eg, pre-hashed to a fixed length). The sender's public key is represented by K. An elliptic curve public key is a point on the curve and has X and Y coordinates (represented by Xk and Yk) in the prime fields, making it twice as large as the other parameters. These operands are supplied to the instruction in the parameter block. This operation produces a true or false validity indication in the condition code.

As an example, condition code 0 is set if the signature is valid, condition code 2 is set if the signature is invalid, and condition code 1 is set when the public key is invalid and on the curve because, for example, it is not greater than zero and less than a prime number . Other examples are possible.

An example of the verification process using the elliptic curve digital signature algorithm is described with reference to FIG. 5 . In this process, an overline ^— indicates a point with x and y coordinates compared to an integer, * indicates modular multiplication, + is modular addition, × is a scalar multiplication of a point, and == is used for integer comparison equality. Bollinger type test.

為生成值，亦即稱為基點或生成點的橢圓曲線上之區分性點；且n為

之階數，步驟500。在一個實例中，

及n為由例如執行指令之硬體可存取之記憶體中儲存的函式碼指示的根據曲線(基於標準)之固定常數。作為實例，n大於2¹⁶⁰。點

之階數例如為最小正整數n，使得nx

專於無窮大的點。檢查簽章R及S是否例如不<1且不>n-1，查詢502。若此檢查失敗，則處理結束，步驟504。否則，將c設定成等於S mod n之模逆=S^-1，步驟506。此外，將u1設定成等於(H(msg)* c)mod n，步驟508，且將u2設定成等於(R * c)mod n，步驟510。將(

,

)設定成等於(u1 x

)+(u2 x

)，步驟512。另外，將v設定成等於x1 mod n，步驟514。此亦可寫為

，其中p為奇質數。在v與簽章(R)之間執行用於整數比較相等之布林型測試，且例如在 條件碼中傳回布林型正確或錯誤，步驟516。 Initially, in an instance,

is the generated value, that is, the distinguishing point on the elliptic curve called the base point or generating point; and n is

The order, step 500. In one instance,

and n is a fixed constant according to the curve (based on the standard) indicated by, for example, function code stored in memory accessible to the hardware executing the instruction. As an example, n is greater than 2 ¹⁶⁰ . point

For example, the order of is the smallest positive integer n, such that nx

Specialize in infinite points. Check whether the signatures R and S are not <1 and not>n-1, for example, query 502. If this check fails, the process ends, step 504. Otherwise, set c equal to the modular inverse of S mod n = S ⁻¹ , step 506 . Additionally, u1 is set equal to (H(msg)*c)mod n, step 508, and u2 is set equal to (R*c)mod n, step 510. will(

,

) is set equal to (u1 x

)+(u2 x

), step 512. Additionally, v is set equal to x1 mod n, step 514. This can also be written as

, where p is an odd prime number. A Boolean test for integer comparison equality is performed between v and the signature (R), and Boolean true or false is returned, eg, in the condition code, step 516.

。 In one example, K has x and y coordinates and is a point, which is equal to the secret key d times the generated value point

.

As indicated, the operands for the verification function are provided via parameter blocks, examples of which are described below. After describing the parameter blocks used for various functions, additional details about the fields of the parameter block are described.

An example of a parameter block for the KDSA-ECDSA-verify-P256 function is described with reference to Figure 4B. In one example, parameter block 402 includes, for example, the following fields: signature (R) 403, signature (S) 404, hashed message H (msg) 405, public cryptographic key (K) 406 (e.g., public The cryptographic key X component (Xk) and Y component (Yk)), and the reserved storage area 407. In one example, each field is represented as 32 bytes, or 256 bits wide, and the instance displacement within the parameter block is depicted in Figure 4B. In one example, the displacement of Xk is Dec 96/Hex 60 and the displacement of Yk is Dec 128/Hex 80.

Additionally, an example of a parameter block for the KDSA-ECDSA-verify-P384 function is depicted in Figure 4C. In this example, each field is 48 bytes, or 384 bits wide. As shown, parameter block 408 includes fields such as: signature (R) 409, signature (S) 410, hashed message 411, public cryptographic key (K) 412 (e.g., Xk and Yk), and Reserved save area 413. Example displacements within the parameter block are depicted in Figure 4C. In one example, the displacement of Xk is Dec 144/Hex 90 and the displacement of Yk is Dec 192/Hex C0.

In addition, as shown in Figure 4D, the parameter block 414 for the KDSA-ECDSA-verify-P521 function includes, for example, the following fields: signature (R) 415, signature (S) 416, hashed message 417, Public cryptographic keys 418 (eg, Xk, Yk), and reserved storage area 419. Each field is, for example, 80 bytes or 640 bits wide. In one instance, the NIST standard Defines the data to be passed as 8-bit wide octets. Therefore, the 521-bit operand is padded with 7 zeros on the leftmost significant bit to form a 528-bit or 66-bit group (octet). If updated, each parameter includes the rightmost 66 bytes of the 80-byte field. The instance displacements within the parameter block are depicted in Figure 4D. As an example, the displacement of Xk is Dec 240/Hex F0 and the displacement of Yk is Dec 320/Hex 140.

KDSA-ECDSA-mark function

In one embodiment, three KDSA-ECDSA-marking functions and three KDSA-encryption-ECDSA-marking functions are supported, and the corresponding function codes are provided below:

KDSA-ECDSA-mark-P256 (function code 9)

KDSA-ECDSA-mark-P384 (function code 10)

KDSA-ECDSA-mark-P521 (function code 11)

KDSA-encryption-ECDSA-mark-P256 (function code 17)

KDSA-encryption-ECDSA-mark-P384 (function code 18)

KDSA-encryption-ECDSA-mark-P521 (function code 19)

The KDSA-ECDSA-tagged function uses the cryptographic key (K) that is the plaintext key for the author's private key. This key is to be protected by software. The KDSA-encryption-ECDSA-mark function uses an encryption key to save the author's private key, and has a corresponding wrapper key verification pattern (Wk _a VP) to test the key.

The ECDSA algorithm uses random numbers to randomize signatures. The KDSA-ECDSA-tagged function for NIST prime numbers with plain text keys (e.g., P256, P384, and P521) utilizes a user-specified random number RN in the parameter block. Allowing the user to specify a random number makes this command deterministic and faster. The KDSA-Crypto-ECDSA-Tag command for NIST primes with encryption keys uses a specified random number to generate a pair of keys to the user within the command execution. A hidden secret random number that adds security to the signature process and will change under the same input. In another embodiment, the KDSA-Crypto-ECDSA-Tag command for NIST primes with encryption keys allows the user to specify a random number and further randomize this number by part of a time-of-day (TOD) clock , thus allowing the simulation model to be deterministic but the actual hard system to be stochastic. In one embodiment, the EdDSA technique does not use random numbers.

The result of a marker function is a signature represented by two integers, R and S, stored in specified locations in the parameter block, between a value such as zero and the degree of the curve of the particular function. .

As an example, condition code 1 is set if the verification pattern mismatches, the hashed message is zero, or the private key is zero or greater than or equal to the degree of the curve or not on the curve. If the random number is irreversible for ECDSA-marks, but not for encryption-ECDSA-marks, then condition code 2 is set. For encrypted-ECDSA-marks, the generated hidden random numbers are reversible. If the signature is generated successfully, condition code 0 is set.

An example of marking processing using the elliptic curve digital signature algorithm is described with reference to FIG. 6 . In this process, the overline ^— indicates a point with x and y coordinates.

In one example, the variable z is initially set equal to a selected number (Ln) of the leftmost bit of the hashed message (H(msg)), where Ln is the order n of the base point of the curve used to label the function length, step 600. Additionally, a query 602 is performed to determine whether the selected random number (RN) is between a first value (eg, 0) and a second value (eg, n). If the random number is not between the two values, the condition code is set to the selected value (for example, CC=2), step 604. However, if the random number is between the two values, then RN ^-1 is set equal to the modular inverse of RN mod n, step 606.

,

)設定成等於RN及

之純量乘法，其中

為生成點，步驟608。此外，將R設定成等於x1 mod n，其中n為

之階 數，×為點之純量乘法，且+為模加，步驟610。判定R是否設定成等於諸如零之選定值，查詢612。若R設定成等於零，則將條件碼設定成選定值(例如，CC=2)，步驟614。然而，若R並未設定成等於零，則將變數S設定成等於RN^-1 *(z+K * R)mod n，步驟616，其中K為金鑰。 In addition, change the coordinates (

,

) is set equal to RN and

scalar multiplication of , where

To generate points, step 608. Additionally, set R equal to x1 mod n, where n is

The order of , × is the scalar multiplication of points, and + is the modular addition, step 610. To determine whether R is set equal to a selected value such as zero, query 612. If R is set equal to zero, then the condition code is set to the selected value (eg, CC=2), step 614. However, if R is not set equal to zero, then the variable S is set equal to RN ^-1 * (z + K * R) mod n, step 616, where K is the key.

To determine whether S is equal to a selected value such as zero, query 618. If S equals zero, then the condition code is set to the selected value (eg, CC=2), step 620. Otherwise, return the signature, step 622. The signature includes two integers R and S.

As indicated, the operands for the tagged function are provided via parameter blocks, examples of which are described below.

An example of a parameter block for the KDSA-ECDSA-Tag P256 function with a plain text key is described with reference to Figure 4E. In one example, the parameter block 420 includes, for example, the following fields: signature (R) 421, signature (S) 422, hashed message 423, private cryptographic key in plain text 424, random number 425, and Save area 426 is reserved. The instance displacements within the parameter block are depicted in Figure 4E.

Additionally, referring to Figure 4F, the parameter block 427 for the KDSA-ECDSA-Tag P384 function with a plain text key includes, for example, the following fields: signature (R) 428, signature (S) 429, hashed message 430. The private password key (K) 431 in plain text, the random number 432 and the reserved storage area 433. The instance displacements within the parameter block are depicted in Figure 4F.

Additionally, referring to Figure 4G, the parameter block 434 for the KDSA-ECDSA-Tag P521 function with a plain text key includes, for example, the following fields: signature (R) 435, signature (S) 436, hashed message 437. Private password key 438 in plain text, random number 439, and reserved storage area 440. In one example, in addition to the hashed message, the parameters are 528 bits (66 bytes) and are right-justified in an 80-byte field. A 521-bit source parameter is represented by 7 zeros Pad to the left of the most significant bit, as specified by the NIST standard. The signature's destination field, for example in the parameter field, is 66 bytes wide, right-aligned, and the remaining 14 bytes remain unchanged. The hashed message is, for example, 80 bytes wide. The instance displacements within the parameter block are depicted in Figure 4G.

Continuing with the parameter block, referring to Figure 4H, the parameter block 441 for the KDSA-Encryption-ECDSA-Mark P256 function using the encryption key includes, for example, the following fields: signature (R) 442, signature (S) 443 , hashed message 444, encrypted private cryptographic key (WK _a (K)) 445, random number 446, AES wrapper key verification pattern (WK _a VP) 447, and reserved storage area 448. Example displacements within parameter blocks are depicted in Figure 4H.

In addition, referring to Figure 4I, the parameter block 449 for the KDSA-Encrypt-ECDSA-Mark-P384 function includes, for example, the following fields: signature (R) 450, signature (S) 451, hashed message 452, encryption Private cryptographic key (WK _a (K)) 453, random number 454, AES wrapped key verification pattern (WK _a VP) 455, and reserved storage area 456. The instance displacements within the parameter block are depicted in Figure 4I.

In addition, referring to Figure 4J, the parameter block 457 for the KDSA-Encrypt-ECDSA-Mark-P521 function includes, for example, the following fields: signature (R) 458, signature (S) 459, hashed message 460, encryption Private cryptographic key (WK _a (K)) 461, random number 462, AES wrapped key verification pattern (WK _a VP) 463, and reserved storage area 464. In one example, the P521 format has 521 bits, with an additional most significant 7 bits of zero for right-aligned R, S, and 66-byte operands within the 80-byte field. The remaining 14 bytes of the R and S fields remain unchanged. The hashed message is, for example, an 80-byte field, and H(msg) and the operand are right-aligned within the 80-byte field. The instance displacements within the parameter block are depicted in Figure 4J.

KDSA-EdDSA-verification function

In one embodiment, support for Edwards curves with special prime numbers is Two KDSA-EdDSA-verification functions, and the corresponding function codes are provided below:

˙KDSA-EdDSA-verification-Ed25519 (function code 32)

˙KDSA-EdDSA-verification-Ed448 (function code 36)

The locations and addresses of the operands used by each of these functions are shown in Figures 3D-3F. The parameter block for each function described below contains the operands used by the KDSA-EdDSA-verification function and is addressed by general purpose register 1.

In one embodiment, EdDSA is defined as having an integer encoded in little endian form as opposed to most cryptographic techniques. Ed25519 in the form of little-endian octets (bytes) encodes the 32-byte string h as h[0]...h[31], where h[31] is the most significant. If A is the address of h[0], then A+31 is the address of the most significant byte h[31]. For the 255-bit format, the most significant bit of the most significant byte is not required. For a compressed point, the y-coordinate is placed in the 255 least significant bits, and the least significant bit of the x-coordinate is placed in the remaining most significant bit (h[31], bit 7). Ed448 in little-endian octet form encodes the compressed point with the 56-byte y-coordinate in the least significant 56 bytes of the 57-byte byte, and the least significant bit of the x-coordinate is placed in bit 57 The most significant bit of the group's most significant byte (h[56], bit 7), and the remaining bits of the byte are filled with zeros.

KDSA-EdDSA-verify command checks the validity of a tagged message. The sender of the message has a public key that can be used to see if the signature matches the message (e.g., the hashed message). The signature consists of two values in the prime fields specified by R and S. In one example, R is a compressed point, which in one example is treated as an integer (although possibly larger than a prime number) and S is an integer. The sender and receiver agree on the hash scheme used to create the signature. The KDSA-EdDSA-verify command operates on the complete message addressed by operand 2. The sender's public key is represented by K in the parameter block and is in compressed format with the least significant x coordinate The bits are concatenated to all bits of the y coordinate. Therefore, the public key is slightly wider than the prime number of the curve that occupies 57 bytes of the Ed448 curve. This operation produces a true or false validity indication in the condition code.

As an example, if the signature is valid, condition code 0 is set, and if the signature is invalid, condition code 2 is set. Furthermore, condition code 1 is set when the public key is invalid and on the curve because, for example, it is not greater than zero and less than a prime number.

而非

用作基點。此外，在此處理中，上劃線^—指示具有x及y座標之點，+為模加且×為點之純量乘法。K為經壓縮公開金鑰，且對於Ed25519佔用例如32位元組並對於Ed448佔用57位元組。 An example of the verification process using the Edwards Curve digital signature algorithm is described with reference to FIG. 7 . In one example, Ed25519 uses SHA-512 and Ed448 uses SHAKE256 for hash H(x). Such curves will

rather than

Used as base point. Furthermore, in this process, the overline ^- indicates a point with x and y coordinates, + is modular addition and × is scalar multiplication of the point. K is a compressed public key and occupies, for example, 32 bytes for Ed25519 and 57 bytes for Ed448.

設定成等於點解壓縮(K)，其中K為經壓縮公開金鑰點=(x(lsb)∥y)，其中lsb為最低有效位元且∥為級聯，步驟700。此外，計算

，其中

，其中R=(x(lsb)∥y)，步驟702。此外，計算h，其中h=H(R∥K∥msg)，步驟704。點解壓縮逆向於點壓縮，此允許使用因此自x_p及y_p導出之y_p及單個額外位元x_p緊湊地表示點

。 Referring to Figure 7, in one example, the public key

Set equal to point decompression (K), where K is the compressed public key point = (x(lsb)∥y), where lsb is the least significant bit and ∥ is the concatenation, step 700. In addition, calculate

,in

, where R=(x(lsb)∥y), step 702. In addition, h is calculated, where h=H(R∥K∥msg), step 704. Point decompression is the inverse of point compression, allowing points to be represented compactly using y _p thus derived from x _p and y _p and a single extra bit x _p

.

設定成等於S×

(點之純量相乘)，步驟706，且將

設定成等於h×

(點之純量相乘)，步驟708。執行用於整數比較相等之布林型測試(

)，且例如在條件碼中傳回正確或錯誤指示，步驟710。 In addition, it will

Set equal to S×

(scalar multiplication of points), step 706, and

Set equal to h×

(Scalar multiplication of points), step 708. Performs a Boolean test for integer comparison equality (

), and returns a correct or error indication, such as in a condition code, step 710.

Refer to Figure 4K to describe the parameters used in the KDSA-EdDSA-verify-Ed25519 function. An example of a number block. In one example, parameter block 468 includes fields such as: signature (R) 469, signature (S) 470, public cryptographic key (K) 471, and reserved storage area 472. In one example, each field is represented as 32 bytes, or 256 bits wide, and the instance displacement within the parameter block is depicted in Figure 4K.

In addition, referring to Figure 4L, the parameter block 473 for the KDSA-EdDSA-verify-Ed448 function includes, for example, the following fields: signature (R) 474, signature (S) 475, public cryptographic key (K) 476 , and reserved save area 477. In one example, each field is 64 bytes, or 512 bits wide. The S parameter is represented by the rightmost 448 bits of the 512-bit field, and the R and K fields, which are compression points, are represented by the rightmost 456 bits of the 512-bit field. Example displacements within the parameter block are depicted in Figure 4L.

KDSA-EdDSA-marker function

In one embodiment, two KDSA-EdDSA-marking functions and two KDSA-Encryption-EdDSA-marking functions are supported, and the corresponding function codes are provided below:

˙KDSA-EdDSA-mark-Ed25519 (function code 40)

˙KDSA-EdDSA-mark-Ed448 (function code 44)

˙KDSA-Encryption-EdDSA-Mark-Ed25519 (function code 48)

˙KDSA-Encryption-EdDSA-Mark-Ed448 (function code 52)

The KDSA-EdDSA-tagged function uses a cryptographic key (K) that is the plaintext key for the author's private key. This key is to be protected by software. The KDSA-Encryption-EdDSA-Tag function uses an encryption key to store the author's private key, and has a corresponding Wrapping Key Verification Pattern (WK _a VP) to test the key.

In one embodiment, the EdDSA technique does not use random numbers, and therefore, no numbers are specified for the KDSA-EdDSA-Tag function.

KDSA-EdDSA-The result of a signature function is a signature stored in the specified location in the parameter block, represented by a compressed point R and an integer S between a value such as zero and the value of the curve of the particular function. between levels.

In one example, if the signature is generated successfully, condition code 0 is set. In addition, condition code 1 is set if the verification pattern does not match, the message is zero, or the private key is, for example, zero or greater than or equal to the degree of the curve or not on the curve.

An example of marking processing using the Edwards Curve digital signature algorithm is described with reference to FIG. 8 . In this process, the overline ^- indicates a point with x and y coordinates, * indicates modular multiplication, × is a scalar multiplication of points; + is modular addition, and ψ is a cascade. As an example, Ed25519 uses SHA-512 and Ed448 uses SHAKE256 for hashing H(x).

設定成等於(s1×

)，其為公開金鑰，步驟806。將Ac設定成等於點壓縮(Ax,Ay)，其等於Ax(lsb)∥Ay，步驟808。此外，將r設定成等於H(首碼∥msg)，步驟810。將

設定成等於r×

(等於RFC8032中之R)，步驟812。將Rc設定成等於點壓縮(Rx,Ry)=Rx(lsb)∥Ry，步驟814。將k設定成等於H(Rc∥Ac∥msg)，步驟818，且將S設定成等於(r+k * s1)mod n，步驟818。傳回Rc及S，步驟820。 Referring to Figure 8, in one embodiment, h1 is set equal to H(K), which is the hash of the private key, step 800. Set s1 equal to h1 (0:31B), which is bytes 0 to 31, step 802, and set the header equal to h1 (32:63B), step 804. will

Set equal to (s1×

), which is the public key, step 806. Set Ac equal to point compression (Ax,Ay), which is equal to Ax(lsb)∥Ay, step 808. Additionally, r is set equal to H (first code ∥msg), step 810. will

Set equal to r×

(Equal to R in RFC8032), step 812. Set Rc equal to point compression (Rx, Ry) = Rx (lsb) ∥ Ry, step 814. Set k equal to H(Rc∥Ac∥msg), step 818, and set S equal to (r+k*s1)mod n, step 818. Return Rc and S, step 820.

An example of the parameter block for the KDSA-EdDSA-mark-Ed25519 function is described with reference to Figure 4M. In one example, parameter block 478 includes fields such as: signature (R) 479, signature (S) 480, private cryptographic key (K) 481 in plain text, and reserved storage area 482. The R, S, and K parameters are 32-bit fields. In one instance, the S parameters have The most significant bit of the field that is forced to zero. The random number is not specified because the EdDSA algorithm does not require random numbers. The instance displacements within the parameter block are depicted in Figure 4M.

Referring to Figure 4N, the parameter block 483 for the KDSA-EdDSA-mark-Ed448 function includes, for example, the following fields: signature (R) 484, signature (S) 485, private cryptographic key in plain text ( K) 486, and reserved storage area 487. In one example, the S parameter is 448 bytes or 56 bytes and is right aligned with the 64 bytes field. The R and K parameters are 456 bits or 57 bytes and right aligned. The Ed448 format also uses EdDSA technology that does not utilize random numbers. The instance displacements within the parameter block are depicted in Figure 4N.

In addition, referring to Figure 4O, the parameter block 488 for the KDSA-Encrypt-EdDSA-Mark-Ed25519 function includes, for example: signature (R) 489, signature (S) 490, encryption private cryptographic key (WK _a (K)) 491, AES wrapped key verification pattern (WK _a VP) 492, and reserved storage area 493. In one example, the Ed25519 format uses 255 rightmost bits for S (with zeros for the most significant bit), and 256 bits are used for the encryption key, R, and wrapping key verification pattern. Example displacements within parameter blocks are depicted in Figure 4O.

Referring to Figure 4P, the parameter block 494 of the KDSA-Encryption-EdDSA-Mark-Ed448 function includes, for example: signature (R) 495, signature (S) 496, encryption private cryptographic key (WK _a (K)) 497. AES wrapper key verification pattern (WK _a VP) 498, and reserved storage area 499. In one example, the S parameter is 448 bytes, or 56 bytes, and the R parameter is 57 bytes and right-justified within a 64-byte field. The instance displacements within the parameter block are depicted in Figure 4P.

Additional details of the fields used in the parameter blocks of the KDSA-authenticate and KDSA-mark functions are described below. In one instance:

Signature (R): the first integer of the signature. In one example, R is greater than zero and less than the degree of the curve. For the EdDSA function, R is slightly wider than the prime numbers because it represents the meridional pressure Contraction point, where the least significant bit of X is concatenated with Y.

Signature (S): the second integer of the signature. In one example, S is greater than zero and less than the degree of the curve.

Hashed Message-H(msg): Marking and verification operations utilize a hashed version of the author message used for the ECDSA curve. This is performed before the KDSA command to allow greater flexibility in supported encryption. The hashed message is, for example, an integer greater than or equal to zero and less than a prime number of the curve. This parameter is not available on the EdDSA curve since it does not pre-hashe the message and instead operand 2 addresses the encrypted message.

CryptoKey (K): The cryptographic key used for marking and verifying operations begins at various bytes in the parameter block. The size of the key field and its displacement in the parameter block depend on the function code, as shown in Figure 9. The * in Figure 9 indicates that zeros are added to the key length to provide the length in bytes.

In one example, Ed25519 uses the 255 rightmost bits of a 256-bit 32-byte field. The KDSA-marker used for P521 and Ed448 uses different key format widths for encrypted keys and plain text keys. Encryption keys are encoded and use 128-bit boundaries. The P521 plain text key used for marking and verification is 521 bits (65 bytes and 1 bit), aligned in the rightmost bit of the 66-byte field.

Reserved Save Area: A reserved save area is a predefined amount of memory that is used to save pending state information (such as whether the command ended with a partial completion), allowing the command to be restarted on partial completion.

AES Wrapped Key Verification Pattern (WK _a VP): For KDSA-Encryption-Tagged functions (e.g., function codes 17 to 19, 48, and 52), the 32 bytes immediately following the key in the parameter block contain AES Wrapped Key Verification Pattern (WK _a VP).

For KDSA-verification functions and plain text key KDSA-mark functions, the WK _a VP field does not exist in the parameter block.

Wrapper key verification: For KDSA-tagged functions with encryption keys (e.g., function codes 17 to 19, 48, and 52), compare the contents of the 32-byte WK _a VP field to the AES wrapper key The contents of a verification pattern register (for example, a register containing a 256-bit AES wrapped key verification pattern). If they do not match, the parameter block position remains unchanged and the operation is completed by setting condition code 1. If they match, the contents of the key field of the parameter block are decrypted using the AES wrapper key to obtain the cryptographic key K used for the token processing described herein. In one example, the encrypted ECC key is protected with AES-256 encryption.

For KDSA functions that do not use encryption keys, wrapper key verification is not performed.

Random Number (RN): The KDSA-ECDSA-tagged function using NIST prime numbers (e.g., P256, P384, and P521) has input random numbers. The random number will be greater than zero for example. The more significant bits are, for example, forced to zero, and if not lower than the order of the curve of the function, the order of the curve is subtracted from the random number. In one example, the random number will be reversible by the order of the curve; otherwise, the parameter block position remains unchanged and the operation is completed by setting condition code 2.

In one example, for the KDSA-Encryption-ECDSA-Tag function, the nonce is greater than zero and the parameter block position remains unchanged, and the operation is completed by setting condition code 2. For the KDSA-Encryption-ECDSA-Tag function, the random number does not have to be reversible since it is not directly used to create a reversible hidden random number, but is instead used to create a seed.

A PER save-change event is recognized when it applies to a portion of a stored parameter block, including reserved fields of the parameter block. A PER zero address detection event is recognized when it applies to the second operand position and parameter block. When targeting one of these positions Or when a PER event is detected, it is unpredictable which location will be identified in the PER Access Identification (PAID) and the PER ASCE ID (Al).

Access exceptions and PER zero address detection for functions that perform a comparison of an encryption cryptographic key and a wrapper key verification pattern register when the comparison results in a mismatch and the length of the respective operand is non-zero Whether an event is recognized for use in the second operand is unpredictable.

Access exceptions may be reported for a larger portion of an operand than the portion of an operand that is processed in a single execution of the instruction; however, in one embodiment, access exceptions are not recognized for use beyond the operation Unit-length positions are also not used for positions larger than 4K bytes beyond the current position being processed.

Example conditions for KDSA include, for example:

If any of the following occurs, a specification exception is recognized and no further action is taken:

1. Bits 57 to 63 of general register 0 specify unassigned or uninstalled function codes.

2. The R ₂ field specifies the odd numbered register or general register 0.

Example of the resulting condition code:

0 Verification: The signature is verified for use in the function; Flag: Normal completion.

1 Verification: The public key is not on the curve; Mark: The key verification pattern does not match.

2 Verification: The signature is incorrect; Mark: The random number is irreversible (0<RN<the order of the curve).

3 parts completed

Example program exceptions:

˙Access (extract, parameter block field, operand 2 (EdDSA function only); store, parameter block field)

˙Operation (when Message Security Assistant Extension 9 is not installed)

˙Standard

˙Change constraints

Instance priorities for KDSA execution include, for example:

1.-6. Exception conditions whose priority is the same as the priority of program interruption conditions in general conditions.

7.A The access exception of the second instruction half word.

7.B Operational Exceptions.

7.C Change constraints.

8. Standard exception due to invalid function code or invalid register number.

9. Specification exception due to invalid operand length.

10.A.1 Access exceptions for accessing parameter blocks.

10.A.2. Condition code 1 or 2 due to verification pattern mismatch or non-reversible random number or public key not on the curve.

10.B Access exceptions for accessing the second operand.

11. Due to condition code 3 of partial processing.

12. Condition code 0 due to normal completion or condition code 2 due to incorrect signature.

Programmed notes:

1. In one embodiment, if the program is to frequently test the availability of functions, Then it should execute the query function once during initialization; subsequently, it should check the stored results of the query function in memory through instructions such as testing under a mask.

2. Inconsistent results can simply be stored in the first operand location as observed by this CPU, other CPUs, and the I/O subsystem.

3. When condition code 3 is set, the general register containing the operand address and length and the parameter block are usually updated so that the program can only branch back to the instruction to continue operation.

As described herein, in one aspect, a single instruction (e.g., a single architected machine instruction at a hardware/software interface, such as a compute digital signature authentication instruction) is provided to perform signature generation using, for example, a general-purpose processor and/or verification function. This instruction is, for example, a hardware instruction defined in the Instruction Set Architecture (ISA). As a result, the complexity of programs associated with marking and/or validating functions is reduced. In addition, functions and therefore processor performance are improved. Compared to a software implementation, executing a single instruction requires significantly fewer execution loops to perform the same operation. Additionally, in one embodiment, by using a single architected instruction, intermediate results are encrypted, providing additional security if the instruction is partially completed.

As an example, the Compute Digital Signature Authentication command is used to create a signature that is used to mark a message and to authenticate the message and/or the sender of the message upon receipt. For example, the user (the sender or someone on behalf of the sender) executes a calculation digital signature authentication command to obtain the signatures R, S. The sender sends the message to the receiver along with signatures R and S. The recipient receives the message and signature and performs verification using, for example, a Compute Digital Signature Authentication command. If the signature and/or sender are verified (for example, the command result indicates correct), the message is read; otherwise, the message is rejected.

Although various fields and registers are described for computing digital signature authentication instructions, one or more aspects of the invention may use other, additional or fewer fields or registers, or a combination of fields and registers. Other sizes etc. Many variations are possible. For example, you can use implicit registers instead of an explicit register or field specified by the instruction, and/or an explicitly specified register or field may be used instead of an implicit register or field. Other variations are also possible.

One or more aspects of the invention are inevitably related to computer technology and facilitate processing within computers, thereby improving their performance. The use of a single structured machine instruction that performs signature generation and/or verification improves performance within a computing environment. Signed/verified messages can be used in many technical fields, such as computer processing, medical processing, security fields, etc. Improves these technical areas by reducing execution time by providing markup/validation optimization.

Additional details of one embodiment for facilitating processing within a computing environment as it relates to one or more aspects of the invention are described with reference to FIGS. 10A-10B.

Referring to Figure 10A, instructions are obtained (1000) to generate a signature for a message. This instruction is a single architected instruction (1002). The instruction is executed (1004), and the execution includes determining one of a plurality of tagged functions supported by the instruction to be executed (1006). Input for the command is obtained and includes the message and password key (1008). A signature is generated based on the mark function to be executed and the input (1010). The signature is to be used to verify the message (1012).

In one example, the message is a hashed message (1014).

Additionally, in one example, the signature is represented by a plurality of values (1016). The plurality of values includes, for example, a first integer and a second integer (1018) between zero and the degree of the curve for the labeled function to be performed. As a specific example, the marking function is an Edwards Curve digital signature algorithm marking function, and the plurality of values includes compressed points and integers (1019).

In another example, the input further includes random numbers (1020).

Additionally, in one embodiment, referring to FIG. 10B , the execution includes testing that the random number is between the first value and the second value (1022); and executing based on the random number being between the first value and the second value. Signature generation (1024). As an example, the first value is zero and the second value represents the The degree (1026) of the base point of the curve on which the marking function is executed.

In one example, the plurality of marking functions includes a plurality of elliptic curve digital signature algorithm marking functions for a plurality of prime numbers (1028). Complex prime numbers include, for example, the National Institute of Standards and Technology (NIST) prime number P256, the NIST prime number P384, and the NIST prime number P521 (1030). In another example, the plurality of marking functions includes a plurality of Edwards Curve Digital Signature Algorithm marking functions for a plurality of prime numbers (1032). The complex prime numbers include the Edwards curve prime number Ed25519 and the Edwards curve prime number Ed448 (1034).

Other variations and embodiments are possible.

Aspects of the invention may be used by many types of computing environments. Another embodiment of a computing environment incorporating and using one or more aspects of the present invention is described with reference to FIG. 11A. In this example, computing environment 10 includes, for example, a native central processing unit (CPU) 12 , memory 14 , and one or more input/output devices and/or interfaces 16 , each via, for example, one or more buses 18 and /or other connections to couple each other. By way of example, computing environment 10 may include: a ^PowerPC® processor provided by International Business Machines Corporation of Armonk, New York; a PowerPC® processor provided by Hewlett Packard Co. of Palo Alto, California; HP Superdome with Intel Itanium II processors; and/or other machines based on architecture provided by International Business Machines Corporation, Hewlett-Packard Company, Intel Corporation, Oracle Corporation, or others. IBM, z/Architecture, IBM Z, z/OS, PR/SM and PowerPC are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

Native central processing unit 12 includes one or more native registers 20, such as one or more general purpose registers and/or one or more special purpose registers used during processing within the environment. These registers include information that represents the state of the environment at any particular point in time.

In addition, the native CPU 12 executes instructions and program codes stored in the memory 14 . In one particular example, the central processing unit executes emulator code 22 stored in memory 14 . This code enables a computing environment configured in one architecture to emulate another architecture. For example, the emulator code 22 allows machines based on architectures other than the z/Architecture hardware architecture (such as PowerPC processors, HP Superdome servers, or others) to emulate the z/Architecture hardware architecture and execute the z/Architecture-based hardware architecture. /Architecture software and instructions for hardware architecture development.

Additional details related to emulator code 22 are described with reference to Figure 11B. Object instructions 30 stored in memory 14 include software instructions (eg, related to machine instructions) developed for execution in an architecture other than the architecture of native CPU 12 . For example, object instructions 30 may have been designed to execute on a processor based on the z/Architecture hardware architecture, but instead are emulated on a native CPU 12 which may be, for example, an Intel Itanium II processor. In one example, emulator code 22 includes instruction fetch routines 32 to obtain one or more object instructions 30 from memory 14 and optionally provide local buffering of the obtained instructions. The emulator code also includes instruction translation routines 34 to determine the type of object instruction obtained and to translate the object instruction into one or more corresponding native instructions 36 . This translation includes, for example, identifying the function to be executed by the object instruction and selecting the native instruction to execute the function.

Additionally, emulator code 22 includes emulation control routines 40 to enable execution of native instructions. The emulation control routine 40 causes the native CPU 12 to execute a routine that emulates one or more previously obtained object instructions and upon completion of such execution, transfer control back to the instruction fetch routine to emulate the next object instruction. or the acquisition of a set of object instructions. Execution of native instructions 36 may include loading data from memory 14 into a register; storing data from the register back into memory; or performing a certain type of arithmetic or logical operation, as determined by a translation routine. .

Each routine is implemented in software, for example, which is stored in memory and executed by the native central processing unit 12 . In other examples, one or more routines or operations are implemented in firmware, hardware, software, or some combination thereof. The registers 20 of the native CPU may be used or by using locations in memory 14 to emulate the registers of the simulated processor. In embodiments, the object instructions 30, the native instructions 36, and the emulator code 22 may reside in the same memory or may be distributed among different memory devices.

The computing environments described above are only examples of computing environments that may be used. Other environments may be used, including but not limited to other unsegmented environments, other segmented environments, and/or other simulated environments; embodiments are not limited to any one environment.

Each computing environment can be configured to include one or more aspects of the invention. For example, each computing environment may be configured to provide tagging/authentication in accordance with one or more aspects of this disclosure.

One or more aspects may involve cloud computing.

It should be understood that, although this disclosure includes a detailed description with respect to cloud computing, implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or later developed.

Cloud computing is a method used to facilitate a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) A service delivery model for on-demand network access where configurable computing resources can be quickly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

The characteristics are as follows:

On-demand self-service: Cloud consumers automatically provision computing one-way as needed capabilities (such as server time and network storage) without human interaction with the service provider.

Broadband network access: Capabilities are available over the network and are accessed through standard mechanisms facilitated by heterogeneous thin or complex client platforms (e.g., mobile phones, laptops, and PDAs).

Resource Aggregation: The provider's computing resources are aggregated to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned based on demand. The sense of location independence exists because consumers typically do not have control or knowledge of the exact location of a provided resource, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

Rapid elasticity: Capacity can be quickly and elastically deployed (in some cases, automatically) to expand outward quickly, and capacity can be released quickly to expand inward quickly. From the consumer's perspective, the capacity available for deployment often appears to be unlimited and can be purchased at any time and in any amount.

Measured services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services utilized.

The service model is as follows:

Software as a Service (SaaS): The capability provided to consumers using the provider's applications running on cloud infrastructure. Applications may be accessed from a variety of client devices through a streamlined client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the network, servers, operating systems, storage or even individual The underlying cloud infrastructure for application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS): The ability provided to consumers to deploy consumer-created or acquired applications on cloud infrastructure using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does have application control over deployed applications and possible hosting environment configurations.

Infrastructure as a Service (IaaS): The ability provided to consumers to deploy processing, storage, networking and other basic computing resources, where consumers can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, deployed applications, and may have limited control over select network connectivity components (e.g., host firewall).

The deployment model is as follows:

Private Cloud: Operates cloud infrastructure only for the organization. Private clouds can be managed by the organization or a third party and can exist on-premises or off-premises.

Clustered cloud: Cloud infrastructure is shared by several organizations and supports specific clusters that share issues such as tasks, security requirements, policies, and compliance considerations. Cluster clouds can be managed by an organization or a third party and can exist on-premises or off-premises.

Public cloud: This cloud infrastructure is available to the public or large industrial groups and is owned by an organization that sells cloud services.

Hybrid Cloud: A cloud infrastructure that is a combination of two or more clouds (private, clustered, or public) that remain distinct entities but provide the same functionality by enabling data and application portability (e.g., for use in the cloud) Standardization or dedicated implementation of load balancing between cloud bursts Bound together by technology.

Service orientation for cloud computing environments by focusing on borderless, low-coupling, modularization, and semantic interoperability. The key to cloud computing is the infrastructure including the network of interconnected nodes.

Referring now to Figure 12, an illustrative cloud computing environment 50 is depicted. As shown, cloud computing environment 50 includes one or more cloud computing nodes 52, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and/or used by cloud consumers. Or the local computing device of the vehicle computer system 54N may communicate with the one or more cloud computing nodes. Nodes 52 can communicate with each other. The nodes may be grouped physically or virtually (not shown) in one or more networks, such as a private, clustered, public or hybrid cloud as described above, or a combination thereof. This scenario allows the cloud computing environment 50 to provide infrastructure, platform and/or software as services for which the cloud consumer does not need to maintain resources on the local computing device. It should be understood that the types of computing devices 54A-54N shown in Figure 12 are intended to be illustrative only, and that computing node 52 and cloud computing environment 50 may be connected via any type of network and/or network addressable connection (e.g., Use a web browser) to communicate with any type of computerized device.

Referring now to Figure 13, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 12) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 13 are intended to be illustrative only and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided.

Hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframe computer 61; server 62 based on reduced instruction set computer (RISC) architecture; server 63; blade server 64; storage device 65; and network and network connection components 66. In some embodiments, the software components include web application server software 67 and database software 68.

Virtualization layer 70 provides an abstraction layer from which virtual entities can be provided. Example below: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

In one example, management layer 80 may provide functionality described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources for performing tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within a cloud computing environment, and accounting or invoicing for the consumption of such resources. In one example, these resources may include application software authorizations. Security provides identity verification for cloud consumers and tasks, as well as protection of data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management to meet required service levels. Service Level Agreement (SLA) Planning and Implementation 85 provides pre-configuration and procurement of cloud computing resources. Future requirements for cloud computing resources are anticipated based on the SLA.

Workload layer 90 provides instances of functionality for which the cloud computing environment can be utilized. Examples of workloads and functions that can be provided from this layer include: mapping and navigation91; software development and lifecycle management92; virtual classroom education delivery93; data analysis processing94; transaction processing95; and tagging/validation processing96.

Aspects of the invention may be systems, methods and/or computer program products at any possible level of integration of technical details. The computer program product may include one (or more) computer-readable storage media having computer-readable program instructions thereon to cause the processor to perform aspects of the present invention.

A computer-readable storage medium may be a tangible device that retains and stores instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media Including the following: portable computer disks, hard drives, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), Static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device (such as one with instructions recorded on it) punched cards or raised structures in grooves), and any suitable combination of the foregoing. As used herein, computer-readable storage media themselves should not be construed as temporary signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated through waveguides or other transmission media (e.g., pulses of light traveling through fiber optic cables) ), or electrical signals transmitted through wires.

Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing/processing device or via a network (e.g., the Internet, a local area network, a wide area network, and/or a wireless network) to an external computer or external storage device. Networks may include copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in the respective computing/processing device. Read the storage medium.

Computer-readable program instructions for performing operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, written in any combination of one or more programming languages. Firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code in one or more programming languages including object-oriented programming languages such as Smalltalk, C++, etc., and procedural A programming language, such as the "C" programming language or similar programming language. Computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone package, partly on the user's computer and partly on a remote computer, or Executed entirely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (for example, using Internet service provider via the Internet). In some embodiments, electronic circuits (including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLA)) can be configured individually by utilizing state information from computer-readable program instructions. An electronic circuit is used to execute computer-readable program instructions in order to execute aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-readable program instructions.

Such computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing device to produce a machine such that instructions executed by the processor of the computer or other programmable data processing device create Components used to implement the functions/actions specified in the one or more flowchart and/or block diagram blocks. Such computer-readable program instructions may also be stored in a computer-readable storage medium. Such instructions may instruct computers, programmable data processing equipment, and/or other devices to function in a specific manner, such that the computer in which the instructions are stored The readable storage medium includes an article of manufacture including instructions that implement the functions/actions specified in the one or more flowchart and/or block diagram blocks.

Computer-readable program instructions may also be loaded into a computer, other programmable data processing equipment, or other device to cause a series of operating steps to be executed on the computer, other programmable equipment, or other device to produce computer-implemented processing. A program that causes instructions executed on the computer, other programmable device, or other device to implement the one or more flowchart and/or block diagram areas The function/action specified in the block.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the invention. In this regard, each block in the flowchart or block diagrams may represent a module, section, or portion of instructions, which contains one or more executable instructions for implementing the specified logical function or functions. In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact execute substantially concurrently, or the blocks may sometimes execute in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations and the block diagrams and/or flowchart illustrations may be implemented by a special purpose hardware-based system that performs the specified function or action or a combination of special hardware and computer instructions. The combination of blocks in the description.

In addition to the above, one or more aspects may be provided, deployed, managed, serviced, etc. by a service provider that provides management of the customer environment. For example, a service provider may create, maintain, support(etc.) computer code and/or execute computer infrastructure in one or more aspects for use by one or more customers. In return, the service provider may receive payment from the customer under a subscription and/or fee contract (as an example). Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.

In one aspect, an application may be deployed for performing one or more embodiments. As one example, deployment of an application includes providing computer infrastructure operable to execute one or more embodiments.

As yet another aspect, computing infrastructure may be deployed, including integrating computer-readable code into a computing system, where the code in conjunction with the computing system is capable of executing one or more embodiments.

As yet another aspect, a process for integrating computing infrastructure can be provided A program consists of integrating computer-readable code into a computer system. The computer system includes computer-readable media, where the computer media includes one or more embodiments. The program code, in conjunction with a computer system, is capable of executing one or more embodiments.

Although various embodiments are described above, they are examples only. For example, other architectural computing environments may be used with and using one or more embodiments. Additionally, different instructions or operations can be used. Additionally, different registers and/or other types of cryptographic algorithms may be used. Many variations are possible.

Additionally, other types of computing environments may be beneficial and may be used. As an example, a data processing system suitable for storing and/or executing program code may be used that includes at least two processors coupled to a memory element, either directly or indirectly through a system bus. Memory components include, for example, local memory used during actual execution of the code, bulk storage, and provision of temporary storage of at least some code in order to reduce the need to retrieve the code from bulk storage during execution. number of caches.

Input/output or I/O devices (including (but not limited to) keyboards, monitors, pointing devices, DASD, tapes, CDs, DVDs, thumb drives and other memory media, etc.) can be directly or through intervention. The I/O controller is coupled to the system. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a/an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the terms "comprises and/or composition" when used in this specification designate the stated specific features, integers, steps, operations, elements and/or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.

All corresponding structures, materials, acts, and equivalents of all components or step plus function elements within the scope of the following claims, if any, are intended to include any structure, material, or equivalent for performing the function in combination with other claimed elements as specifically claimed. action. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments were chosen and described in order to best explain the various aspects and practical applications, to enable others of ordinary skill in the art to understand the various embodiments and with the various modifications as are suited to the particular use contemplated.

300: Computed Digital Signature Authentication (KDSA) command

302:Operation code field

304: First register field (R ₁ )

306: Second register field (R ₂ )

Claims (20)

A computer program product for facilitating processing within a computing environment, the computer program product comprising: a computer-readable storage medium readable by a processing circuit and storing instructions for executing a method comprising: obtaining An instruction for performing an operation to generate a signature for a message, the instruction being a single structured instruction that is part of a general-purpose processor instruction set architecture, the instruction representing a buffer and including at least one opcode field for specifying the operation; and implementing the instruction to perform the operation, the implementation including: determining one of a plurality of tagged functions supported by the instruction to be executed, The plurality of marking functions include a first marking function that uses a first random number to randomize a first signature and a second marking function that does not use a second random number to randomize a second signature. function, and the determining includes identifying the tag from the plurality of tag functions including the first tag function and the second tag function via a corresponding tag function code of the plurality of tag functions supported by the instruction. function; obtains input for the command, the input including the message and a cryptographic key; and generates the signature based on the tagged function to be executed and the input, the signature to be used to authenticate the message. For example, the computer program product of claim 1, wherein the message is a hashed message. For example, the computer program product of claim 1, wherein the signature is represented by a plurality of values. The computer program product of claim 3, wherein the plurality of values includes a first integer and a second integer between zero and an order of a curve for the marking function to be executed. The computer program product of claim 3, wherein the marking function includes an Edwards curve digital signature algorithm marking function, and the plurality of values includes a compressed point and an integer. For example, the computer program product of claim 1, wherein the input further includes a random number. For example, the computer program product of claim 6, wherein the implementation further includes: testing that the random number is between a first value and a second value; and based on the random number being between the first value and the second value The signature is generated between executions. The computer program product of claim 7, wherein the first value is zero, and the second value represents the first order of a base point of a curve for the marking function to be executed. The computer program product of claim 1, wherein the plurality of marking functions include a plurality of elliptic curve digital signature algorithm marking functions for a plurality of prime numbers. For example, the computer program product of claim 9, wherein the plurality of prime numbers includes National Institute of Standards and Technology (NIST) prime number P256, NIST prime number P384 and NIST prime number P521. The computer program product of claim 1, wherein the plurality of marking functions include a plurality of Edwards curve digital signature algorithm marking functions for a plurality of prime numbers. For example, the computer program product of claim 11, wherein the plurality of prime numbers includes the Edwards curve prime number Ed25519 and the Edwards curve prime number Ed448. A computer system for facilitating processing within a computing environment, the computer system comprising: a memory; and a processor coupled to the memory, wherein the computer system is configured to perform a method, the method Includes: obtaining an instruction to perform an operation to generate a signature for a message, the instruction being a single architected instruction that is part of a general-purpose processor instruction set architecture, the instruction representing a register and including at least one opcode field for specifying the operation; and implementing the instruction to perform the operation, the implementation including: determining one of a plurality of tagged functions supported by the instruction to be executed Functions, the plurality of marking functions include a first marking function that uses a first random number to randomize a first signature and one that does not use a second random number to randomize a second signature. a second marker function, and the determination includes passing a corresponding marker function code from a plurality of marker functions supported by the instruction from the plurality of marker functions including the first marker function and the second marker function Identify the tagged function; obtain input for the command, the input including the message and a cryptographic key; and generate the signature based on the tagged function to be executed and the input, the signature to be used Verify this message. For example, the computer system of claim 13, wherein the message is a hashed message. The computer system of claim 13, wherein the input further includes a random number. Such as the computer system of claim 15, wherein the implementation further includes: testing that the random number is between a first value and a second value; and based on the random number being between the first value and the second value. The signature is generated during execution. A computer-implemented method for facilitating processing within a computing environment, the computer-implemented method comprising: obtaining, from a processor, an instruction for performing an operation to generate a signature for a message, the instruction being a single an architected instruction, the single architected instruction being part of a general-purpose processor instruction set architecture, the instruction representing a register and including at least one opcode field used to specify the operation; and implementing the instruction to perform the operation , the implementation includes: determining one of a plurality of tagged functions supported by the instruction to be executed, the plurality of tagged functions including using a first random number to randomize one of the first signatures. a marking function and a second marking function that does not use a second random number to randomize a second signature, and the determination includes passing a corresponding marking function of a plurality of marking functions supported by the instruction The code identifies the marked function from the plurality of marked functions including the first marked function and the second marked function; Obtain input for the command, the input including the message and a cryptographic key; and generate the signature based on the tagged function to be executed and the input, the signature to be used to authenticate the message. The computer implementation method of claim 17, wherein the message is a hashed message. Such as the computer implementation method of claim 17, wherein the signature is represented by a plurality of values. As claimed in claim 17, the computer implementation method, wherein the input further includes a random number, and the implementation further includes: testing that the random number is between a first value and a second value; and based on the random number Generating the signature is performed between the first value and the second value.