Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/netbsd-6-0]: src/crypto/external/bsd/openssh Apply patch (requested by m...
details: https://anonhg.NetBSD.org/src/rev/a244d009095c
branches: netbsd-6-0
changeset: 775227:a244d009095c
user: snj <snj%NetBSD.org@localhost>
date: Tue Aug 15 04:53:00 2017 +0000
description:
Apply patch (requested by mrg in ticket #1468):
Update OpenSSH to 7.5.
diffstat:
crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 | 107 +
crypto/external/bsd/openssh/dist/PROTOCOL.key | 68 +
crypto/external/bsd/openssh/dist/PROTOCOL.krl | 169 +
crypto/external/bsd/openssh/dist/bcrypt_pbkdf.c | 174 +
crypto/external/bsd/openssh/dist/bitmap.c | 213 +
crypto/external/bsd/openssh/dist/bitmap.h | 58 +
crypto/external/bsd/openssh/dist/blf.h | 88 +
crypto/external/bsd/openssh/dist/blocks.c | 248 +
crypto/external/bsd/openssh/dist/blowfish.c | 695 ++
crypto/external/bsd/openssh/dist/chacha.c | 221 +
crypto/external/bsd/openssh/dist/chacha.h | 36 +
crypto/external/bsd/openssh/dist/cipher-aesctr.c | 78 +
crypto/external/bsd/openssh/dist/cipher-aesctr.h | 35 +
crypto/external/bsd/openssh/dist/cipher-chachapoly.c | 119 +
crypto/external/bsd/openssh/dist/cipher-chachapoly.h | 41 +
crypto/external/bsd/openssh/dist/crypto_api.h | 42 +
crypto/external/bsd/openssh/dist/digest-libc.c | 259 +
crypto/external/bsd/openssh/dist/digest-openssl.c | 189 +
crypto/external/bsd/openssh/dist/digest.h | 71 +
crypto/external/bsd/openssh/dist/ed25519.c | 145 +
crypto/external/bsd/openssh/dist/fe25519.c | 337 +
crypto/external/bsd/openssh/dist/fe25519.h | 70 +
crypto/external/bsd/openssh/dist/ge25519.c | 321 +
crypto/external/bsd/openssh/dist/ge25519.h | 43 +
crypto/external/bsd/openssh/dist/ge25519_base.data | 858 ++
crypto/external/bsd/openssh/dist/hash.c | 76 +
crypto/external/bsd/openssh/dist/hmac.c | 197 +
crypto/external/bsd/openssh/dist/hmac.h | 38 +
crypto/external/bsd/openssh/dist/kexc25519.c | 133 +
crypto/external/bsd/openssh/dist/kexc25519c.c | 170 +
crypto/external/bsd/openssh/dist/kexc25519s.c | 161 +
crypto/external/bsd/openssh/dist/krl.c | 1303 +++
crypto/external/bsd/openssh/dist/krl.h | 64 +
crypto/external/bsd/openssh/dist/moduli-gen/Makefile | 32 +
crypto/external/bsd/openssh/dist/moduli-gen/moduli-gen.sh | 33 +
crypto/external/bsd/openssh/dist/moduli-gen/moduli.2048 | 42 +
crypto/external/bsd/openssh/dist/moduli-gen/moduli.3072 | 35 +
crypto/external/bsd/openssh/dist/moduli-gen/moduli.4096 | 37 +
crypto/external/bsd/openssh/dist/moduli-gen/moduli.6144 | 33 +
crypto/external/bsd/openssh/dist/moduli-gen/moduli.7680 | 32 +
crypto/external/bsd/openssh/dist/moduli-gen/moduli.8192 | 41 +
crypto/external/bsd/openssh/dist/opacket.c | 322 +
crypto/external/bsd/openssh/dist/opacket.h | 164 +
crypto/external/bsd/openssh/dist/pfilter.c | 44 +
crypto/external/bsd/openssh/dist/pfilter.h | 3 +
crypto/external/bsd/openssh/dist/poly1305.c | 158 +
crypto/external/bsd/openssh/dist/poly1305.h | 22 +
crypto/external/bsd/openssh/dist/rijndael.c | 1126 +++
crypto/external/bsd/openssh/dist/rijndael.h | 44 +
crypto/external/bsd/openssh/dist/sandbox-pledge.c | 71 +
crypto/external/bsd/openssh/dist/sc25519.c | 308 +
crypto/external/bsd/openssh/dist/sc25519.h | 80 +
crypto/external/bsd/openssh/dist/smult_curve25519_ref.c | 268 +
crypto/external/bsd/openssh/dist/ssh-ed25519.c | 167 +
crypto/external/bsd/openssh/dist/ssh_api.c | 538 +
crypto/external/bsd/openssh/dist/ssh_api.h | 137 +
crypto/external/bsd/openssh/dist/sshbuf-getput-basic.c | 464 +
crypto/external/bsd/openssh/dist/sshbuf-getput-crypto.c | 218 +
crypto/external/bsd/openssh/dist/sshbuf-misc.c | 159 +
crypto/external/bsd/openssh/dist/sshbuf.c | 414 +
crypto/external/bsd/openssh/dist/sshbuf.h | 349 +
crypto/external/bsd/openssh/dist/ssherr.c | 148 +
crypto/external/bsd/openssh/dist/ssherr.h | 84 +
crypto/external/bsd/openssh/dist/sshkey.c | 3910 ++++++++++++
crypto/external/bsd/openssh/dist/sshkey.h | 221 +
crypto/external/bsd/openssh/dist/umac128.c | 6 +
crypto/external/bsd/openssh/dist/utf8.c | 290 +
crypto/external/bsd/openssh/dist/utf8.h | 25 +
crypto/external/bsd/openssh/dist/verify.c | 49 +
crypto/external/bsd/openssh/lib/_strtoi.h | 144 +
crypto/external/bsd/openssh/lib/consttime_memequal.c | 41 +
crypto/external/bsd/openssh/lib/explicit_memset.c | 34 +
crypto/external/bsd/openssh/lib/netbsd_ssh_compat.h | 22 +
crypto/external/bsd/openssh/lib/reallocarr.c | 97 +
crypto/external/bsd/openssh/lib/reallocarray.c | 55 +
crypto/external/bsd/openssh/lib/strtoi.c | 74 +
crypto/external/bsd/openssh/lib/strtonum.c | 66 +
crypto/external/bsd/openssh/openssh2netbsd | 38 +
78 files changed, 17472 insertions(+), 0 deletions(-)
diffs (truncated from 17784 to 300 lines):
diff -r f047386d2c46 -r a244d009095c crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/crypto/external/bsd/openssh/dist/PROTOCOL.chacha20poly1305 Tue Aug 15 04:53:00 2017 +0000
@@ -0,0 +1,107 @@
+This document describes the chacha20-poly1305%openssh.com@localhost authenticated
+encryption cipher supported by OpenSSH.
+
+Background
+----------
+
+ChaCha20 is a stream cipher designed by Daniel Bernstein and described
+in [1]. It operates by permuting 128 fixed bits, 128 or 256 bits of key,
+a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output
+is used as a keystream, with any unused bytes simply discarded.
+
+Poly1305[2], also by Daniel Bernstein, is a one-time Carter-Wegman MAC
+that computes a 128 bit integrity tag given a message and a single-use
+256 bit secret key.
+
+The chacha20-poly1305%openssh.com@localhost combines these two primitives into an
+authenticated encryption mode. The construction used is based on that
+proposed for TLS by Adam Langley in [3], but differs in the layout of
+data passed to the MAC and in the addition of encyption of the packet
+lengths.
+
+Negotiation
+-----------
+
+The chacha20-poly1305%openssh.com@localhost offers both encryption and
+authentication. As such, no separate MAC is required. If the
+chacha20-poly1305%openssh.com@localhost cipher is selected in key exchange,
+the offered MAC algorithms are ignored and no MAC is required to be
+negotiated.
+
+Detailed Construction
+---------------------
+
+The chacha20-poly1305%openssh.com@localhost cipher requires 512 bits of key
+material as output from the SSH key exchange. This forms two 256 bit
+keys (K_1 and K_2), used by two separate instances of chacha20.
+The first 256 bits consitute K_2 and the second 256 bits become
+K_1.
+
+The instance keyed by K_1 is a stream cipher that is used only
+to encrypt the 4 byte packet length field. The second instance,
+keyed by K_2, is used in conjunction with poly1305 to build an AEAD
+(Authenticated Encryption with Associated Data) that is used to encrypt
+and authenticate the entire packet.
+
+Two separate cipher instances are used here so as to keep the packet
+lengths confidential but not create an oracle for the packet payload
+cipher by decrypting and using the packet length prior to checking
+the MAC. By using an independently-keyed cipher instance to encrypt the
+length, an active attacker seeking to exploit the packet input handling
+as a decryption oracle can learn nothing about the payload contents or
+its MAC (assuming key derivation, ChaCha20 and Poly1305 are secure).
+
+The AEAD is constructed as follows: for each packet, generate a Poly1305
+key by taking the first 256 bits of ChaCha20 stream output generated
+using K_2, an IV consisting of the packet sequence number encoded as an
+uint64 under the SSH wire encoding rules and a ChaCha20 block counter of
+zero. The K_2 ChaCha20 block counter is then set to the little-endian
+encoding of 1 (i.e. {1, 0, 0, 0, 0, 0, 0, 0}) and this instance is used
+for encryption of the packet payload.
+
+Packet Handling
+---------------
+
+When receiving a packet, the length must be decrypted first. When 4
+bytes of ciphertext length have been received, they may be decrypted
+using the K_1 key, a nonce consisting of the packet sequence number
+encoded as a uint64 under the usual SSH wire encoding and a zero block
+counter to obtain the plaintext length.
+
+Once the entire packet has been received, the MAC MUST be checked
+before decryption. A per-packet Poly1305 key is generated as described
+above and the MAC tag calculated using Poly1305 with this key over the
+ciphertext of the packet length and the payload together. The calculated
+MAC is then compared in constant time with the one appended to the
+packet and the packet decrypted using ChaCha20 as described above (with
+K_2, the packet sequence number as nonce and a starting block counter of
+1).
+
+To send a packet, first encode the 4 byte length and encrypt it using
+K_1. Encrypt the packet payload (using K_2) and append it to the
+encrypted length. Finally, calculate a MAC tag and append it.
+
+Rekeying
+--------
+
+ChaCha20 must never reuse a {key, nonce} for encryption nor may it be
+used to encrypt more than 2^70 bytes under the same {key, nonce}. The
+SSH Transport protocol (RFC4253) recommends a far more conservative
+rekeying every 1GB of data sent or received. If this recommendation
+is followed, then chacha20-poly1305%openssh.com@localhost requires no special
+handling in this area.
+
+References
+----------
+
+[1] "ChaCha, a variant of Salsa20", Daniel Bernstein
+ http://cr.yp.to/chacha/chacha-20080128.pdf
+
+[2] "The Poly1305-AES message-authentication code", Daniel Bernstein
+ http://cr.yp.to/mac/poly1305-20050329.pdf
+
+[3] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley
+ http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
+
+$OpenBSD: PROTOCOL.chacha20poly1305,v 1.3 2016/05/03 13:10:24 djm Exp $
+
diff -r f047386d2c46 -r a244d009095c crypto/external/bsd/openssh/dist/PROTOCOL.key
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/crypto/external/bsd/openssh/dist/PROTOCOL.key Tue Aug 15 04:53:00 2017 +0000
@@ -0,0 +1,68 @@
+This document describes the private key format for OpenSSH.
+
+1. Overall format
+
+The key consists of a header, a list of public keys, and
+an encrypted list of matching private keys.
+
+#define AUTH_MAGIC "openssh-key-v1"
+
+ byte[] AUTH_MAGIC
+ string ciphername
+ string kdfname
+ string kdfoptions
+ int number of keys N
+ string publickey1
+ string publickey2
+ ...
+ string publickeyN
+ string encrypted, padded list of private keys
+
+2. KDF options for kdfname "bcrypt"
+
+The options:
+
+ string salt
+ uint32 rounds
+
+are concatenated and represented as a string.
+
+3. Unencrypted list of N private keys
+
+The list of privatekey/comment pairs is padded with the
+bytes 1, 2, 3, ... until the total length is a multiple
+of the cipher block size.
+
+ uint32 checkint
+ uint32 checkint
+ string privatekey1
+ string comment1
+ string privatekey2
+ string comment2
+ ...
+ string privatekeyN
+ string commentN
+ char 1
+ char 2
+ char 3
+ ...
+ char padlen % 255
+
+Before the key is encrypted, a random integer is assigned
+to both checkint fields so successful decryption can be
+quickly checked by verifying that both checkint fields
+hold the same value.
+
+4. Encryption
+
+The KDF is used to derive a key, IV (and other values required by
+the cipher) from the passphrase. These values are then used to
+encrypt the unencrypted list of private keys.
+
+5. No encryption
+
+For unencrypted keys the cipher "none" and the KDF "none"
+are used with empty passphrases. The options if the KDF "none"
+are the empty string.
+
+$OpenBSD: PROTOCOL.key,v 1.1 2013/12/06 13:34:54 markus Exp $
diff -r f047386d2c46 -r a244d009095c crypto/external/bsd/openssh/dist/PROTOCOL.krl
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/crypto/external/bsd/openssh/dist/PROTOCOL.krl Tue Aug 15 04:53:00 2017 +0000
@@ -0,0 +1,169 @@
+This describes the key/certificate revocation list format for OpenSSH.
+
+1. Overall format
+
+The KRL consists of a header and zero or more sections. The header is:
+
+#define KRL_MAGIC 0x5353484b524c0a00ULL /* "SSHKRL\n\0" */
+#define KRL_FORMAT_VERSION 1
+
+ uint64 KRL_MAGIC
+ uint32 KRL_FORMAT_VERSION
+ uint64 krl_version
+ uint64 generated_date
+ uint64 flags
+ string reserved
+ string comment
+
+Where "krl_version" is a version number that increases each time the KRL
+is modified, "generated_date" is the time in seconds since 1970-01-01
+00:00:00 UTC that the KRL was generated, "comment" is an optional comment
+and "reserved" an extension field whose contents are currently ignored.
+No "flags" are currently defined.
+
+Following the header are zero or more sections, each consisting of:
+
+ byte section_type
+ string section_data
+
+Where "section_type" indicates the type of the "section_data". An exception
+to this is the KRL_SECTION_SIGNATURE section, that has a slightly different
+format (see below).
+
+The available section types are:
+
+#define KRL_SECTION_CERTIFICATES 1
+#define KRL_SECTION_EXPLICIT_KEY 2
+#define KRL_SECTION_FINGERPRINT_SHA1 3
+#define KRL_SECTION_SIGNATURE 4
+
+2. Certificate section
+
+These sections use type KRL_SECTION_CERTIFICATES to revoke certificates by
+serial number or key ID. The consist of the CA key that issued the
+certificates to be revoked and a reserved field whose contents is currently
+ignored.
+
+ string ca_key
+ string reserved
+
+Where "ca_key" is the standard SSH wire serialisation of the CA's
+public key. Alternately, "ca_key" may be an empty string to indicate
+the certificate section applies to all CAs (this is most useful when
+revoking key IDs).
+
+Followed by one or more sections:
+
+ byte cert_section_type
+ string cert_section_data
+
+The certificate section types are:
+
+#define KRL_SECTION_CERT_SERIAL_LIST 0x20
+#define KRL_SECTION_CERT_SERIAL_RANGE 0x21
+#define KRL_SECTION_CERT_SERIAL_BITMAP 0x22
+#define KRL_SECTION_CERT_KEY_ID 0x23
+
+2.1 Certificate serial list section
+
+This section is identified as KRL_SECTION_CERT_SERIAL_LIST. It revokes
+certificates by listing their serial numbers. The cert_section_data in this
+case contains:
+
+ uint64 revoked_cert_serial
+ uint64 ...
+
+This section may appear multiple times.
+
+2.2. Certificate serial range section
+
+These sections use type KRL_SECTION_CERT_SERIAL_RANGE and hold
+a range of serial numbers of certificates:
+
+ uint64 serial_min
+ uint64 serial_max
+
+All certificates in the range serial_min <= serial <= serial_max are
+revoked.
+
+This section may appear multiple times.
+
+2.3. Certificate serial bitmap section
+
+Bitmap sections use type KRL_SECTION_CERT_SERIAL_BITMAP and revoke keys
+by listing their serial number in a bitmap.
+
+ uint64 serial_offset
+ mpint revoked_keys_bitmap
+
+A bit set at index N in the bitmap corresponds to revocation of a keys with
+serial number (serial_offset + N).
+
+This section may appear multiple times.
+
+2.4. Revoked key ID sections
+
+KRL_SECTION_CERT_KEY_ID sections revoke particular certificate "key
+ID" strings. This may be useful in revoking all certificates
+associated with a particular identity, e.g. a host or a user.
+
+ string key_id[0]
+ ...
+
+This section must contain at least one "key_id". This section may appear
Home |
Main Index |
Thread Index |
Old Index