Hakase/openssl-custom
1
0 Fork 0
Code Issues Pull Requests Releases Wiki Activity

Latest update

Browse Source
This commit is contained in:
Hakase
2019-03-07 13:14:32 +09:00
parent 25fbda8e8b
commit ee0cf37f98
226 changed files with 20407 additions and 2210 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/man7/EVP_KDF_SSHKDF.pod
+175
View File
@@ -0,0 +1,175 @@
=pod
=head1 NAME
EVP_KDF_SSHKDF - The SSHKDF EVP_KDF implementation
=head1 DESCRIPTION
Support for computing the B<SSHKDF> KDF through the B<EVP_KDF> API.
The EVP_KDF_SSHKDF algorithm implements the SSHKDF key derivation function.
It is defined in RFC 4253, section 7.2 and is used by SSH to derive IVs,
encryption keys and integrity keys.
Five inputs are required to perform key derivation: The hashing function
(for example SHA256), the Initial Key, the Exchange Hash, the Session ID,
and the derivation key type.
=head2 Numeric identity
B<EVP_KDF_SSHKDF> is the numeric identity for this implementation; it
can be used with the EVP_KDF_CTX_new_id() function.
=head2 Supported controls
The supported controls are:
=over 4
=item B<EVP_KDF_CTRL_SET_MD>
=item B<EVP_KDF_CTRL_SET_KEY>
These controls work as described in L<EVP_KDF_CTX(3)/CONTROLS>.
=item B<EVP_KDF_CTRL_SET_SSHKDF_XCGHASH>
=item B<EVP_KDF_CTRL_SET_SSHKDF_SESSION_ID>
These controls expect two arguments: C<unsigned char *buffer>, C<size_t length>
They set the respective values to the first B<length> bytes of the buffer
B<buffer>. If a value is already set, the contents are replaced.
EVP_KDF_ctrl_str() takes two type strings for these controls:
=over 4
=item "xcghash"
=item "session_id"
The value string is used as is.
=item "hexxcghash"
=item "hexsession_id"
The value string is expected to be a hexadecimal number, which will be
decoded before being passed on as the control value.
=back
=item B<EVP_KDF_CTRL_SET_SSHKDF_TYPE>
This control expects one argument: C<int mode>
Sets the type for the SSHHKDF operation. There are six supported types:
=over 4
=item EVP_KDF_SSHKDF_TYPE_ININITAL_IV_CLI_TO_SRV
The Initial IV from client to server.
A single char of value 65 (ASCII char 'A').
=item EVP_KDF_SSHKDF_TYPE_ININITAL_IV_SRV_TO_CLI
The Initial IV from server to client
A single char of value 66 (ASCII char 'B').
=item EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_CLI_TO_SRV
The Encryption Key from client to server
A single char of value 67 (ASCII char 'C').
=item EVP_KDF_SSHKDF_TYPE_ENCRYPTION_KEY_SRV_TO_CLI
The Encryption Key from server to client
A single char of value 68 (ASCII char 'D').
=item EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_CLI_TO_SRV
The Integrity Key from client to server
A single char of value 69 (ASCII char 'E').
=item EVP_KDF_SSHKDF_TYPE_INTEGRITY_KEY_SRV_TO_CLI
The Integrity Key from client to server
A single char of value 70 (ASCII char 'F').
=back
EVP_KDF_ctrl_str() type string: "type"
The value is a string of length one character. The only valid values
are the numerical values of the ASCII caracters: "A" (65) to "F" (70).
=back
=head1 NOTES
A context for SSHKDF can be obtained by calling:
EVP_KDF_CTX *kctx = EVP_KDF_CTX_new_id(EVP_KDF_SSHKDF);
The output length of the SSHKDF derivation is specified via the C<keylen>
parameter to the L<EVP_KDF_derive(3)> function.
Since the SSHKDF output length is variable, calling L<EVP_KDF_size()>
to obtain the requisite length is not meaningful. The caller must
allocate a buffer of the desired length, and pass that buffer to the
L<EVP_KDF_derive(3)> function along with the desired length.
=head1 EXAMPLE
This example derives an 8 byte IV using SHA-256 with a 1K "key" and appropriate
"xcghash" and "session_id" values:
EVP_KDF_CTX *kctx;
unsigned char key[1024] = "01234...";
unsigned char xcghash[32] = "012345...";
unsigned char session_id[32] = "012345...";
unsigned char out[8];
size_t outlen = sizeof(out);
kctx = EVP_KDF_CTX_new_id(EVP_KDF_SSHKDF);
if (EVP_KDF_CTX_set_md(kctx, EVP_sha256()) <= 0)
/* Error */
if (EVP_KDF_CTX_set1_key(kctx, key, 1024) <= 0)
/* Error */
if (EVP_KDF_CTX_set1_sshkdf_xcghash(kctx, xcghash, 32) <= 0)
/* Error */
if (EVP_KDF_CTX_set1_sshkdf_session_id(kctx, session_id, 32) <= 0)
/* Error */
if (EVP_KDF_CTX_set_sshkdf_type(kctx,
EVP_KDF_SSHKDF_TYPE_ININITAL_IV_CLI_TO_SRV) <= 0)
/* Error */
if (EVP_KDF_derive(kctx, out, &outlen) <= 0)
/* Error */
=head1 CONFORMING TO
RFC 4253
=head1 SEE ALSO
L<EVP_KDF_CTX>,
L<EVP_KDF_CTX_new_id(3)>,
L<EVP_KDF_CTX_free(3)>,
L<EVP_KDF_ctrl(3)>,
L<EVP_KDF_size(3)>,
L<EVP_KDF_derive(3)>,
L<EVP_KDF_CTX(3)/CONTROLS>
=head1 COPYRIGHT
Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the OpenSSL license (the "License"). You may not use
this file except in compliance with the License. You can obtain a copy
in the file LICENSE in the source distribution or at
L<https://www.openssl.org/source/license.html>.
=cut
doc/man7/openssl-core.h.pod
+96
View File
@@ -0,0 +1,96 @@
=pod
=head1 NAME
openssl/core.h - OpenSSL Core types
=head1 SYNOPSIS
#include <openssl/core.h>
=head1 DESCRIPTION
The <openssl/core.h> header file defines a number of public types that
are used to communicate between the OpenSSL libraries and
implementation providers.
These types are designed to minimise the need for intimate knowledge
of internal structures between the OpenSSL libraries and the providers.
The types are:
=over 4
=item C<OSSL_DISPATCH>
This type is a tuple of function identity and function pointer.
Arrays of this type are passed between the OpenSSL libraries and the
providers to describe what functionality one side provides to the
other.
Arrays of this type must be terminated with a tuple having function
identity zero and function pointer C<NULL>.
The available function identities and corresponding function
signatures are defined by L<openssl-core_numbers.h(7)>.
Any function identity not recognised by the recipient of this type
will be ignored.
This ensures that providers built with one OpenSSL version in mind
will work together with any other OpenSSL version that supports this
mechanism.
=item C<OSSL_ITEM>
This type is a tuple of integer and pointer.
It's a generic type used as a generic descriptor, its exact meaning
being defined by how it's used.
Arrays of this type are passed between the OpenSSL libraries and the
providers, and must be terminated with a tuple where the integer is
zero and the pointer C<NULL>.
=item C<OSSL_ALGORITHM>
This type is a tuple of an algorithm name (string), a property
definition (string) and a dispatch table (array of C<OSSL_DISPATCH>).
Arrays of this type are passed on demand from the providers to the
OpenSSL libraries to describe what algorithms the providers provide
implementations of, and with what properties.
Arrays of this type must be terminated with a tuple having function
identity zero and function pointer C<NULL>.
The algorithm names and property definitions are defined by the
providers.
=item C<OSSL_PARAM>
This type is a structure that allows passing arbitrary object data
between two parties that have no or very little shared knowledge about
their respective internal structures for that object.
It's normally passed in arrays, where the array is terminated with an
element where all fields are zero (for non-pointers) or C<NULL> (for
pointers).
These arrays can be used both to set parameters for some object, and
to request parameters.
C<OSSL_PARAM> is further described in L<OSSL_PARAM(3)>
=back
=head1 SEE ALSO
L<openssl-core_numbers.h(7)>
=head1 HISTORY
The types described here were added in OpenSSL 3.0.
=head1 COPYRIGHT
Copyright 2019 The OpenSSL Project Authors. All Rights Reserved.
Licensed under the Apache License 2.0 (the "License"). You may not use
this file except in compliance with the License. You can obtain a copy
in the file LICENSE in the source distribution or at
L<https://www.openssl.org/source/license.html>.
=cut