Poly1305 is a universal hash family designed by Daniel J. Bernstein for use in cryptography.
As with any universal hash family, Poly1305 can be used as a one-time message authentication code to authenticate a single message using a key shared between sender and recipient,
like a one-time pad can be used to conceal the content of a single message using a key shared between sender and recipient.
Originally Poly1305 was proposed as part of Poly1305-AES,
a Carter–Wegman authenticator
that combines the Poly1305 hash with AES-128 to authenticate many messages using a single short key and distinct message numbers.
Poly1305 was later applied with a single-use key generated for each message using XSalsa20 in the NaCl crypto_secretbox_xsalsa20poly1305 authenticated cipher,
and then using ChaCha in the ChaCha20-Poly1305 authenticated cipher
deployed in TLS on the internet.
Poly1305 takes a 16-byte secret key and an -byte message and returns a 16-byte hash .
To do this, Poly1305:
Interprets as a little-endian 16-byte integer.
Breaks the message into consecutive 16-byte chunks.
Interprets the 16-byte chunks as 17-byte little-endian integers by appending a 1 byte to every 16-byte chunk, to be used as coefficients of a polynomial.
Evaluates the polynomial at the point modulo the prime .
Reduces the result modulo encoded in little-endian return a 16-byte hash.
The coefficients of the polynomial , where , are:
with the exception that, if , then:
The secret key is restricted to have the bytes , i.e., to have their top four bits clear; and to have the bytes , i.e., to have their bottom two bits clear.
Thus there are distinct possible values of .
If is a secret 16-byte string interpreted as a little-endian integer, then
is called the authenticator for the message .
If a sender and recipient share the 32-byte secret key in advance, chosen uniformly at random, then the sender can transmit an authenticated message .
This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.
The tables below compare cryptography libraries that deal with cryptography algorithms and have API function calls to each of the supported features. This table denotes, if a cryptography library provides the technical requisites for FIPS 140, and the status of their FIPS 140 certification (according to NIST's CMVP search, modules in process list and implementation under test list). Key operations include key generation algorithms, key exchange agreements and public key cryptography standards.
OpenSSL is a software library for applications that provide secure communications over computer networks against eavesdropping, and identify the party at the other end. It is widely used by Internet servers, including the majority of HTTPS websites. OpenSSL contains an open-source implementation of the SSL and TLS protocols. The core library, written in the C programming language, implements basic cryptographic functions and provides various utility functions.
Cryptography, or cryptology (from κρυπτός "hidden, secret"; and γράφειν graphein, "to write", or -λογία -logia, "study", respectively), is the practice and study of techniques for secure communication in the presence of adversarial behavior. More generally, cryptography is about constructing and analyzing protocols that prevent third parties or the public from reading private messages. Modern cryptography exists at the intersection of the disciplines of mathematics, computer science, information security, electrical engineering, digital signal processing, physics, and others.
Four recent trends have emerged in the evolution of authenticated encryption schemes: (1) Regarding simplicity, the adoption of public permutations as primitives allows for sparing a key schedule and the need for storing round keys; (2) using the sums of p ...
Key agreement protocols are frequently based on the Diffie-Hellman protocol but require authenticating the protocol messages in two ways. This can be made by a cross-authentication protocol. Such protocols, based on the assumption that a channel which can ...
Our main motivation is to design more user-friendly security protocols. Indeed, if the use of the protocol is tedious, most users will not behave correctly and, consequently, security issues occur. An example is the actual behavior of a user in front of an ...