Talk:Message Stream Encryption

From VuzeWiki
Jump to: navigation, search

current concerns[edit]

  • a fixed IV should be added to the SHA1(S)
  • breakoff conditions and timeouts should be added since any incoming stream can be misconceived as a DH exchange


async DH exchange[edit]

comparing sequential and simultaneous DH, assuming constant 200ms latency in both directions and infinite bandwidth:

sequential:

  0ms A->B integer A
200ms B->A integer B+encrypted(supported methods)
400ms A->B encrypted(chosen methods)+payload
600ms B->A payload

simultanoues:


  0ms A->B integer A
  0ms B->A integer B
200ms A->B encrypted(supported methods)
200ms B->A encrypted(supported methods)
400ms A->B payload
400ms B->A payload

speed-exchange:

  0ms A->B integer A + padding1
  0ms B->A integer B + padding2
200ms A+B calculate S
200ms A->B hash("A"+S)+encrypted_withStandard-Algo(supported methods+payload)
200ms B->A hash("B"+S)+encrypted_withStandard-Algo(supported methods+payload)
400ms A+B calculate the minimal, mutually supported method from the bitfields
400ms A->B encrypted_withHandshaked-Algo(payload)
400ms B->A encrypted_withHandshaked-Algo(payload)


speed-exchange with sender-first (compatibility for legacy connections):

  0ms A->B integer A + padding1
200ms B->A integer B + padding2
200ms B calculates S
200ms B->A hash("B"+S)+encrypted_withStandard-Algo(supported methods+payload)
400ms A calculates S
400ms A->B hash("A"+S)+encrypted_withStandard-Algo(supported methods+payload)
400ms A calculates the minimal, mutually supported method from the bitfields
400ms A->B encrypted_withHandshaked-Algo(payload)
600ms B calculates the minimal, mutually supported method from the bitfields
600ms B->A encrypted_withHandshaked-Algo(payload)

Note: from the implementation perspective it is exacly the same, just that the peers don't operate isochronous and thus one of them lags behind.

--The8472 19:00, 20 January 2006 (GMT)

Suggestion for alternative implementation (by Ludde/uau/The_8472)[edit]


The protocol has a notion of 'initial data'. This is data that is sent before the encryption handshake
is completed for optimization purposes (It avoids waiting for data to read). It's just a part of the stream
sent befor the handshake is done.


Diffie hellman method:
----------------------

The entire handshake is in big-endian.
The crypto handshake is transparent to the next upper protocol, thus the payload endianness doesn't matter.


Prime P is a 768 bit safe prime, "0xFFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9A63A36210000000000090563"
Generator G is "2"

Xa and Xb are a variable size random integers. 
They are the private key for each side and have to be discarded after the DH handshake is done.
Minimum length is 128 bit. Anything beyond 180 bit is not believed to add any further security and only increases the necessary calculation time.
You should use a length of 160bits whenever possible, lower values may be used when CPU time is scarce.



Pubkey of A: Ya = (G^Xa) mod P
Pubkey of B: Yb = (G^Xb) mod P

DH secret: S = (Ya^Xb) mod P = (Yb^Xa) mod P

P, S, Ya and Yb are 768bits length



PadA, PadB: Random data with a random length of 0 to 512 bytes each
PadC, PadD: Arbitrary data with a length of 0 to 512 bytes, can be used to extend the crypto handshake in future versions.
Current implementations may choose to set them to 0-length. For padding-only usage in the current version they should be zeroed.

len(X) specifies the length of X in 2 bytes.
Thus the maximum length that can be specified is 65535 bytes, this is important for the IA block.


SKEY = Stream Identifier/Shared secret used to drop connections early if we don't have a
matching stream. It's additionally used to harden the protocol against MITM attacks and portscanning.
Protocols w/o unique stream properties may use a constant.

Note: For BitTorrent, the SKEY should be the torrent info hash.


IA = initial payload data from A
may be 0-sized if you want to wait for the encryption negotation.

A may buffer up to 65535 bytes before or during the DH handshake to append it to the 3rd step.
IA is considered as atomic and thus an implementation may not expect that anything is handed
to the upper layer before IA is completely transmitted. Thus no blocking operations may occur
within IA.

Note, Example for Bittorrent:
 After \19Bittorrent protocol + the BT handshake a block occurs since A waits for B to send his handshake
 before A continues to send his bitfield, thus IA can only include the prefix + the bt handshake
 but not the bitfield


ENCRYPT() is RC4, that uses one of the following keys to send data:
"HASH('keyA', S, SKEY)" if you're A
"HASH('keyB', S, SKEY)" if you're B
The first 1024 bytes of the RC4 output are discarded.
consecutive calls to ENCRYPT() by one side continue the encryption stream (no reinitialization, no keychange).
They are only used to distinguish semantically seperate content. 

ENCRYPT2() is the negotiated crypto method.
Current options are:
 0x01 Plaintext. After the specified length (see IA/IB) each side sends unencrypted payload
 0x02 RC4-128. The ENCRYPT() RC4 encoding is continued (no reinitialization, no keychange)

HASH() is SHA1 binary output (20 bytes)


VC is a verification constant that is used to verify whether the other side knows S
and SKEY and thus defeats replay attacks of the SKEY hash.
As of this version VC is a String of 8 bytes set to 0x00.


crypto_provide is a 32bit bitfield. As of now 0x01 = plaintext, 0x02 = RC4. The remaining bits are reserved for future use.
A peer may choose only to provide higher encryption levels e.g. if  plaintext isn't sufficient for it's security needs.

crypto_select is a 32bit integer with a set bit corresponding to a set bit in crypto_provide.

Bits with an unknown meaning in crypto_provide and crypto_select should be ignored as they might be used in future versions.


A is the initiator of the underlying transport (e.g. a TCP connection)

The handshake is seperated into 5 blocking steps.

1 A->B: Diffie Hellman Ya, PadA
2 B->A: Diffie Hellman Yb, PadB
3 A->B: HASH('req1', S), HASH('req2', SKEY) xor HASH('req3', S), ENCRYPT(VC, crypto_provide, len(PadC), PadC, len(IA)), ENCRYPT(IA)
4 B->A: ENCRYPT(VC, crypto_select, len(padD), padD), ENCRYPT2(Payload Stream)
5 A->B: ENCRYPT2(Payload Stream)


Since the length of PadA and PadB are unknown
B will be able to resynchronize on HASH('req1', S)
A will be able to resynchronize on ENCRYPT(VC)


Optional early termination conditions (should verified before the indicated step is started).
If a fail-fast behavior is prefered those conditions can be used to disconnect the peer immediately.
If less recognizable patterns are preferred a peer may wait and disconnect at a later point.
If any of these conditions are met the handshake can be considered as invalid.

2 (termination by B)
if A sent less than 64 Bytes within 30 seconds
if A sent more than 576 bytes 

3 (termination by A)
if B sent less than 64 Bytes within 30 seconds
if B sent more than 576 bytes

4 (termination by B)
if A didn't send the correct S hash within 596 bytes after the connection start (synchronisation point)
if A didn't send a supported SKEY hash after the S hash
if VC can't be decoded correctly after the SKEY hash
if none of the crypto_provide options are supported or the bitfield is zeroed
from here on it's up to the next protocol layer to terminate the connection

5 (termination by A)
if VC can't be decoded correctly within 584 bytes after the connection start (synchronisation point)
if the selected crypto method wasn't provided
from here on it's up to the next protocol layer to terminate the connection


SS-only handshake hidden as wiki comment: