Skip to content

Commit 92eae9e

Browse files
arif-pragmasysarif-pragmasys
committed
7.1p1 original test files
1 parent 720b362 commit 92eae9e

File tree

222 files changed

+11941
-669
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

222 files changed

+11941
-669
lines changed

‎.cvsignore

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,28 @@
1+
*.0
2+
*.out
3+
Makefile
4+
autom4te.cache
5+
buildit.sh
6+
buildpkg.sh
7+
config.cache
8+
config.h
9+
config.h.in
10+
config.log
11+
config.status
12+
configure
13+
openssh.xml
14+
opensshd.init
15+
scp
16+
sftp
17+
sftp-server
18+
ssh
19+
ssh-add
20+
ssh-agent
21+
ssh-keygen
22+
ssh-keyscan
23+
ssh-keysign
24+
ssh-pkcs11-helper
25+
sshd
26+
stamp-h.in
27+
survey
28+
survey.sh

‎PROTOCOL.chacha20poly1305

Lines changed: 105 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,105 @@
1+
This document describes the [email protected] authenticated
2+
encryption cipher supported by OpenSSH.
3+
4+
Background
5+
----------
6+
7+
ChaCha20 is a stream cipher designed by Daniel Bernstein and described
8+
in [1]. It operates by permuting 128 fixed bits, 128 or 256 bits of key,
9+
a 64 bit nonce and a 64 bit counter into 64 bytes of output. This output
10+
is used as a keystream, with any unused bytes simply discarded.
11+
12+
Poly1305[2], also by Daniel Bernstein, is a one-time Carter-Wegman MAC
13+
that computes a 128 bit integrity tag given a message and a single-use
14+
256 bit secret key.
15+
16+
The [email protected] combines these two primitives into an
17+
authenticated encryption mode. The construction used is based on that
18+
proposed for TLS by Adam Langley in [3], but differs in the layout of
19+
data passed to the MAC and in the addition of encyption of the packet
20+
lengths.
21+
22+
Negotiation
23+
-----------
24+
25+
The [email protected] offers both encryption and
26+
authentication. As such, no separate MAC is required. If the
27+
[email protected] cipher is selected in key exchange,
28+
the offered MAC algorithms are ignored and no MAC is required to be
29+
negotiated.
30+
31+
Detailed Construction
32+
---------------------
33+
34+
The [email protected] cipher requires 512 bits of key
35+
material as output from the SSH key exchange. This forms two 256 bit
36+
keys (K_1 and K_2), used by two separate instances of chacha20.
37+
38+
The instance keyed by K_1 is a stream cipher that is used only
39+
to encrypt the 4 byte packet length field. The second instance,
40+
keyed by K_2, is used in conjunction with poly1305 to build an AEAD
41+
(Authenticated Encryption with Associated Data) that is used to encrypt
42+
and authenticate the entire packet.
43+
44+
Two separate cipher instances are used here so as to keep the packet
45+
lengths confidential but not create an oracle for the packet payload
46+
cipher by decrypting and using the packet length prior to checking
47+
the MAC. By using an independently-keyed cipher instance to encrypt the
48+
length, an active attacker seeking to exploit the packet input handling
49+
as a decryption oracle can learn nothing about the payload contents or
50+
its MAC (assuming key derivation, ChaCha20 and Poly1305 are secure).
51+
52+
The AEAD is constructed as follows: for each packet, generate a Poly1305
53+
key by taking the first 256 bits of ChaCha20 stream output generated
54+
using K_2, an IV consisting of the packet sequence number encoded as an
55+
uint64 under the SSH wire encoding rules and a ChaCha20 block counter of
56+
zero. The K_2 ChaCha20 block counter is then set to the little-endian
57+
encoding of 1 (i.e. {1, 0, 0, 0, 0, 0, 0, 0}) and this instance is used
58+
for encryption of the packet payload.
59+
60+
Packet Handling
61+
---------------
62+
63+
When receiving a packet, the length must be decrypted first. When 4
64+
bytes of ciphertext length have been received, they may be decrypted
65+
using the K_1 key, a nonce consisting of the packet sequence number
66+
encoded as a uint64 under the usual SSH wire encoding and a zero block
67+
counter to obtain the plaintext length.
68+
69+
Once the entire packet has been received, the MAC MUST be checked
70+
before decryption. A per-packet Poly1305 key is generated as described
71+
above and the MAC tag calculated using Poly1305 with this key over the
72+
ciphertext of the packet length and the payload together. The calculated
73+
MAC is then compared in constant time with the one appended to the
74+
packet and the packet decrypted using ChaCha20 as described above (with
75+
K_2, the packet sequence number as nonce and a starting block counter of
76+
1).
77+
78+
To send a packet, first encode the 4 byte length and encrypt it using
79+
K_1. Encrypt the packet payload (using K_2) and append it to the
80+
encrypted length. Finally, calculate a MAC tag and append it.
81+
82+
Rekeying
83+
--------
84+
85+
ChaCha20 must never reuse a {key, nonce} for encryption nor may it be
86+
used to encrypt more than 2^70 bytes under the same {key, nonce}. The
87+
SSH Transport protocol (RFC4253) recommends a far more conservative
88+
rekeying every 1GB of data sent or received. If this recommendation
89+
is followed, then [email protected] requires no special
90+
handling in this area.
91+
92+
References
93+
----------
94+
95+
[1] "ChaCha, a variant of Salsa20", Daniel Bernstein
96+
http://cr.yp.to/chacha/chacha-20080128.pdf
97+
98+
[2] "The Poly1305-AES message-authentication code", Daniel Bernstein
99+
http://cr.yp.to/mac/poly1305-20050329.pdf
100+
101+
[3] "ChaCha20 and Poly1305 based Cipher Suites for TLS", Adam Langley
102+
http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-03
103+
104+
$OpenBSD: PROTOCOL.chacha20poly1305,v 1.2 2013/12/02 02:50:27 djm Exp $
105+

‎PROTOCOL.key

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
This document describes the private key format for OpenSSH.
2+
3+
1. Overall format
4+
5+
The key consists of a header, a list of public keys, and
6+
an encrypted list of matching private keys.
7+
8+
#define AUTH_MAGIC "openssh-key-v1"
9+
10+
byte[] AUTH_MAGIC
11+
string ciphername
12+
string kdfname
13+
string kdfoptions
14+
int number of keys N
15+
string publickey1
16+
string publickey2
17+
...
18+
string publickeyN
19+
string encrypted, padded list of private keys
20+
21+
2. KDF options for kdfname "bcrypt"
22+
23+
The options:
24+
25+
string salt
26+
uint32 rounds
27+
28+
are concatenated and represented as a string.
29+
30+
3. Unencrypted list of N private keys
31+
32+
The list of privatekey/comment pairs is padded with the
33+
bytes 1, 2, 3, ... until the total length is a multiple
34+
of the cipher block size.
35+
36+
uint32 checkint
37+
uint32 checkint
38+
string privatekey1
39+
string comment1
40+
string privatekey2
41+
string comment2
42+
...
43+
string privatekeyN
44+
string commentN
45+
char 1
46+
char 2
47+
char 3
48+
...
49+
char padlen % 255
50+
51+
Before the key is encrypted, a random integer is assigned
52+
to both checkint fields so successful decryption can be
53+
quickly checked by verifying that both checkint fields
54+
hold the same value.
55+
56+
4. Encryption
57+
58+
The KDF is used to derive a key, IV (and other values required by
59+
the cipher) from the passphrase. These values are then used to
60+
encrypt the unencrypted list of private keys.
61+
62+
5. No encryption
63+
64+
For unencrypted keys the cipher "none" and the KDF "none"
65+
are used with empty passphrases. The options if the KDF "none"
66+
are the empty string.
67+
68+
$OpenBSD: PROTOCOL.key,v 1.1 2013/12/06 13:34:54 markus Exp $

‎PROTOCOL.krl

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
This describes the key/certificate revocation list format for OpenSSH.
2+
3+
1. Overall format
4+
5+
The KRL consists of a header and zero or more sections. The header is:
6+
7+
#define KRL_MAGIC 0x5353484b524c0a00ULL /* "SSHKRL\n\0" */
8+
#define KRL_FORMAT_VERSION 1
9+
10+
uint64 KRL_MAGIC
11+
uint32 KRL_FORMAT_VERSION
12+
uint64 krl_version
13+
uint64 generated_date
14+
uint64 flags
15+
string reserved
16+
string comment
17+
18+
Where "krl_version" is a version number that increases each time the KRL
19+
is modified, "generated_date" is the time in seconds since 1970-01-01
20+
00:00:00 UTC that the KRL was generated, "comment" is an optional comment
21+
and "reserved" an extension field whose contents are currently ignored.
22+
No "flags" are currently defined.
23+
24+
Following the header are zero or more sections, each consisting of:
25+
26+
byte section_type
27+
string section_data
28+
29+
Where "section_type" indicates the type of the "section_data". An exception
30+
to this is the KRL_SECTION_SIGNATURE section, that has a slightly different
31+
format (see below).
32+
33+
The available section types are:
34+
35+
#define KRL_SECTION_CERTIFICATES 1
36+
#define KRL_SECTION_EXPLICIT_KEY 2
37+
#define KRL_SECTION_FINGERPRINT_SHA1 3
38+
#define KRL_SECTION_SIGNATURE 4
39+
40+
2. Certificate section
41+
42+
These sections use type KRL_SECTION_CERTIFICATES to revoke certificates by
43+
serial number or key ID. The consist of the CA key that issued the
44+
certificates to be revoked and a reserved field whose contents is currently
45+
ignored.
46+
47+
string ca_key
48+
string reserved
49+
50+
Where "ca_key" is the standard SSH wire serialisation of the CA's
51+
public key. Alternately, "ca_key" may be an empty string to indicate
52+
the certificate section applies to all CAs (this is most useful when
53+
revoking key IDs).
54+
55+
Followed by one or more sections:
56+
57+
byte cert_section_type
58+
string cert_section_data
59+
60+
The certificate section types are:
61+
62+
#define KRL_SECTION_CERT_SERIAL_LIST 0x20
63+
#define KRL_SECTION_CERT_SERIAL_RANGE 0x21
64+
#define KRL_SECTION_CERT_SERIAL_BITMAP 0x22
65+
#define KRL_SECTION_CERT_KEY_ID 0x23
66+
67+
2.1 Certificate serial list section
68+
69+
This section is identified as KRL_SECTION_CERT_SERIAL_LIST. It revokes
70+
certificates by listing their serial numbers. The cert_section_data in this
71+
case contains:
72+
73+
uint64 revoked_cert_serial
74+
uint64 ...
75+
76+
This section may appear multiple times.
77+
78+
2.2. Certificate serial range section
79+
80+
These sections use type KRL_SECTION_CERT_SERIAL_RANGE and hold
81+
a range of serial numbers of certificates:
82+
83+
uint64 serial_min
84+
uint64 serial_max
85+
86+
All certificates in the range serial_min <= serial <= serial_max are
87+
revoked.
88+
89+
This section may appear multiple times.
90+
91+
2.3. Certificate serial bitmap section
92+
93+
Bitmap sections use type KRL_SECTION_CERT_SERIAL_BITMAP and revoke keys
94+
by listing their serial number in a bitmap.
95+
96+
uint64 serial_offset
97+
mpint revoked_keys_bitmap
98+
99+
A bit set at index N in the bitmap corresponds to revocation of a keys with
100+
serial number (serial_offset + N).
101+
102+
This section may appear multiple times.
103+
104+
2.4. Revoked key ID sections
105+
106+
KRL_SECTION_CERT_KEY_ID sections revoke particular certificate "key
107+
ID" strings. This may be useful in revoking all certificates
108+
associated with a particular identity, e.g. a host or a user.
109+
110+
string key_id[0]
111+
...
112+
113+
This section must contain at least one "key_id". This section may appear
114+
multiple times.
115+
116+
3. Explicit key sections
117+
118+
These sections, identified as KRL_SECTION_EXPLICIT_KEY, revoke keys
119+
(not certificates). They are less space efficient than serial numbers,
120+
but are able to revoke plain keys.
121+
122+
string public_key_blob[0]
123+
....
124+
125+
This section must contain at least one "public_key_blob". The blob
126+
must be a raw key (i.e. not a certificate).
127+
128+
This section may appear multiple times.
129+
130+
4. SHA1 fingerprint sections
131+
132+
These sections, identified as KRL_SECTION_FINGERPRINT_SHA1, revoke
133+
plain keys (i.e. not certificates) by listing their SHA1 hashes:
134+
135+
string public_key_hash[0]
136+
....
137+
138+
This section must contain at least one "public_key_hash". The hash blob
139+
is obtained by taking the SHA1 hash of the public key blob. Hashes in
140+
this section must appear in numeric order, treating each hash as a big-
141+
endian integer.
142+
143+
This section may appear multiple times.
144+
145+
5. KRL signature sections
146+
147+
The KRL_SECTION_SIGNATURE section serves a different purpose to the
148+
preceeding ones: to provide cryptographic authentication of a KRL that
149+
is retrieved over a channel that does not provide integrity protection.
150+
Its format is slightly different to the previously-described sections:
151+
in order to simplify the signature generation, it includes as a "body"
152+
two string components instead of one.
153+
154+
byte KRL_SECTION_SIGNATURE
155+
string signature_key
156+
string signature
157+
158+
The signature is calculated over the entire KRL from the KRL_MAGIC
159+
to this subsection's "signature_key", including both and using the
160+
signature generation rules appropriate for the type of "signature_key".
161+
162+
This section must appear last in the KRL. If multiple signature sections
163+
appear, they must appear consecutively at the end of the KRL file.
164+
165+
Implementations that retrieve KRLs over untrusted channels must verify
166+
signatures. Signature sections are optional for KRLs distributed by
167+
trusted means.
168+
169+
$OpenBSD: PROTOCOL.krl,v 1.3 2015/01/30 01:10:33 djm Exp $

0 commit comments

Comments
 (0)