⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 message stream encryption.mht

📁 关于BT的协议文档
💻 MHT
📖 第 1 页 / 共 5 页
字号:
From: <由 Microsoft Internet Explorer 5 保存>
Subject: Message Stream Encryption - AzureusWiki
Date: Mon, 23 Apr 2007 11:51:51 +0800
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="----=_NextPart_000_000A_01C7859D.C7CB7D30"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C7859D.C7CB7D30
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.azureuswiki.com/index.php/Message_Stream_Encryption

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" =
"http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML lang=3Den dir=3Dltr xml:lang=3D"en"=20
xmlns=3D"http://www.w3.org/1999/xhtml"><HEAD><TITLE>Message Stream =
Encryption - AzureusWiki</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META=20
content=3D"Message Stream Encryption,Avoid traffic shaping,Azureus =
messaging protocol,Bad ISPs,Distributed tracker,Enhanced messaging =
protocol,Peer Exchange,Secure Torrents"=20
name=3Dkeywords><LINK href=3D"/favicon.ico" rel=3D"shortcut icon"><LINK=20
href=3D"/index.php/AzureusWiki:Copyright" rel=3Dcopyright>
<STYLE type=3Dtext/css media=3Dscreen,projection>@import url( =
/skins/monobook/main.css?7 );
</STYLE>
<LINK media=3Dprint =
href=3D"http://www.azureuswiki.com/skins/common/commonPrint.css"=20
type=3Dtext/css rel=3Dstylesheet><!--[if lt IE 5.5000]><style =
type=3D"text/css">@import =
"/skins/monobook/IE50Fixes.css";</style><![endif]--><!--[if IE =
5.5000]><style type=3D"text/css">@import =
"/skins/monobook/IE55Fixes.css";</style><![endif]--><!--[if IE 6]>
<STYLE type=3Dtext/css>@import url( /skins/monobook/IE60Fixes.css );
</STYLE>
<![endif]--><!--[if IE 7]><style type=3D"text/css">@import =
"/skins/monobook/IE70Fixes.css?1";</style><![endif]--><!--[if lt IE 7]>
<SCRIPT src=3D"http://www.azureuswiki.com/skins/common/IEFixes.js"=20
type=3Dtext/javascript></SCRIPT>

<META http-equiv=3Dimagetoolbar content=3Dno><![endif]-->
<SCRIPT=20
type=3Dtext/javascript>var skin =3D 'monobook';var stylepath =3D =
'/skins';</SCRIPT>

<SCRIPT src=3D"http://www.azureuswiki.com/skins/common/wikibits.js"=20
type=3Dtext/javascript><!-- wikibits js --></SCRIPT>

<SCRIPT=20
src=3D"http://www.azureuswiki.com/index.php?title=3D-&amp;action=3Draw&am=
p;gen=3Djs"=20
type=3Dtext/javascript><!-- site js --></SCRIPT>

<STYLE type=3Dtext/css>@import url( =
/index.php?title=3DMediaWiki:Common.css&action=3Draw&ctype=3Dtext/css&sma=
xage=3D18000 );
@import url( =
/index.php?title=3DMediaWiki:Monobook.css&action=3Draw&ctype=3Dtext/css&s=
maxage=3D18000 );
@import url( /index.php?title=3D-&action=3Draw&gen=3Dcss&maxage=3D18000 =
);
</STYLE>
<!-- Head Scripts -->
<META content=3D"MSHTML 6.00.2900.3059" name=3DGENERATOR></HEAD>
<BODY class=3D"ns-0 ltr">
<DIV id=3DglobalWrapper>
<DIV id=3Dcolumn-content>
<DIV id=3Dcontent><A id=3Dtop name=3Dtop></A>
<H1 class=3DfirstHeading>Message Stream Encryption</H1>
<DIV id=3DbodyContent>
<H3 id=3DsiteSub>From AzureusWiki</H3>
<DIV id=3DcontentSub></DIV>
<DIV id=3Djump-to-nav>Jump to: <A=20
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#co=
lumn-one">navigation</A>,=20
<A=20
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#se=
archInput">search</A></DIV><!-- start content -->
<P><I>Note:</I> This is the <B>Message Stream Encryption</B> =
specification, see=20
<A title=3D"Avoid traffic shaping"=20
href=3D"http://www.azureuswiki.com/index.php/Avoid_traffic_shaping">Avoid=
 traffic=20
shaping</A> for Azureus specific setup instructions and documentation. =
</P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Protocol Objectives"=20
href=3D"http://www.azureuswiki.com/index.php?title=3DMessage_Stream_Encry=
ption&amp;action=3Dedit&amp;section=3D1">edit</A>]</DIV><A=20
name=3DProtocol_Objectives></A>
<H2>Protocol Objectives</H2>
<P>The following encapsulation protocol is designed to provide a =
completely=20
random-looking header and (optionally) payload to avoid passive protocol =

identification and traffic shaping. When it is used with the stronger =
encryption=20
mode (<A class=3Dextiw title=3Dwikipedia:RC4=20
href=3D"http://en.wikipedia.org/wiki/RC4">RC4</A>) it also provides =
reasonable=20
security for the encapsulated content against passive eavesdroppers. =
</P>
<P>It is a 3-way handshake where the initiating client can directly =
append its=20
payload after his 2nd step (which globally is the 3rd). The responding =
client=20
has to send one step (globally the 2nd) of the handshake and then wait =
until the=20
initiating client has completed its 2nd step to send payload. </P>
<P>To achieve complete randomness from the first byte on the protocol =
uses a <A=20
class=3Dextiw title=3Dwikipedia:Diffie-Hellman_key_exchange=20
href=3D"http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange">D-H =
key=20
exchange</A> which uses large random Integers by design. The 2nd phase - =
the=20
payload encryption negotiation - is itself encrypted and thus =
approximately=20
random too. To avoid simple length-pattern detections various paddings =
have been=20
added to each phase. </P>
<P>This encapsulation protocol is independent of the encapsulated =
content, but=20
is intended to be used with the BitTorrent Protocol, the <A=20
title=3D"Azureus messaging protocol"=20
href=3D"http://www.azureuswiki.com/index.php/Azureus_messaging_protocol">=
Azureus=20
messaging protocol</A> (running ontop of the former) or the <A=20
title=3D"Enhanced messaging protocol"=20
href=3D"http://www.azureuswiki.com/index.php/Enhanced_messaging_protocol"=
>Enhanced=20
messaging protocol</A> in the near future. Since there are no guarantees =
about=20
the content additional protocol detection is mandatory when the first =
payload=20
arrives. </P>
<P>The 2 different payload encryption methods plaintext transmission and =
RC4=20
provide a different degree of protocol obfuscation, security and speed. =
Where=20
the plaintext mode only provides basic anti-shaping obscurity, no =
security and=20
low CPU usage the RC4 encryption obfuscates the entire stream and not =
only the=20
header and adds some cryptographic security at the price of spent CPU =
cycles.=20
</P>
<P>It is worth restating the aim - that of message stream obfuscation by =
the=20
application of fairly simple cryptographic techniques, not a full blown=20
transport level security mechanism like SSL. In the future, if the =
latter is=20
required, this will be addressed by a separate activity. </P>
<TABLE class=3Dtoc id=3Dtoc summary=3DContents>
  <TBODY>
  <TR>
    <TD>
      <DIV id=3Dtoctitle>
      <H2>Contents</H2></DIV>
      <UL>
        <LI class=3Dtoclevel-1><A=20
        =
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#Pr=
otocol_Objectives"><SPAN=20
        class=3Dtocnumber>1</SPAN> <SPAN class=3Dtoctext>Protocol=20
        Objectives</SPAN></A>=20
        <LI class=3Dtoclevel-1><A=20
        =
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#Me=
ssage_Stream_Encryption_.28aka_PHE.29_format_specification"><SPAN=20
        class=3Dtocnumber>2</SPAN> <SPAN class=3Dtoctext>Message Stream =
Encryption=20
        (aka PHE) format specification</SPAN></A>=20
        <LI class=3Dtoclevel-1><A=20
        =
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#Im=
plementation_Notes_for_BitTorrent_Clients"><SPAN=20
        class=3Dtocnumber>3</SPAN> <SPAN class=3Dtoctext>Implementation =
Notes for=20
        BitTorrent Clients</SPAN></A>=20
        <LI class=3Dtoclevel-1><A=20
        =
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#Tr=
acker_Extension"><SPAN=20
        class=3Dtocnumber>4</SPAN> <SPAN class=3Dtoctext>Tracker=20
        Extension</SPAN></A>=20
        <LI class=3Dtoclevel-1><A=20
        =
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#No=
tes_about_the_current_Azureus_implementation"><SPAN=20
        class=3Dtocnumber>5</SPAN> <SPAN class=3Dtoctext>Notes about the =
current=20
        Azureus implementation</SPAN></A>=20
        <LI class=3Dtoclevel-1><A=20
        =
href=3D"http://www.azureuswiki.com/index.php/Message_Stream_Encryption#Se=
e_also"><SPAN=20
        class=3Dtocnumber>6</SPAN> <SPAN class=3Dtoctext>See =
also</SPAN></A>=20
    </LI></UL></TD></TR></TBODY></TABLE>
<SCRIPT type=3Dtext/javascript> if (window.showTocToggle) { var =
tocShowText =3D "show"; var tocHideText =3D "hide"; showTocToggle(); } =
</SCRIPT>

<P><BR></P>
<DIV class=3Deditsection style=3D"FLOAT: right; MARGIN-LEFT: 5px">[<A=20
title=3D"Edit section: Message Stream Encryption (aka PHE) format =
specification"=20
href=3D"http://www.azureuswiki.com/index.php?title=3DMessage_Stream_Encry=
ption&amp;action=3Dedit&amp;section=3D2">edit</A>]</DIV><A=20
name=3DMessage_Stream_Encryption_.28aka_PHE.29_format_specification></A>
<H2>Message Stream Encryption (aka PHE) format specification</H2>
<DIV=20
style=3D"BORDER-RIGHT: #333 1px solid; BORDER-TOP: #333 1px solid; =
BACKGROUND: #ccc; BORDER-LEFT: #333 1px solid; BORDER-BOTTOM: #333 1px =
solid; TEXT-ALIGN: center"><B>Version=20
1.0</B><BR>As of now the specification is frozen. Clarifications or =
spelling=20
fixes may still occur.</DIV>
<P><BR></P><PRE>######################################################
### ----- Message Stream Encryption protocol ----- ###
### specification by Ludde/uau/The_8472/Parg/Nolar ###
######################################################

The following protocol describes a transparent wrapper for bidirectional
data streams (e.g. TCP transports) that prevents passive eavesdroping
and thus protocol or content identification.

It is also designed to provide limited protection against active MITM =
attacks
and portscanning by requiring a weak shared secret to complete the =
handshake.
You should note that the major design goal was payload and protocol =
obfuscation,
not peer authentication and data integrity verification. Thus it does =
not offer
protection against adversaries which already know the necessary data to =
establish
connections (that is IP/Port/Shared Secret/Payload protocol).

To minimize the load on systems that employ this protocol fast =
cryptographic
methods have been chosen over maximum-security algorithms.


----------------
- Declarations -
----------------

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


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

##### DH Parameters

Prime P is a 768 bit safe prime, =
"0xFFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088A67CC74020BBE=
A63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25F14374FE1356D6D51C24=
5E485B576625E7EC6F44C42E9A63A36210000000000090563"
Generator G is "2"

Xa and Xb are a variable size random integers.=20
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 =3D (G^Xa) mod P
Pubkey of B: Yb =3D (G^Xb) mod P

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

P, S, Ya and Yb are 768bits long

##### Constants/Variables


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.


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 and crypto_select are a 32bit bitfields.
As of now 0x01 means plaintext, 0x02 means RC4. (see Functions)
The remaining bits are reserved for future use.

The initiating peer A should provide all methods he supports in the =
bitfield,
but he may choose only to provide higher encryption levels e.g. if  =
plaintext
isn't sufficient for it's security needs.
The responding peer B should set a bit corresponding to the single =
method
which he selected from the provided ones.

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





SKEY =3D 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 =3D initial payload data from A
may be 0-sized if you want to wait for the encryption negotation.

Peer 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 there must be no blocking operations 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


###### Functions

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.


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.=20


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)


###### The handshake "packet" format

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -