Systems, apparatus, and methods for verifying a password utilizing commitments

Methods that can verify a password utilizing commitments are provided. One method includes receiving from a client device and storing, by a processor, an initial commitment representing a password for a user account without storing the actual password on the apparatus, receiving, from the client device, a subsequent commitment, and verifying that the subsequent commitment represents the password for the user account based on a difference between the initial commitment and the subsequent commitment. Systems and apparatus that can include, perform, and/or implement the methods are also provided.

FIELD

The subject matter disclosed herein relates to computing networks, systems, and apparatus and, more particularly, relates to computing networks, systems, and methods for verifying a password utilizing commitments.

BACKGROUND

In some conventional computing network, systems, and apparatus, user passwords are sent in clear form from a client device to a server and then hashed on the server. In other conventional computing network, systems, and apparatus, the user passwords are hashed on the client device using a static key (or salt) and then transmitted to the server for storage on the server. In further conventional computing network, systems, and apparatus, the user passwords are encrypted with a public/private key cryptography and interactive zero knowledge systems (ZKS) schemas. While these techniques provide a level of password protection, improved password protection can be made available.

BRIEF SUMMARY

Methods, systems, apparatus, and methods that can verify a password utilizing commitments are provided. One method includes receiving from a client device and storing, by a processor, an initial commitment representing a password for a user account without storing the actual password on the apparatus and receiving, from the client device, a subsequent commitment, and verifying that the subsequent commitment represents the password for the user account based on a difference between the initial commitment and the subsequent commitment.

A system includes a processor of an information handling device and a memory configured to store code executable by the processor. The code causes the processor to receive, from a client device, and store an initial commitment representing a password for a user account without storing the actual password on the apparatus, receive, from the client device, a subsequent commitment, and verify that the subsequent commitment represents the password for the user account based on a difference between the initial commitment and the subsequent commitment.

A computer program product comprising a computer-readable storage medium configured to store code executable by a processor are also provided. The executable code comprises code to perform receiving from a client device and storing an initial commitment representing a password for a user account without storing the actual password on the apparatus, receiving, from the client device, a subsequent commitment, and verifying that the subsequent commitment represents the password for the user account based on a difference between the initial commitment and the subsequent commitment.

DETAILED DESCRIPTION

Disclosed herein are various embodiments providing methods, systems, and computer program products that can merge protocols for storage networks and systems. Notably, the language used in the present disclosure has been principally selected for readability and instructional purposes, and not to limit the scope of the subject matter disclosed herein in any manner.

In addition, as used herein, the term “set” can mean “one or more,” unless expressly specified otherwise. The term “sets” can mean multiples of or a plurality of “one or mores,” “ones or more,” and/or “ones or mores” consistent with set theory, unless expressly specified otherwise.

The present technology may be a system, a method, and/or a computer program product. The computer program product may include a computer-readable storage medium (or media) including computer-readable program instructions thereon for causing a processor to carry out aspects of the present technology.

The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is 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 the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (“RAM”), a read-only memory (“ROM”), an erasable programmable read-only memory (“EPROM” or Flash memory), a static random access memory (“SRAM”), a portable compact disc read-only memory (“CD-ROM”), a digital versatile disk (“DVD”), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove including instructions recorded thereon, and any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fibre-optic cable), or electrical signals transmitted through a wire.

To more particularly emphasize their implementation independence, many of the functional units described in this specification have been labeled as modules. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

The schematic flowchart diagrams and/or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations. It should also be noted that, 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, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. Although various arrow types and line types may be employed in the flowchart and/or block diagrams, they are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used to indicate only an exemplary logical flow of the depicted embodiment.

The description of elements in each figure below may refer to elements of proceeding figures. For instance, like numbers can refer to similar elements in all figures, including alternate embodiments of similar elements.

With reference now to the drawings,FIG.1is a block diagram of one embodiment of a computing system100including a network102connecting a set of client devices104(also simply referred individually, in various groups, or collectively as client device(s)104) and a host system and/or device106(also simply referred to as host106). The network102may be any suitable wired and/or wireless network102(e.g., public and/or private computer networks in any number and/or configuration (e.g., the Internet, an intranet, a cloud network, etc.)) that is known or developed in the future that enables the set of client devices104and the host106to be coupled to and/or in communication with one another and/or to share resources. In various embodiments, the network102can comprise a cloud network (IAN), a SAN (e.g., a storage area network, a small area network, a server area network, and/or a system area network), a wide area network (WAN), a local area network (LAN), a wireless local area network (WLAN), a metropolitan area network (MAN), an enterprise private network (EPN), a virtual private network (VPN), and/or a personal area network (PAN), among other examples of computing networks and/or or sets of computing devices connected together for the purpose of sharing resources that are possible and contemplated herein.

A client device104can include any suitable computing hardware and/or software (e.g., a thick client, a thin client, or hybrid thereof) capable of accessing the host106via the network102. A client device104can also include a computing device and/or computing system, and may also be referred to herein as an information handling device and/or information handling system.

Each client device104, as part of its respective operation, relies on sending I/O requests to the host106to write data, read data, and/or modify data. Specifically, each client device104can transmit I/O requests to read, write, store, communicate, propagate, and/or transport instructions, data, computer programs, software, code, routines, etc., to the host106and may comprise at least a portion of a client-server model. In general, the host106can be accessed by the client device(s)104and/or communication with the host106can be initiated by the client device(s)104through a network socket (not shown) utilizing one or more inter-process networking techniques.

In various embodiments, the client device(s)104utilize a password to access the host106. The password can be generated by a client device104and/or by a user of the client device. The password is stored on the client device104and is verified by the host106to access the host106, as discussed in greater detail elsewhere herein. In other words, the password is not stored on the host106, but is verified by the host106when the client device104attempts to access the host106.

In some embodiments, verification of the password is performed utilizing a commitment schema. In additional or alternative embodiments, verification of the password is performed utilizing a time-based commitment schema. In further additional or alternative embodiments, verification of the password is performed utilizing a time-based Pedersen commitment schema. Each of these commitment schemas is discussed in greater detail elsewhere herein.

Referring toFIG.2A,FIG.2Ais a block diagram of one embodiment of a client device104A illustrated in and discussed with reference toFIG.1. In various embodiments, a client device104A may form a mobile computing device/system (e.g., a laptop computer, a personal digital assistant (PDA), a tablet computer, a smart phone, a cellular telephone, a smart television, a wearable device, an Internet of Things (IoT) device, a game console, a vehicle on-board computer, a streaming device, a smart device, and a digital assistant, etc., among other mobile computing devices and/or information handling devices that are possible and contemplated herein). At least in the illustrated embodiment, a client device104A includes, among other components, a set of display devices202, a set of input devices204, a set of memory devices206, and a processor208coupled to and in communication with one another via a bus210(e.g., a wired and/or wireless bus).

A display device202A may include any suitable hardware and/or software that can display digital information (e.g., digital data) thereon. In various embodiments, the display device202A includes an internal display device or other similar device that can display data thereon that forms a portion of an information handling device. In some embodiments, the display device202A includes a touch screen that can receive one or more inputs from a user via the user's fingers and/or a stylus, etc.

An input device204may include any suitable hardware and/or software that can receive a user input (e.g., a password). Examples of an input device204include, but are not limited to, a keyboard, a touchscreen, a mouse, a trackball, a joystick, a touchpad, a scanner, and/or a pointing stick, etc., among other devices that are capable of receiving user inputs that are possible and contemplated herein.

A set of input devices204may include any suitable quantity of input devices204. In some embodiments, the set of input devices204includes one (1) input device204. In other embodiments, the set of input devices204includes two (2) or more input devices204.

A set of memory devices206may include any suitable quantity of memory devices206. Further, a memory device206may include any suitable type of storage and/or memory device and/or system that is known or developed in the future that can store computer-useable and/or computer-readable code.

In various embodiments, a memory device206may include one or more non-transitory computer-usable mediums (e.g., readable, writable, etc.), which may include any non-transitory and/or persistent apparatus or device that can contain, store, communicate, propagate, and/or transport instructions, data, computer programs, software, code, routines, etc., for processing by or in connection with a computer processing device. In some embodiments, the memory device(s)206are configured to store one or more passwords for accessing the host106. The password(s) may be generated by the client device104and/or by a user.

A memory device206, in some embodiments, includes volatile computer storage media. For example, a memory device206may include random access memory (RAM), including dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), and/or static RAM (SRAM). In other embodiments, a memory device206includes non-volatile computer storage media. For example, a memory device206may include a hard disk drive, a flash memory, and/or any other suitable non-volatile computer storage device that is known or developed in the future. In various embodiments, a memory device206includes both volatile and non-volatile computer storage media. In additional embodiments, a memory device206also stores program code and/or related data, such as an operating system (OS) and/or other controller algorithms operating on a client device104.

With reference now toFIG.3,FIG.3is a schematic block diagram of an embodiment of a memory device206. At least in the illustrated embodiment, the memory device206includes, among other components, a password module302, a commitment module304, and an input/output (I/O) module306.

A password module302may include any suitable hardware and/or software that can generate one or more passwords and/or receive one or more passwords from a user (e.g., via the input device204) for accessing the host106. The password(s) may include any suitable password that is known or developed in the future. In various embodiments, a password may include alphanumeric characters and/or biometric data transformed into one or more values upon which mathematical calculations can be performed.

The password module302, in some embodiments, is configured to store the password(s). In various embodiments, the password module302is configured to transmit the password(s) to the commitment module304for processing thereon.

A commitment module304may include any suitable hardware and/or software that can implement a commitment schema on a password. In various embodiments, the commitment module304is configured to receive a password from the password module302and implement a commitment schema on the password.

In various embodiments, the commitment schema includes a time-based commitment schema. In further embodiments, the commitment schema includes a Pedersen commitment schema. In additional or alternative embodiments, the commitment schema includes a time-based Pedersen commitment schema.

In various embodiments, the commitment schema includes an elliptical curve based on an Elliptic Curve Discreet Logarithm Problem (ECDLP). Further, the commitment schema may utilize any suitable elliptical curve equation. Alternative embodiments may utilize a commitment schema based on the Elliptic Curve Discreet Logarithm Problem.

In some embodiments, the ECDLP commitment C(S, R) is represented by equation 1,
C=(S*G)+(R*H).  (1)
In equation (1), S is a hashed value of the password (e.g., calculated by a hash module402(see, e.g.,FIG.4)), G is an elliptical generator value for the elliptical curve (e.g., determined/identified by a generator module404(see, e.g.,FIG.4)), H is the elliptical generator value G hashed to a timestamp value to a point on the elliptical curve (e.g., calculated by a timestamp module406(see, e.g.,FIG.4)), and R is a random salt value (e.g., calculated by an encryption module408(see, e.g.,FIG.4)), each of which is discussed in greater detail elsewhere herein.

The elliptical curve may include any suitable elliptical curve parameters that are known or developed in the future. In some embodiments, the elliptical curve includes a public field parameter with a prime number and/or quantity of elements. That is, in various embodiments, the elliptical curve can include the field secp256k1, secp384k1, and/or secp521k1, among other fields with a prime number and/or quantity of elements that are possible and contemplated herein. In the various embodiments, the prime number and/or prime quantity of elements can be any suitable prime number and/or prime quantity of elements.

In other embodiments, the elliptical curve includes a public field parameter with a power of 2 number and/or quantity of elements. That is, in various embodiments, the elliptical curve can include the field secp283k1, secp409k1, and/or secp571k1, among other fields with a power of 2 number and/or quantity of elements that are possible and contemplated herein. In the various embodiments, the power of 2 number and/or power of 2 quantity of elements can be any suitable power of 2 number and/or power of 2 quantity elements.

In still other embodiments, Barreto-Naehrig (BN) pairing-friendly elliptical curves or other BN curves can be utilized. Thus, several different types of curves can be used with a Zero Knowledge Commitment.

With reference toFIG.4,FIG.4is a block diagram of one embodiment of a commitment module304. At least in the illustrated embodiment, the commitment module304includes, among other components, a hash module402, a generator module404, a timestamp module406, an encryption module408, and a commitment value module410.

A hash module402may include any suitable hardware and/or software that can perform a hash function and/or calculation on a password. In various embodiments, the hash module402is configured to receive a password from the password module302and perform a hash function and/or calculation on the password.

The hash module402may perform any suitable cryptographic hash function and/or calculation on the password that is known or developed in the future that can generate a hashed value (e.g., a hashed password (S)). In various embodiments, the hash module402is configured to perform a Secure Hash Algorithm 2 (SHA-2) on the password in generating the value S. That is, the hash module402may be configured to perform a SHA-2 function with 256 bits (SHA-256), 384 bits (SHA-384), or 512 bits (SHA-512, SHA-512/224, or SHA-512/256), among other SHA-2 functions that are possible and contemplated herein. Alternatively, password based key derivation functions, such as PDBKF2, scrypt, bcrypt, and argon2, can be utilized.

The hash module402, in some embodiments, is configured to store the hashed password or value S. In various embodiments, the hash module402is configured to transmit the hashed password or value S to the commitment value module410for processing thereon. The hash module402is configured not to transmit the hashed password or the value S to the I/O module306.

A generator module404may include any suitable hardware and/or software that can determine and/or identify an elliptical generator (e.g., the value (G)) for the elliptical curve. In various embodiments, the elliptical generator or the value G is determined/identified based on the parameters for the elliptical curve. That is, the elliptical generator or the value G is a value generated from the public field parameter of the elliptical curve. In other words, the value G is generated/determined from the public parameters of the prime number field (e.g., secp256k1, secp384k1, secp521k1, etc.), the power of 2 field (e.g., secp283k1, secp409k1, secp571k1, etc.), or other elliptical curves (e.g., Barreto-Naehrig (BN) pairing-friendly elliptical curves or other BN curve(s), etc.).

The generator module404, in some embodiments, is configured to store the value G. In various embodiments, the generator module404is configured to transmit the value G to the commitment value module410for processing thereon and/or to the I/O module306.

A timestamp module406may include any suitable hardware and/or software that can generate a hashed value that is based on time. In various embodiments, the timestamp module406is configured to generate a value H for the commitment C(S,R).

In various embodiments, the value H is generated by calculating the value G hashed to a timestamp to a point on the elliptical curve. In certain embodiments, the value H is a large value.

The timestamp module406may utilize any hashing method, technique, and/or value that is known or developed in the future to generate H by hashing G to the timestamp to the point on the elliptical curve. In various embodiments, the timestamp module406generates H as a derivative of G using a hash function with a time factor as one of the attribute, which can be represented as,to_point(Hashing Function (G, timestamp/time range)).
In some embodiments, the timestamp module406generates H as a derivative of G using the hash function,to_point(SHA256 (ENCODE(G))),
among other hash functions that are possible and contemplated herein.

In some embodiments, the value H includes a token that is valid for a predetermined amount of time, which can be any suitable amount of time for a particular password, application, and/or computing system/device. In certain embodiments, the token is valid for about 5 minutes, among other amounts of time that are possible and contemplated herein. In other embodiments, the token is valid for an amount of time that is less than about 5 minutes or for an amount of time that is greater than about 5 minutes, among other time values that are possible and contemplated herein.

The timestamp module406, in some embodiments, is configured to store the value H. In various embodiments, the timestamp module406is configured to transmit the value H to the commitment value module410for processing thereon. In further embodiments, the timestamp module406is configured to transmit the H value (and the timestamp and/or the token) to the I/O module306.

An encryption module408may include any suitable hardware and/or software that can generate an encryption value, an encryption key, and/or a salt value (simply referred to herein as, salt, a salt value, or the value R), which can be referred to as a blinding factor. The length of the salt value (or salt) can be any suitable length that can sufficiently encrypt the password so that the password is not easily detectable and/or discernable. Further, the salt value can be any suitable value that can sufficiently encrypt a password so that the password is not easily detectable and/or discernable.

In some embodiments, the salt value includes a random length and a random salt value. In other embodiments, the salt value includes a static length and a random salt value. In still other embodiments, the salt value includes a static value and a static salt length.

The encryption module408, in some embodiments, is configured to store the salt or value R. In various embodiments, the encryption module408is configured to transmit the salt or value R to the commitment value module410for processing thereon and/or to the I/O module306.

A commitment value module410may include any suitable hardware and/or software that can calculate a commitment value. In various embodiments, the commitment value module410is configured to receive the value H, the value G, the value H, and the value R and calculate a commitment value C for the commitment C(S,R) (see, e.g., equation (1) above). That is, the commitment value module410is configured to calculate a commitment value C by plugging in the values received from the hash module402, the generator module404, the timestamp module406, and the encryption module408.

In some embodiments, the commitment value module410is configured to generate an initial commitment value C0 ((S0*G)+(H0*R0)) in response to the password module302and/or the user creating/generating a new or initial password for accessing the host106, in which S0 is the initial password hashed to a value. In further embodiments, the commitment value module410is configured to generate a subsequent commitment value C1 ((S1*G)+(H1*R1)) in response to each attempt by the user to access the host106, in which S1 is the password used to access the host106hashed to a value.

The commitment value module410, in some embodiments, is configured to store the initial commitment value C0, one or more subsequent commitment values C1, and/or each subsequent commitment value C1. In various embodiments, the commitment value module410is configured to transmit the initial commitment value C0 and each subsequent commitment value C1 to the I/O module306.

Referring again toFIG.3, an I/O module306may include any suitable hardware and/or software that enables and/or allows a client device104to communicate and/or share resources with the host106. In various embodiments, the I/O module306is configured to receive the value G from the generator module404, the timestamp (and token) from the timestamp module406, the value R from the encryption module408, and the initial commitment value C0 and each subsequent commitment value C1 from the commitment value module410and transmit the value G, the H value (and the timestamp and/or token), the value R, the initial commitment value C0, and each subsequent commitment value C1 to the host106for storage and/or processing on the host106.

Notably, the I/O module306does not receive the value S from the hash module402and, thus, the value S is not transmitted to the host106. That is, the host106never receives the value S from the client device104, but instead, uses the initial commitment value C0, the G value, two H values, two R values, and a subsequent commitment value C1 to verify the authenticity of a password each time the client device104attempts to access the host106. In other words, the host106does not utilize the password itself to verify the authenticity of a password when the client device104is attempting to access the host106.

With reference again toFIG.2A, a processor208may include any suitable non-volatile/persistent hardware and/or software configured to perform and/or facilitate performing functions and/or operations for facilitating verification of a password on a host106. In various embodiments, the processor208includes hardware and/or software for executing instructions in one or more modules and/or applications that can perform and/or facilitate performing functions and/or operations for facilitating verification of a password on the host106. The modules and/or applications executed by the processor208for facilitating verification of a password on a host106can be stored on and executed from a memory device206and/or from the processor208.

With reference toFIG.5,FIG.5is a schematic block diagram of one embodiment of a processor208. At least in the illustrated embodiment, the processor208includes, among other components, a password module502, a commitment module504, and an I/O module506similar to the password module302, the commitment module304, and the I/O module306discussed elsewhere herein with reference to the memory device(s)206.

In various embodiments, the commitment module504includes a hash module402, a generator module404, a timestamp module406, an encryption module408, and a commitment value module410similar to the commitment module304discussed herein with reference to the memory device(s)206. Accordingly, a client device104can include the hash module402, the generator module404, the timestamp module406, the encryption module408, and/or the commitment value module410on the set of memory devices206and/or on the processor208.

Referring toFIG.2B,FIG.2Bis a block diagram of one embodiment of a client device104B illustrated in and discussed with reference toFIG.1. In various embodiments, a client device104B may form a non-mobile computing device/system (e.g., a desktop computer, a set-top box, a game console, a vehicle on-board computer, and a streaming device, etc., among other information handling devices that utilize an external display device that are possible and contemplated herein). At least in the illustrated embodiment, a client device104B includes a set of display devices202B (e.g., one or more external displays and/or monitors). The client device104B further includes, among other components, a set of input devices204, a set of memory devices206, and a processor208coupled to and in communication with one another via a bus210(e.g., a wired and/or wireless bus) similar to the set of input devices204, the set of memory devices206, and the processor208coupled to and in communication with one another via the bus210in the client device104A discussed with reference toFIG.2B.

With reference toFIG.6,FIG.6is a block diagram of one embodiment of a host106illustrated in and discussed with reference toFIG.1. The host106(or host device106) may include any suitable computer hardware and/or software that is known or developed in the future that can provide host operations. In various embodiments, a host106can include one or more processors, computer-readable memory, and/or one or more interfaces, among other features and/or hardware. A host106can further include any suitable software component or module, or computing device(s) that is/are capable of hosting and/or serving a software application or services, including distributed, enterprise, and/or cloud-based software applications, data, and services. For instance, a host106can be configured to host, serve, or otherwise manage data sets, or applications interfacing, coordinating with, or dependent on or used by other services, including transportation service applications and software tools. In some instances, a host106can be implemented as some combination of devices that can comprise a common computing system, server, server pool, or cloud computing environment and share computing resources, including shared memory, processors, and interfaces. At least in the illustrated embodiment, the host106includes, among other components, a set of storage devices602A through602nand a processor604coupled to and in communication with one another via a bus606(e.g., a wired and/or wireless bus).

The storage devices602A through602n(also simply referred individually, in various groups, or collectively as storage device(s)602) may be any suitable type of device and/or system that is known or developed in the future that can store computer-useable data. In various embodiments, a storage device602may include one or more non-transitory computer-usable mediums (e.g., readable, writable, etc.), which may include any non-transitory and/or persistent apparatus or device that can contain, store, communicate, propagate, and/or transport instructions, data, computer programs, software, code, routines, etc., for processing by or in connection with a computer processing device.

Referring toFIG.7,FIG.7is a schematic block diagram of an embodiment of a storage device602. At least in the illustrated embodiment, the storage device602includes, among other components, an initial values module702, a subsequent values module704, and a verification module706.

An initial values module702may include any suitable hardware and/or software that can receive and store one or more sets of initial values. In various embodiments, the initial values module702is configured to receive the value G, an initial H value H0 (and an initial timestamp), an initial R value R0, and an initial commitment value C0 from the client device104and store the value G0, the initial timestamp value, the value R0, and the initial commitment value C0.

The value G, the initial timestamp value, the initial R value R0, and the initial commitment value C0 are the values generated by the client device104when the client device104and/or the user creates a password for accessing the host device106. In some embodiments, the initial values module702is configured to calculate the initial H value H0 based on the value G and the timestamp value received from the client device104.

Further, the value G, the initial H value H0, the initial R value R0, and the initial commitment value C0 can be subsequently utilized by the host106to verify the authenticity of the password when the client device104and/or user attempts to access the host106. As such, the value G, the initial H value H0, the initial R value R0, and the initial commitment value C0 can be transmitted to the verification module306in the future in response to the client device104and/or user attempting to access the host106.

A subsequent values module704may include any suitable hardware and/or software that can receive and/or store one or more sets of subsequent values. In various embodiments, the subsequent values module704is configured to receive the value G, a subsequent H value H1 (and a subsequent timestamp value and/or a token), a subsequent R value R1, and a subsequent commitment value C1 from the client device104. In some embodiments, the subsequent values module704is configured to store the value G, the subsequent H value H1, the subsequent R value R1, and the subsequent commitment value C1.

The value G, the subsequent H value H1, the subsequent R value R1, and the subsequent commitment value C1 are the values generated by the client device104when the client device104and/or the user inputs a password in an attempt to access the host device106. Further, the value G, the subsequent H value H1, the subsequent R value R1, and the subsequent commitment value C1 are utilized by the host106to verify the authenticity of the password input by the client device104and/or user. As such, the value G, the subsequent H value H1, the subsequent R value R1, and the subsequent commitment value C1 can be transmitted to the verification module306in response to the client device104and/or user attempting to access the host106.

A verification module706may include any suitable hardware and/or software that can verify the authenticity of a password in a commitment schema. In various embodiments, the verification module706is configured to verify the password utilizing the initial values stored in the initial values module702and the subsequent values in the subsequent values module704.

The verification module706, in some embodiments, is configured to receive the value G, the initial H value H0, the initial R value R0, and the initial commitment value C0 from the initial values module702and the value G, the subsequent H value H1, the subsequent R value R1, and the subsequent commitment value C1 from the subsequent values module704in response to the client device104and/or the user attempting to access the host106. In various embodiments, the verification module706is configured to verify the password based on a mathematical difference between the initial values and the subsequent values. In other words, the verification module706is configured to verify the password utilizing a verification process and/or algorithm.

One portion of a verification process and/or algorithm performed by the verification module706includes determining a mathematical difference (e.g., a value) between the subsequent commitment value C1 and the initial commitment value C0 (e.g., C1−C0, C0−C1, |C1−C0|, or |C0−C1|). Another portion of the verification process and/or algorithm performed by the verification module706includes determining the mathematical value of the product of the subsequent H value H1 and the subsequent R value R1 (H1*R1) and the mathematical value of the product of the initial H value H0 and the initial R value R0 (H0*R0). A further portion of the verification process and/or algorithm performed by the verification module706includes determining the mathematical difference (e.g., a value) between the product of the subsequent H value H1 and the subsequent R value R1 and the product of the initial H value H0 and the initial R value R0 (e.g., (H1*R1)−(H0*R0), (H0*R0)−(H1*R1), |(H1*R1)−(H0*R0)|, and |(H0*R0)−(H1*R1)|). A certain portion of the verification process and/or algorithm performed by the verification module706includes comparing the mathematical difference between the subsequent commitment value C1 and the initial commitment value C0 and the mathematical difference between the product of the subsequent H value H1 and the subsequent R value R1 and the product of the initial H value H0 and the initial R value R0.

The verification module706is configured to verify that the password is authentic in response to the two differences matching one another (e.g., C1−C0=[(H1*R1)−(H0−R0)]). Further, the verification module706is configured to deem the password not authentic in response to the two differences not matching one another (e.g., C1−C0 [(H1*R1)−(H0−R0)]). Here, the Pedersen commitment ensures that the password is valid or authentic while not sharing the password with a host106(and/or server). The following is the logic supporting the verification process:
C1=[(S*G)+(H1*R1)], and
C0=[(S*G)+(H0*R0)].
Therefore, by substitution,
C1−C0=[(S*G)+(H1*R1)]−[(S*G)+(H0*R0)],
C1−C0=(S*G)+(H1*R1)−(S*G)−(H0*R0),
C1−C0=(S*G)−(S*G)+(H1*R1)−(H0*R0),
C1−C0=[(H1*R1)−(H0*R0)].
Thus, if C1−C0=[(H1*R1)−(H0*R0)], the (S*G) values must be the same value, which means the hashed passwords must be the same value, which further means that the passwords match and can, thus, be verified by the verification module706.

In some embodiments, the verification module706is configured to grant access to the host106to the client device104and/or user in response to the password be verified (e.g., C1−C0=[(H1*R1)−(H0*R0)]). Further, the verification module706is configured to deny access to the host106to the client device104and/or user in response to the password be not verified (e.g., C1−C0 [(H1*R1)−(H0*R0)]).

In certain embodiments, the password is valid for a predetermined period of time. The predetermined period of time, in various embodiments, is based on the token included in the timestamp received from the client device104. That is, the predetermined period of time may be, for example, 5 minutes, among other amounts of time that are greater than 5 minutes or less than 5 minutes that are possible and contemplated herein.

In some embodiments, at the expiration of the amount of time included in the token and/or timestamp, the client device104(and/or user) is logged out of the host104. Here, the client device104and/or the user can re-enter the password into the client device104and the password verification process between the client device104and the host106for accessing the host device106can be repeated.

In this manner, a password for accessing the host106without the host106ever storing the actual password can be obtained. Here, the client device104can store the password, which can render the host106more secure because disclosure/leakage of a commitment by the host106will not comprise the password and/or the hashed password.

With reference toFIG.8,FIG.8is a schematic block diagram of an embodiment of a processor604. At least in the illustrated embodiment, the processor604includes, among other components, an initial values module802, a subsequent values module804, and a verification module806similar to the initial values module702, the subsequent values module704, and the verification module706included in the storage device(s)604discussed with reference toFIG.7. Accordingly, a host106can include the initial values module702, the subsequent values module704, and the verification module706on the set of storage devices602and/or the initial values module802, the subsequent values module804, and the verification module806on the processor604.

With reference toFIG.9,FIG.9is a timing diagram900of one embodiment of operations for verifying a password using commitments. At least in the illustrated embodiment, the operations begin at time T0 by receiving, at a client device104, an initial password0 for accessing a host106.

At time T1, a processor (e.g., processor208) can calculate and store a hashed password S0 for the password0, a value G, an initial H value H0, an initial R value R0, and an initial commitment value C0, as discussed elsewhere herein. The processor208, at time T2, transmits the value G, initial H value H0, initial R value R0, and initial commitment value C0 to the host106for storage thereon. The processor208does not transmit the hashed password S1 to the host106.

In some embodiments, the client device104, at time T3, receives a subsequent password1 from a user when the user is attempting to access the host106via the client device. At time T4, the processor208calculates a hashed password S1 for the password1, a value G, a subsequent H value H1, a subsequent R value R1, and a subsequent commitment value C1, as discussed elsewhere herein.

The processor208, at time T5, transmits the value G, subsequent H value H1, subsequent R value R1, and subsequent commitment value C1 to the host106for verifying the password1. The processor208does not transmit the hashed password S2 to the host106.

The host106, at time T6, calculates whether C1−C0=[(H1*R1)−(H0*R0)] or C1−C0 [(H1*R1)−(H0*R0)]). At time T7, in response to C1−C0=[(H1*R1)−(H0*R0)], the host106allows the client device104to access the host106or, in response to C1−C0 [(H1*R1)−(H0*R0)]), the host106denies the client device104from accessing the host106.

Referring toFIG.10,FIG.10is a schematic flow chart diagram illustrating one embodiment of a method1000for verifying a password utilizing commitments. At least in the illustrated embodiment, the method1000can begin by a processor (e.g., processor208) receiving, at a client device104, an initial password0 for accessing a host106(block1002).

The processor208can calculate and store a hashed password S0 for the password0, a value G, an initial H value H0, an initial R value R0, and an initial commitment value C0, as discussed elsewhere herein (block1004). The processor208transmits the value G, initial H value H0, initial R value R0, and initial commitment value C0 to the host106for storage thereon (block1006). The processor208does not transmit the hashed password S1 to the host106.

In some embodiments, the processor208receives a subsequent password1 from a user when the user is attempting to access the host106via the client device (block1008). The processor208calculates a hashed password S1 for the password1, a value G, a subsequent H value H1, a subsequent R value R1, and a subsequent commitment value C1, as discussed elsewhere herein (block1010).

The processor208transmits the value G, subsequent H value H1, subsequent R value R1, and subsequent commitment value C1 to the host106for verifying the password1 (block1012). The processor208does not transmit the password1 or the hashed password S1 to the host106.

The processor208receives notice that access to the host has been granted or denied (block1014). The method1000can then end.

With reference toFIG.11,FIG.11is a schematic flow chart diagram illustrating another embodiment of a method1100for verifying a password utilizing commitments. At least in the illustrated embodiment, the method1100can begin by a processor (e.g., processor604) receiving, at a client device104, a value G, an initial H value H0, an initial R value R0, and an initial commitment value C0 for an initial password0 for storage thereon, as discussed elsewhere herein (block1102). The processor604does not receive a password0 or a hashed password S0.

The processor604subsequently receives a value G, a subsequent H value H1, a subsequent R value R1, and a subsequent commitment value C1 for a subsequent passowrd1 when the client device104is attempting to access the host106, as discussed elsewhere herein (block1104). The processor604does not receive the password1 or the hashed password S1.

The processor604calculates whether C1−C0=[(H1*R1)−(H0*R0)] (block1106). In response to C1−C0=[(H1*R1)−(H0*R0)] (a “YES” in block1106), the processor604grants access to the client device104(block1108). In response to C1−C0 [(H1*R1)−(H0*R0)]) (e.g., a “NO” in block1106), the processor604denies the client device104access to the host106(block1110).

Referring toFIG.12,FIG.12is a schematic flow chart diagram illustrating yet another embodiment of a method1200for verifying a password utilizing commitments. At least in the illustrated embodiment, the method1200can begin by a processor (e.g., processor208) receiving, at a client device104, an initial password0 for accessing a host106(block1202).

The processor208can calculate and store a hashed password S0 for the password0, a value G, an initial H value H0, an initial R value R0, and an initial commitment value C0, as discussed elsewhere herein (block1204). The processor208transmits the value G, initial H value H0, initial R value R0, and initial commitment value C0 to the host106for storage thereon (block1206). The processor208does not transmit the hashed password S1 to the host106.

A processor (e.g., processor604) receives, at a client device104, the value G, initial H value H0, initial R value R0, and initial commitment value C0 for storage thereon (block1208). The processor604does not receive the password0 or the hashed password S0.

The processor208receives a subsequent password1 from a user when the user is attempting to access the host106via the client device (block1210). The processor208calculates a hashed password S1 for the password1, a value G, a subsequent H value H1, a subsequent R value R1, and a subsequent commitment value C1, as discussed elsewhere herein (block1212).

The processor208transmits the value G, subsequent H value H1, subsequent R value R1, and subsequent commitment value C1 to the host106for verifying the password1 (block1214). The processor208does not transmit the password1 or the hashed password S1 to the host106.

The processor604receives the value G, subsequent H value H1, subsequent R value R1, and subsequent commitment value C1 for a subsequent passowrd1 when the client device104is attempting to access the host106, as discussed elsewhere herein (block1216). The processor604does not receive the password1 or the hashed password S1.

The processor604calculates whether C1−C0=[(H1*R1)−(H0*R0)] (block1218). In response to C1−C0=[(H1*R1)−(H0*R0)] (a “YES” in block1218), the processor604grants access to the client device104(block1220). In response to C1−C0 [(H1*R1)−(H0*R0)]) (e.g., a “NO” in block1218), the processor604denies the client device104access to the host106(block1222).