White And Blue

 multiview控件，实际上是有点象在c/s开发中很常见的tabcontrol控件，可以在一个页面中，放置多个"view"(我们称为选项卡)，比如可以用multiview控件，可以让用户在同一页面中，通过切换到每个选项卡，从而看到要看的内容，而不用每次都重新打开一个新的窗口。
然而对Panel 的 Visible属性进行控制也可以完成这个工作，只是说用这个更专业吧！

未选择某个 View 控件时，该控件不会呈现到页面中。但是，每次呈现页面时都会创建所有 View 控件中的所有 Web 服务器控件的实例，并且将这些实例的值存储为页面的视图状态的一部分。

比如我们在用户注册中，不希望一次出现很多要填写的项，怎么做呢？那就可以用到这个，本来开始都作出来了，可惜做注册的话必须用到验证控件和存入数据库，所以暂时不做，希望大家理解，我之所以把这个系列的控件都分这么细，完全不是我无聊，我只是想尽量摸索每个控件的功能，毕竟如果我们把每个控件的功能都学得比较通了，那在实际运用中能够节约很多时间和网络带宽，我们说做程序特别是ＷＥＢ程序，不能只考虑完成了什么功能，应该考虑如何用做恰当的控件来节约开发时间和页面体积，我常常说要完成一个功能至少有两种途径，但是总有一种是尽量兼顾到各方面的，例如我们说把注册分开几个阶段，可以完成的控件就多了，panel,PlaceHolder,Wizard,当然还有我们即将讲的multiview，如何抉择才能最好呢？这必须我们对控件本身比较了解才行！好了，不废话了．

有点需要注意的是，multiview中的View完全是按照排列来定的索引，并不是你给他的ＩＤ．

当然也可以通过URL 传递参数,总之一句话,只要你把索引值传给了他,就成

通过将 MultiView 控件的 ActiveViewIndex 属性设置为要显示的 View 控件的索引值，可以在视图间移动。MultiView 控件还支持可以添加到每个 View 控件的导航按钮。

若要创建导航按钮，可以向每个 View 控件添加一个按钮控件（Button、LinkButton或 ImageButton ）。然后可以将每个按钮的 CommandName 和 CommandArgument 属性设置为保留值以使 MultiView 控件移动到另一个视图。下表列出了保留的 CommandName 值和相应的 CommandArgument 值。

gdiplus.dll 保证在
c:\WINNT\Microsoft.NET\Framework\V2.0.50727
c:\Program Files\Visual Studio 8\Common7\Packages
两个文件夹中都有
然后
"开始"-"运行" devenv /ResetSkipPkgs

 

用法：
showModalDialog()打开的窗口（简称模式窗口），置在父窗口上，必须关闭才能访问父窗口；
showModelessDialog()（简称无模式窗口），打开后不必关闭也可访问父窗口打开的窗口。

window.showModelessDialog("url","name","参数：值；参数：值；……")
showModalDialog('url','dialogName','dialogWidth:400px;dialogHeight:300px;
dialogLeft:200px;dialogTop:150px;center:yes;help:yes;resizable:yes;status:yes')
对话框的名称，可以为空

scroll： {yes | no | 1 | 0 } 是否有滚动条
status： {yes | no | 1 | 0 } 是否有状态栏，对于非模式对话框窗口，默认值是“yes”；对于模式对话框窗口，默认值是 “no”。
help：   {yes | no | 1 | 0 } 指定对话框窗口中是否显示上下文敏感的帮助图标。默认值是“yes”。 　　
resizable： 是否可以用鼠标拖动改变框提大小，0表示不可以，非0表示可以
dialogWidth： 对话框宽度值
dialogHeight： 对话框高度值
dialogLeft： iXPos 设置对话框窗口相对于桌面左上角的left位置。
dialogTop： iYPos 设置对话框窗口相对于桌面左上角的top位置。
center： {yes | no | 1 | 0 } 指定是否将对话框在桌面上居中，默认值是“yes”。
edge：{ sunken | raised } 指定对话框边框的样式。默认为raised。
unadorned：{ yes | no | 1 | 0 | on | off } 制定是否在对话框中显示边框。仅模式对话框可用。默认为no。
dialogHide：{ yes | no | 1 | 0 | on | off } 设置对话框在打印或者打印预览时是否为隐藏。仅模式对话框可用。默认为no。

MD5 To Be Considered Harmful Someday
Dan Kaminsky
Senior Security Consultant, Avaya
dan@doxpara.com
06-Dec-2004
Abstract
Joux and Wang’s multicollision attack has yielded collisions for several one-way hash algorithms. Of
these, MD5 is the most problematic due to its heavy deployment, but there exists a perception that the flaws
identified have no applied implications. We show that the appendability of Merkle-Damgard allows us to add
any payload to the proof-of-concept hashes released by Wang et al. We then demonstrate a tool, Stripwire,
that uses this capability to create two files – one which executes an arbitrary sequence of commands, the
other which hides those commands with the strength of AES – both with the same MD5 hash. We show how
this affects file-oriented system auditors such as Tripwire, but point out that the failure is nowhere near as
catastrophic as it appears at first glance. We examine how this failure affects HMAC and Digital Signatures
within Digital Rights Management (DRM) systems, and how the full attack expands into an unusual pseudosteganographic
strikeback methodology against peer to peer networks.
I. INTRODUCTION
THE modern application of cryptographic principles is actually quite primitive – not in its complexity,
but in the way the complexity has been managed. Independent primitives such as hashes and
ciphers completely specify the behavior of a limited set of aggressively audited algorithms. Each trusted
implementation is chosen to be entirely functionally equivalent to one another; choosing one over another
is to have no impact on what the user (legitimate or otherwise) can do. Deviations between the chosen
algorithms are limited to speed of operation, some mild key and block size constraints, and a vaguely
understood ”security level” of the underlying mathematics. It is this last fear – that even after all our auditing,
something will still get through – that drives adherence to the primitive specification. If everything
implements the same specification, we can swap out a broken implementation for a correct one.
But just because we can do something doesn’t mean we will. Joux [1] andWang [2] have made it plainly
clear that MD5 has serious problems. This shouldn’t come as much surprise; Dobbertin’s work [3] almost
a decade ago made it clear that this was coming. Yet even now there are those who have hinted that there
isn’t any applied risk and that the vulnerabilities are purely theoretical. Outside of FIPS’s unwillingness
to certify MD5 there is no apparent push to migrate away from MD5 as we once did for its predecessor,
MD4.
The attacks discovered are indeed obscure. But completely theoretical? No. Even given what little
data has been released – code implementing the attack isn’t even public yet – sufficient information has
been released to piece together a rudimentary proof of concept tool that demonstrates, at minimum, that
the selection of MD5 exposes new and potentially deeply undesirable functionality above and beyond
what the one-way hash primitive specifies. The tool, Stripwire, implements some of the attacks described
herein.
That being said, this paper is not a ”smoking gun” indictment of MD5. I’ve taken great pains to include
the caveats of each vulnerability, as it is far too easy to overestimate the risks described in this paper. It is
for that reason I am not saying ”today”, or ”any day now”. The title states ”someday” for a reason. There
are dots going back ten years as to the risk of MD5. Here are a few more, in the hopes that they will start
to be connected.
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 2
II. MD5 HOWTO
For a detailed description, look elsewhere [4] [5]. Put simply though, MD5 is an implementation of
a one-way hash by which an arbitrary amount of data may be reduced to a 128 bit fingerprint of what
went in. The hash is one way when it’s simple to compute the hash from arbitrary data but difficult – in
a ”computationally infeasible” sense – to reverse the process, finding data that matches a particular hash.
The hashing process needs to be resistant to the point where two datasets cannot even be created for the
express purpose of ”colliding” – having the same hash value. These cryptographically strong one way
hashes are quite useful when we want to store summaries of data, and retain the ability to recognize that
data at a later time, without actually having to keep a copy of the original data around or needing to worry
about other people being able to pretend they have a copy of the original data.
III. THE DISCOVERY: JOUX AND WANG’S MULTICOLLISION ATTACK
For MD5 (and actually a number of popular hashing algorithms, SHA-1 not among them), it is possible
to compute particular classes of input data for which subtle changes can be silently introduced without
causing apparent changes in the final MD5 hash. Capacity is not huge – of the two 128 byte proof-ofconcept
files released by Wang, only six bits differ. But many ”doppelganger” sets can be computed, each
of which may be swapped out with the other at no effect to the resultant hash. The sets are two MD5
blocks long. Because it’s possible to compute new blocks on demand, a generic ”antivirus” style colliding
block detector isn’t possible. It may be possible to generate a custom weak class detector. The ability to
generate colliding datasets exposes a fundamentally new mode of operation for MD5.
IV. EXTENDING THE ATTACK
To see how this relatively obscure new mode can cause problems, it is necessary to understand how
MD5 works. In what’s referred to as a Merkle-Damgard construction, MD5 starts with an arbitrary initial
state 128 bits in length. 512 bits of input data are ”stirred” into this 128 bit state, with a new, massively
shuffled 128 bit value as the result. 512 more bits are constantly stirred in, over and over, until there’s no
further data. 64 bits more are appended to the data stream to explicitly reflect the amount of data being
hashed with another round of MD5 being done if need be (if there wasn’t enough room in a previous round
to hash in that 64 bits), and the final 128 bit value after all the stirring is complete is christened the MD5
hash.
Now, amongst the cryptological community there is a well known failure mode to the this particular
construction: If at any point in the cascade two different datasets are stirred into equal 128 bit values,
arbitrary data can be appended to both datasets and their hashes will remain equal. In mathematical terms,
using the ”+” sign to refer to concatenation and assuming length(x) and length(y) both evenly divide into
the 64 byte blocksize of MD5, if md5(x) = md5(y), then md5(x+q) = md5(y +q).
It’s relatively straightforward to see why this occurs: Files are read in 512 bits at a time with each block
summarized into only what can fit inside the 128 bit value. Once two deviant datasets collide to the same
128 bit value, anything added on after the fact is too late – MD5 may be a chaotic and nonlinear function,
but from the same seed, the chaotic linearity between the two datasets will remain forever synchronized
with the early difference forever cloaked.
The original attack gives us our two deviant datasets. This extension shows us how we can append
arbitrary data after the datasets and still retain collision. Stripwire demonstrates how we can convert this
collision into an applied attack.
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 3
V. STRIPWIRE
We begin by defining two files, ”vec1” and ”vec2”, as the proof-of-concept test vectors released by
Wang. Vec1 and Vec2 have the same MD5 hash but differ by six bits out of 1024. We also define
”payload” as some arbitrary string of commands to be executed. The ”encrypted payload” is simply the
AES encrypted representation of payload, using the SHA-1 of vec1 as the key. (It is useful to note that
while vec1 and vec2 do share the same MD5 hash, they do not in this case share the same SHA-1 hash.)
We now define two more files, ”Fire” and ”Ice”. Fire is simply vec1 with the encrypted payload appended
to it, while Ice is vec2 with the encrypted payload attached. Only six bits separate Fire and Ice but
this small deviation is critical. Fire contains vec1, which can be easily hashed to acquire the key to the
encrypted payload. Ice contains vec2, which can be run through the SHA-1 hash but yields a useless value
that fails to decrypt the payload. So while Fire easily exposes the means to burn the system, Ice’s payload
remains frozen in its AES-enforced shell.1
Fire burns. Ice remains frozen. Fire and Ice have the same MD5 hash. Returning to the math, the
encrypted payload is q; it is a constant payload appended to the x and y of colliding sets. Through this
mechanism Ice and Fire can be exchanged at will, and as far as MD5 is concerned, nothing ever happened.
This is not theoretical. It looks like this:
A. Demo
Stripwire itself has been designed to be as readable as possible; for some readers its source code will
be much better documentation than this paper. For those seeking to reimplement the attack from this
document alone, the two test vectors are as follows:
$vec1 = h2b("
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 87 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 71 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd f2 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 b4 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 a8 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 2b 6f f7 2a 70
");
$vec2 = h2b("
d1 31 dd 02 c5 e6 ee c4 69 3d 9a 06 98 af f9 5c
2f ca b5 07 12 46 7e ab 40 04 58 3e b8 fb 7f 89
55 ad 34 06 09 f4 b3 02 83 e4 88 83 25 f1 41 5a
08 51 25 e8 f7 cd c9 9f d9 1d bd 72 80 37 3c 5b
d8 82 3e 31 56 34 8f 5b ae 6d ac d4 36 c9 19 c6
dd 53 e2 34 87 da 03 fd 02 39 63 06 d2 48 cd a0
e9 9f 33 42 0f 57 7e e8 ce 54 b6 70 80 28 0d 1e
c6 98 21 bc b6 a8 83 93 96 f9 65 ab 6f f7 2a 70
");
1 Since Ice and Fire deviate by only 6 bits, it may be possible for a particularly adept auditor to brute-force convert vec2 to vec1 and thus
acquire the correct key to examine the AES encrypted payload. If bit deviations can be at arbitrary positions, this becomes a 245 attack; if
Wang’s attack only allows a few locations to be involved in multicollisions, (as it appears to do) converting vec2 to vec1 may be a near-trivial
operation. Of course if these particular hash collisions are employed cracking the encrypted payload requires only a copy of this paper.
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 4
A line has been inserted between the two 64 byte MD5 blocks and bytes with deviant bits have been
highlighted. For example, the byte set to ”87” in vec1 is set to ”07” in vec2. It’s worth noticing that the
changes within each vector are repeated, in the same position, between their first block and their second
block.
Now onto our payload. Our payload to be encrypted may be of arbitrary size; for the purposes of this
paper we will demonstrate a bare-bones application that opens a pseudoshell on an arbitrary port.
$ cat backlash.pl
#!/usr/bin/perl
# Backlash: Open a pseudoshell on port 50023
# Author: Samy Kamkar, www.lucidx.com
use IO;
while(1){
while($c=new IO::Socket::INET(LocalPort,
50023,Reuse,1,Listen)->accept){
$˜->fdopen($c,w);
STDIN->fdopen($c,r);
system$_ while<>;
}
}
First we generate Fire and Ice.
$ ./stripwire.pl -v -b backlash.pl
fire.bin: md5 = 4df01ec3a18df7d7d6cdf8e16e98cd99
ice.bin: md5 = 4df01ec3a18df7d7d6cdf8e16e98cd99
fire.bin: sha1 = a7f6ebb805ac595e4553f84cb9ec40865cc11e08
ice.bin: sha1 = 85f602de91440cd877c7393f2a58b5f0d72cbc35
Note, their md5sum’s match, but not their sha1sums. And of course they share the same filesize.
$ ls -l fire.bin ice.bin
-rw-r--r-- 1 kaminsky mkgroup_ 496 Nov 30 20:50 fire.bin
-rw-r--r-- 1 kaminsky mkgroup_ 496 Nov 30 20:50 ice.bin
Binary comparison cannot be fooled.
$ diff fire.bin ice.bin
Files fire.bin and ice.bin differ
Stripwire contains the execution harness for Fire and Ice. When we run it against Ice...
$ ./stripwire.pl -v -r ice.bin
Unable to decrypt file: ice.bin
Failure. Fire is another story:
$ ./stripwire.pl -v -r fire.bin &
[1] 1420
$ telnet 127.0.0.1 50023
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’ˆ]’.
cat /etc/ssh_host_dsa_key_demo
-----BEGIN DSA PRIVATE KEY-----
MIH5AgEAAkEAlcTshGgpYY0eQgRBJRyQCrBDgXhFWFTbxazsgbrKiebh1aal4ET6
vPYZ7/OlPbrKxwMnX5mcEHywmEhOcK00pwIVAJyQ0ZlkpRPr2eJWz/ECgr1XgUvP
AkBWeUy6MJHApO5sF+T0V7vs319fGvw0j8dthueQ2pAZHJl063SC2n9JkaMZRHEn
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 5
J7c04xMEHnFdmIvxTNFCavKZAkEAieVtNTFNNV7SIf0m4z60mJ1Hz3zj50R7ih1S
SxPon+IxzKsoAEP9JkyjS67+HBQGpowxNuukOFaqDwl1gclGfwIVAJuPpSn6yj2e
z5m7aTzZ72B131h8
-----END DSA PRIVATE KEY-----
VI. CAVEATS
It should come as no surprise that the primary applied target for the Stripwire tool is the highly popular
”Tripwire” file system auditing tool. Although Tripwire can configured to use more trustworthy algorithms,
under common configurations it works by collecting MD5 hashes of every system file contained
within the file system and alarming if any of those hashes change. The base security presumption is that
as long as the file system doesn’t change, neither will the behavior of the system running on top of it.
Stripwire makes it trivial for an attacker to swap out the harmless Ice for the arbitrarily dangerous Fire
with Tripwire none the wiser. So does this mean Tripwire is fundamentally broken? The short answer, no,
absolutely not. The longer answer is where things get interesting.
We begin by looking closer at Tripwire’s base presumption – yes, security engineers use Tripwire to
detect unauthorized changes in the file system, but altering the file system is not the only way operations
can be affected. The file system doesn’t fully define an operating environment any more than laws fully
define a legal system. Any number of external sources can alter behavior. Faults amidst its files are but
one path, and not necessarily the best one. An entire branch of exploit research focuses on memory-only
attacks that use the network as their injection vector and alter only the in-RAM kernel or library structures
to support remote control of the OS. The disk is never touched; all evidence bleeds away the moment the
plug is pulled by a naive forensic analyst.
And of course, systems do not need to be networked to exhibit deviant behavior with a constant software
load. Anything from CPU speed to motherboard temperature sensors to the particular date emitted by the
RTC (Real Time Clock) can be used to select between completely different sets of instructions. Systems
can be even be configured to alter their behavior randomly. What matters is what the system is programmed
to do, and that’s the second problem: Tripwire doesn’t tell you that you can trust something; only auditors
can do that. It only says if you could trust it before, you still can now. For Stripwire to pose an actual
threat to a deployed environment not only would Ice need to be added to the trusted list of MD5-monitored
files but so too would the Stripwire execution harness itself. That is an unlikely circumstance.
So most uses of MD5, even by Tripwire, remain secure – under the present threat regime at least. There
still remains a critical blind spot in anything that uses MD5; to pick one example this is a fantastic channel
for a group of malicious developers to submit innocuous and undecryptable content to their auditors for
approval, and then once that’s acquired to swap in a self-decrypting and unaudited payload. Audits against
the shipped code would show the same MD5 hashes, and all would appear well.
Not that malice from the developers is a required component of such an attack. Maynor [6] describes
a fascinating failure mode whereby the multitude of compilation, assembly, and packaging tools used to
bring code from raw text to deployed code are themselves attacked. The logical progression of Thompson’s
classic essay on Trusting Trust [7], in which a C Compiler was infected and would subsequently
infect anything else compiled with it, including other C Compilers, Maynor’s approach has some interesting
implications when combined with Stripwire. Conceivably, ”Ice” could be injected into each build
assembled by the developers, thus allowing internal testing to proceed uninhibited. But, upon shipment
”Fire” would be swapped in by a malicious third party. Even if system administrators had a process by
which they validated the MD5 sum of the code to be installed with the developers’ concept of that sum
(say, through an automated package manager), they would still find themselves installing the corrupted
code.
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 6
Ultimately, MD5 cannot be depended upon to protect against a bait and switch, and neither can anything
that depends on it.
VII. DIGITAL SIGNATURES AND DRM
Digital Rights Management, or DRM, has become a catch-all term for a extensive reimagining of issues
not simply technical, but legal, political, and economic as well. The latter three have effectively driven
the concept of a mutually trusted ”third party attester” into technology that has traditionally operated
on a ”dumb automaton” model of command/execution. Third party attestation allows a third party to
control the precise manner in which a system should operate, independent of mere technological capacity.
Cryptographic primitives are chained together in DRM systems to link grantable resources to the externally
provided objects that provide the granting.
DRM systems with MD5 as part of their chain could conceivably face problems even with they never
hash data directly. All three major digital signature algorithms – RSA, DSA/ElGamel, and Elliptical
Curve – are almost universally used in a mode where they do not sign data directly, but rather sign a
hashed representation of the data. (Asymmetric algorithms are quite slow; this maneuver makes it realistic
to sign arbitrarily large files.) Often the hash algorithm of choice is MD5. Identical input yields identical
output – if two files have the same hash, they’ll both verify against the same signature. So, a key constraint
of the digital signature primitive, that no other data could survive signature verification save for the data
that was originally signed, cannot be met.
There appears to be only limited vulnerability to this in open deployment. Microsoft’s Authenticode
technology, used within its browser to limit executable content within web page to signed documents, does
indeed use (or at least allow) MD5 hashes to be signed. It would be trivial to sign something innocuous
and then actually release something malicious. But the security model of Authenticode has always been
one of legal accountability – having someone to sue – and not of technical restriction. Indeed the amount
of abjectly destructive ”spyware” tunneled to user machines through Internet Explorer is astonishing.
It is worth noting that probably the widest-deployed hardware that employs digital signatures for thirdparty
attestation, the Microsoft X-Box, uses SHA-1 as its hashing algorithm and not MD5 [8]. So it is not
vulnerable. But it’s also worth noting that had Microsoft selected MD5 instead of SHA-1 their use of a
2048 bit key for their RSA signature would have been completely irrelevant.
VIII. MULTICOLLISIONS UNLEASHED
Interestingly enough, none of what’s been discussed already actually requires the full attack discovered
by Joux and Wang. Thus far everything has been based only on the ability to append arbitrary data to
Wang’s test vectors. But failures inside cryptographic primitives, even very small ones, tend to lead to
slowly discovered catastrophic failures. MD5 does not seem to be an exception to this rule.
We can do much more with the actual multicollision attack. The test vectors collide only when stirred
into the default initial state for the MD5 algorithm; the attack itself works against any arbitrary state.
The upshot here is that we can not only append arbitrary data but prepend it as well. Presently Fire
and Ice required a dedicated external execution harness which could arouse suspicion. With prepending
available, a correctly formatted binary executable could be synthesized that would self-analyze and branch
appropriately depending on which vector was contained within.
In addition, being limited to the MD5 initial state means only hashes calculated on a per-file basis can
be made to collide; a full disc or partition sum will come across the doppelganger set at a vastly different
initial state and fail to collide. With the full attack we could specify our colliding blocks against the MD5
state that would be found during a full disk or partition hashing operation. Of course, then the colliding
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 7
set we generated wouldn’t collide on a per-file basis. Thus far we can only adapt to a single MD5 state at
a time.
IX. HMAC
Most observers have written that the HMAC, or Hashed Message Authentication Code, construction is
entirely immune to the multicollision attack. They are mostly correct, just not entirely correct. HMAC
is a method of taking an arbitrary hashing algorithm like MD5 and introducing a secret to it such that
only someone with that secret can either synthesize or verify the correct hash for some arbitrary input.
In simple terms, HMAC is a mechanism for altering the initial state according to some password. More
precisely, HMAC does the following:
Inner = MD5(Key XOR 0x36 + Data)
Outer = MD5(Key XOR 0x5c + Inner)
HMAC-MD5 = Outer
There are three things going on here:
1. A key is prepended to the data being hashed.
2. Additional noise is added to the user provided key.
3. Two rounds of hashing are used instead of one, with the noise varying between the two rounds.
There’s a fair amount of defensive cryptosystem design inside of HMAC – it’s an avowed goal of the
algorithm to still function even if small faults are found in the underlying hash. But for all its defensive
operation, the Data portion is only invoked once, prepended with a key-derived block. This new block
creates a new 128 bit state for Data to be stirred into, and this state diverges substantially from our generic
MD5 initial state.
But the multicollision attack works against any state, not just the generic one. That means it’s straightforward,
given the key, to adapt to the new system state and cause a collision in the inner hash. Once
the inner hash has collided, the outer must as well, as it’s getting the same input from both datasets. (If
the outer hash also concatenated the Data portion, the attack would fail entirely, because it’s thus far
impossible to adapt to the two separate MD5 states by the 0x36 v. 0x5c padding XORs.)
This is the first known method of creating two datasets that collide under HMAC-MD5. Once again,
though, the caveats are deep.
From one perspective, saying HMAC is insecure when the key is known is a little like saying AES is
insecure when the key is known – the whole point is that the key is unknown to the attacker. It’s quite
arguable that the MAC primitive, like anything else with a key, is allowed to collapse if the key leaks. The
basic idea of open crypto design, after all, is to migrate all secrecy and security out of the algorithm and
into the key. Is it really fair to complain when, given this design, risks show up with the key being lost?
Probably not. For all the analysis in this paper, the multicollision attack against MD5 remains relatively
weak, with special circumstances required for an attack to succeed. For Tripwire to be compromised, the
initial trust database needed to be infected. For digital signatures to be affected, something only apparently
innocuous needed to be signed first. In both cases, the use of MD5 opened up a small threat vector;
would HMAC have changed this? If an attacker has access to a system such that files may be altered, he
probably also has access to whatever HMAC key Tripwire had been reconfigured to use (assuming the
entire contents of the file system aren’t being streamed over the network to an uncompromised host). So
HMAC doesn’t change the threat scenario for Tripwire. And for a digital signature bait and switch, the
attacker has to have the HMAC key to create a signable payload for the third party attester.
Ultimately, as most uses of MD5 are immune to the multicollision vulnerability, so too are most uses
of HMAC-MD5. But when MD5 does experience an applied threat, HMAC-MD5 provides limited if any
protection.
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 8
X. STRIKEBACK: TRAITOR TRACING
Security is a battle between attackers and defenders, and defenders do not necessarily need to cede the
ground of cryptographic exploitation to attackers alone. A research path known as ”Strikeback” examines
the mechanisms by which a defender under attack can exploit weaknesses in his attackers to defend his
systems.
There are strikeback implications to this MD5 research.
The proof of concept for Stripwire was simple: Take an audio file encoded in the MPEG-1 Layer 3
(MP3) format. Append it to both vec1 and vec2. Note that the agglomerated files both play flawlessly and
identically. This wasn’t a surprising result; MP3 is a bitstream format and as such is highly resistant to socalled
”junk data” infecting the datastream. But this was the first proof that two files with bit-differences
and the same MD5 hash could still function correctly given a cooperative execution harness, and led to the
basic design of Stripwire.
It also yielded an MP3 file that contained an extra bit of information – whether vec1 or vec2 had been
prepended. A single bit is not useful. But we are not constrained to a single bit.
Wang has disclosed that, given an arbitrary MD5 system state, her implementation is capable of finding
a multicollision-capable set after approximately one hour of computation with one doppelganger computable
every fifteen minutes after that. It is well within the realm of feasiblity to compute 16 sequential
multicollision sets, each adapting to the MD5 state emitted by the previous, with 256 (or 28)computed
doppelgangers for each set. Now, instead of the single bit of information represented by the choice between
vec1 and vec2, we have 8 bits of information per prepended block – and there are 16 blocks. This
yields space for a 128 bit signature, and things just got much more interesting.
A. MP3
Consider the problem of tracing the path of an MP3 file as it winds its way through a peer to peer
network. (Peer to Peer networks are, of course, just a special case of a distributed content network of
which there are innumerable legitimate uses – Google, for one.) Since MP3 files are error-resilient, one
could connect a custom client to the network that prepended a unique 128-bit serial number to every song
transmitted. Every second-level copy would now be individually tagged and it’d be possible to trace every
file on the network back to the second-level host that retrieved it from the custom file server. Adding
a deviating serial number to each file transmitted would normally cause problems as both the search
algorithms and file integrity checks on P2P networks tend to be MD5 centric. But since the serial number
is represented in a form that MD5 is blind to, nothing fails – except perhaps some of the opacity of the
P2P network.
That’s not to say there aren’t countermeasures. The serial number is easy to detect, can be trivially
stripped, is simple to alter, and can be rendered inoperable simply by switching the network to another
hashing algorithm. But even here there are caveats – detection may be simple, but eliminating the serial
number entirely will yield a different hash value, subtly breaking the network’s ability to coalesce all
identical payloads. And while it’s possible for hosts on the P2P network to ”mix and match” doppelganger
sets from several hosts, it’s relatively straightforward to identify a cryptographically secure subset of the
2128 possible serial numbers that makes it impossible for users to synthesize valid serial numbers through
any other means of acquiring them from a first or second generation source. And finally peer to peer
networks are still networks and as such are vulnerable to the greatest caveat of network effects: Even after
faults are identified, so many nodes may depend on the faulty behavior that the value of the network is
decreased more by fixing the fault than it is by suffering its continued presence.
There is one special case on P2P networks – some designs allow a file to be acquired in pieces from
several different nodes. One solution to this is to seed a file with serial numbers across its entire body,
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 9
perhaps three sets every 128 kilobytes. This is a much more compute-intensive operation, though, since
the multicollision sets must be computed on a per-file basis as different data will preceed each group of
doppelgangers.
B. Executables
Barring some of the more creative and noticeably illegal designs which infect MP3 files with executable
content, it’s not possible for MP3-embedded signatures to yield any more evidence except for what they
present by their existence on any number of hosts.
Actual executables are another story. They are generally quite full of undocumented and undocumentable
functionality, much of it inserted by a compiler. (Thus the limits of auditors – they may be
able to read source, but how many can read what the compiler actually emits? Because that’s what the
system ultimately needs to trust.) Particularly if an executable is aggressively protected from public distribution,
there can be no expectation of publically safe behavior (in fact, that’s generally why aggressive
protections are instituted in the first place. That and profit motives.) It would be quite irresponsible to
embed code that erased hard drives or flooded networks...
But why not locate the source of the leak?
128 bits is a fair amount of capacity – English text only takes 1.3 bits per character, compressed –
and it’d be reasonable to quadruple that if needed. Before distributing an illicitly acquired executable,
an attacker is likely to test it during their packaging process. During this testing, the executable installer
could be configured to collect PII (Personally Identifiable Information) from across the file system. The
128 to 512 most valuable bits of information would be locally transformed into the requisite MD5-blind
series of doppelgangers, and injected back into the installer upon its exit before mass distribution could
take place. The range of acquirable data is extensive – potential sources include:
1. Network data – IP address, DNS name, default name server, MAC address
2. Browser Cookies, Caches, and Password Stores – Online Banking, Hotmail, Amazon 1-Click
3. Cached Instant Messenger Credentials – Yahoo, AOL IM, MSN, Trillian
4. P2P Memberships – KaZaA, Gnutella2
5. Corporate Identifiers – VPN Client Data / Logs
6. Shipped Material – CPU ID, Vendor ID, Windows Activation Key
7. System Configurations – Time Zone, Telephone API area code
8. Wireless Data – MAC addresses of local access points
9. Existence Tests – Special files in download directory
Also possible but legally problematic would be acquiring not just one hop’s worth of data but watching
the executable as it travels across large networks, containing identifying information for as many previous
hops as possible. Capacity becomes a problem, as it does with IP’s ”Record Route” option, but we can
handle it by dynamically reducing resolution (the RRDTool approach) or by simply keeping an overflow
counter (what IP does).
This is not the first scheme assembled to uniquely tag executables. What’s interesting here is that these
tags are self-updating as the file is trafficked, and that the self-updating tags are difficult to detect even
with dedicated file integrity checks (md5sums). In a very unique sense, this is a steganographic strategy
aimed not at the human analyst but at the precise internals of the MD5 algorithm. It’s quite effective.
XI. CONCLUSIONS
The point is not that MD5 has collapsed. It hasn’t. The point is that there’s a very clear trend regarding
the security level of MD5, and it isn’t good. It is now undeniable that the selection of MD5 matters – the
constraint that deployed implementations of the one-way hash primitive be functionally identical has been
MD5 TO BE CONSIDERED HARMFUL SOMEDAY 10
broken. The failures detected are not merely algorithmic or theoretical, rather new capabilities above and
beyond what the primitive specifies are made available by the selection of MD5. It is not expected that
this paper will cause a precipitous decline in the use of MD5; that will probably occur when a means of
silently introducing single-bit errors in arbitrary (rather than chosen) MD5 payloads is discovered.
But in the security community, we tend to complain about the ”phase change” nature of our systems
that suddenly collapse from secure to insecure on the discovery of a ”zero day” exploit. The phase change
for MD5 isn’t here yet, but it will come, someday. Nobody should be surprised when that day arrives.
REFERENCES
[1] Antoine Joux, “Multicollisions in iterated hash functions. applications to cascaded constructions.,”
2004.
[2] XiaoyunWang, Dengguo Feng, Xuejia Lai, and Hongbo Yu, “Collisions for hash functions md4, md5,
haval-128 and ripemd,” Cryptology ePrint Archive, Report 2004/199, 2004, http : / / eprint .
iacr . org/.
[3] Hans Dobbertin, “Cryptanalysis of md5 compress,” 1996, http : / / citeseer . ist . psu .
edu / 68442 . html.
[4] Philip Hawkes, Michael Paddon, and Gregory G. Rose, “Musings on the wang et al. md5 collision,”
Cryptology ePrint Archive, Report 2004/264, 2004, http : / / eprint . iacr . org/.
[5] Stefan Lucks, “Design principles for iterated hash functions,” Cryptology ePrint Archive, Report
2004/253, 2004, http : / / eprint . iacr . org/.
[6] David Maynor, “Trust no one, not even yourself, or the weak link might be your build tools,” in
The Black Hat Briefings USA, 2004, http : / / www . blackhat . com / presentations /
bh-usa-04 / bh-us-04-maynor . pdf.
[7] Ken Thompson, “Reflections on trusting trust,” Commun. ACM, vol. 27, no. 8, pp. 761–763, 1984.
[8] Andy Green Peter Barth, Jeff Mears, “Project b (hacking) overview,” 2004, http : / / www .
xbox-linux . org / docs / projectboverview . html.

SOAP  摘要简单对象访问协议  (SOAP)  通过一种基于XML的、和平台无关的方法规划网站，从而提高Internet的交互性。绪论  Internet正在从根本上改变着计算，从而根本上改变了商业实现的方式。向电子商务的过渡在所有的计算机系统中导致了巨大的波浪反应。随着公司将它们的客户管理、订单实现系统和它们的在线销售系统综合，网站的作用将越来越小。下一步综合将延伸到商务伙伴之间，如供应商和发行商之间。除了通过Internet综合各种商务系统外，还有另外一些推动网络发展的、与服务相关的现象。例如，用户需要更丰富、更深、更个性化和更主动的服务，服务于他们的工作或个人生活，这是为他们的利益服务的，同时可以节约他们的时间、金钱和困难。结果，网络正从一个由一些网页提供简单服务的网站方式发展到动态Web服务，可以交互执行一些复杂的步骤，为用户提供服务。这些任务可能需要一个Web服务调用另外的Web服务，像一个传统的软件程序一样调整步骤执行命令。今天所面临的问题是和其他服务的综合以及和其他设备连接仍然是困难的，因为还缺少一些互相联络的工具和通用协定。网络所需要的是一种能够将所有服务结合起来的一般方法。多个服务能够一起无缝地工作，必须能够容易地协调Internet上的各个服务步骤，容易地创建新的和用户化的服务。开发人员必须能够综合，而不仅仅是提供服务。他们需要能够从任何软件组件、应用程序、商务进程、设备或其他知识产权的组合中形成解决方案。这需要一个共同的目标使得在Internet上任何地方的开发人员能够一起工作—这是新的应用程序模型，为分布式组件以快速、可靠的方式连接分布式服务和组件提供核心的编程服务。以前，创建这类复杂的应用对应用的通讯是使用一个对象模型，例如Microsoft的DCOM或Object  Management  Group的Internet  Inter-ORB协议  (IIOP)或Common  Object  Request  Broker  Architecture  (CORBA)。但是这些技术在创建Web服务的时候具有一些不足。具体地说，DCOM和IIOP/CORBA是复杂环境，意味着用它们实现的应用程序通常是复杂的和均匀的。换句话说，使用它们创建分布式应用程序，通常需要在连接的两端都运行相同的分布对象模型。但是Internet并不保证和你连接的另外一端运行特定的客户和服务软件，如HTTP。并且要让每个人都运行IIOP或COM是不切实际的，在技术上也是不可实现的.  解决这个问题的一种方案是使用已有的Internet标准:  HTTP  and  XML。超过其他任何一种应用程序协议，超文本传输协议连接了整个世界。几百万个网站和浏览器已经证明了这一点。如果你没有一个e-mail客户端软件，你可以通过一个网站来使用e-mail;  如果你想使用其他的不同于HTTP的技术来连接到Internet,  你将会发现大部分其他的应用程序协议最多是可以容忍的，并且通常会被防火墙阻挡在外面。单独使用HTTP的问题是它主要是一个服务器到客户端传输文件的机制。为了创建更好的Web服务，你需要扩展HTTP。SOAP更好满足了这个要求：它加入了一套HTTP标题和一个丰富XML，能够在Internet上实现复杂的应用和应用的通讯。  SOAP做什么和不做什么  SOAP通讯协议使用HTTP来发送XML格式的信息。SOAP规范的定期目标包括两个层次：  提供一个Internet标准的标准对象调用协议，通过HTTP进行传输，数据编码成XML格式。  创建一个可扩展协议和有效载荷（payload）格式，  能够随时间升级。这个规范的作者明确地将创建对象模型更辣手部分以及已经创建好的部分排除在外。他们指出他们不想“定义一个分布式对象系统的所有方面”。这意味着不存在分布式的垃圾堆积、类型安全或版本、没有双向的HTTP通讯、没有消息传输或管道进程、没有参考对象以及没有激活对象。SOAP意味着简单—可以被一个开发人员在几天的时间内使用任何编程语言在任何操作系统上完成。这些虽然不是SOAP本身的目标，但它们可以在SOAP的环境中实现—不仅仅是SOAP。它们需要你通过任何可用的工具自己创建。  SOAP定义  SOAP定义了一种在HTTP客户端和服务器端传输命令和参数的机制。SOAP不关心什么操作系统、编程语言或在服务器端或客户端使用的对象模型：除了需要使用HTTP传输外，与其他无关。  SOAP是简单的。客户端发送一个请求给服务器，调用相应的对象，然后服务器返回结果。这些消息是XML格式的，并且封装成符合HTTP协议的消息。  SOAP通过已有的Internet下层结构来工作。你不需要作任何工作，它符合任何路由器、防火墙或代理服务器。  SOAP客户请求封装在一个HTTP  POST  (或M-POST)包中。下面的例子摘自Internet-draft规范说明中:  POST  /StockQuote  HTTP/1.1  Host:  www.stockquoteserver.com  Content-Type:  text/xml  Content-Length:  nnnn  SOAPMethodName:  Some-Namespace-URI#GetLastTradePrice  <SOAP:Envelope  xmlnsOAP="urnchemas-xmlsoap-orgoap.v1">  <SOAP:Body>  <m:GetLastTradePrice  xmlns:m="Some-Namespace-URI">  <symbol>DIS</symbol>  </m:GetLastTradePrice>  </SOAP:Body>  </SOAP:Envelope>  第一个四行是标准的HTTP:  POST是HTTP的动词，所有的HTTP消息都需要主机。Content-Type和Content-Length部分是所有包含  payload  的HTTP消息所需要的。Content-Type  "text/xml"表示payload是一个发送给服务器的XML消息(或者是发送一个具有扫描应用程序头功能的防火墙的消息)  XML代码是易懂的，比如：Envelope和Body部分规定了普通  payload打包机制；  <GetLastTradePrice>  部分包括一个被称为<符号>的部分，其中包含了股票交易的符号。这个请求的目的是非常明显的：得到某个特定股票的最后一次交易价格—本例子中是Disney(DIS)。发送这个消息的程序仅仅需要知道如何格式化一个SOAP请求：  构成一个请求所需要的HTTP头格式和XML  格式。本例子中，程序知道需要形成是一个股票价格的请求。接受这个消息的HTTP服务器通过这个HTTP头SOAPMethodName知道这是一个SOAP请求；然后服务器发送或处理消息的相应部分。  SOAP说明  SOAP定义了两种类型的消息，请求和响应，从而允许客户端能够递交一个远端请求，允许服务器端能够响应这些请求。上面所举的是一个请求的例子；下面列举了对该请求的响应：  HTTP/1.1  200  OK  Content-Type:  text/xml  Content-Length:  nnnn  <SOAP:Envelope  xmlnsOAP="urnchemas-xmlsoap-orgoap.v1">  <SOAP:Body>  <m:GetLastTradePriceResponse  xmlns:m="Some-Namespace-URI">  <return>34.5</return>  </m:GetLastTradePriceResponse>  </SOAP:Body>  </SOAP:Envelope>  最前面的三行仍然是标准的HTTP：第一行表明这是对前面的POST请求的一个响应，第二行和第三行指出了内容类型和长度。  XML头封装了一个SOAP的payload。XML的<GetLastTradePriceResponse>部分包含了对一次交易价格请求的响应；它的子部分<return>表明了返回这个请求的值。  SOAP说明的关键部分是它所调用的HTTP动词POST  和M-POST、附加的  HTTP头、和XML所需要的名称空间，从而避免在不同环境可能由于复制所带来的错误。这个说明还详细表明了SOAP所调用的方法和所处理的数据类型。如果你还感到困惑，M-POST动词是来自HTTP  Extension  Framework  Internet设计的。在这个设计中定义了一个新的HTTP动词是如何在已有动词的基础上通过加入字符"M-"来创建的。  接收包含有这些动词的请求，服务器必须按照这个动词作出相应的响应。如果一个POST操作失败了  (比如，被防火墙阻挡)，SOAP说明将会建议你再使用M-POST试一次。这使得SOAP处于出现错误可以替换的状态，但是不需要防火墙来完成任何扩展的功能。  SOAP和对象模型  SOAP不需要任何对象模型，也不需要通过其他的通讯实体来使用对象模型。在避免对象模型的基础上，SOAP将大部分对象功能  (如初始化代码和垃圾堆积)留给客户端和服务器端工作的底层，同时其他功能(如信号编辑)则可以留给SOAP综合已有的应用程序和底层结构来完成。  SOAP可以使用任何语言来完成，只要客户端发送正确SOAP请求  (也就是说，传递一个合适的参数给一个实际的远端服务器)。SOAP没有对象模型，应用程序可以捆绑在任何对象模型中。早期实现SOAP功能的有Java,  Perl,  和Windows版本。当将每个功能变为SOAP实体能够理解的参数和响应后  (例如，数据保存在一个XML元素中，并封装在HTTP消息中),它就可以和其他的SOAP功能交互作用。  使用SOAP编程使用SOAP编程有两种不同方式，决定于是否SOAP已经存在于你的底层结构中  (比如，通过CORBA部分完成或将其置入你的操作系统中)或你是否自己创建SOAP底层结构。为SOAP创建底层结构使用SOAP不需要创建分布式对象；毕竟，SOAP本身就是设计出来通过网络从一个对象发送消息到另一个对象的，不依靠于任何  消息来去对象。在理论上说，这意味着通过判断到达服务器的数据类型(从客户端请求)和需要发送的数据类型(对请求的响应)，可以在系统之间创建一个SOAP界面。举一个简单的例子，对于一个SOAP-enabled的体温计：它只接收一个消息，  <GetCurrentTemp>  并且只返回一个值<CurrentTemp>。其他的任何信息将被忽视。对于一个自动调温器：你可以使用<GetCurrentTemp>调用，也可以使用  <GetCurrentSetting>调用，这将返回自动调温器的当前设置。加入<SetTemp>功能，这时你已经完成了一个非常使用的应用。一个应用程序是否象那个SOAP-enabled  自动调温器那样相对简单或相当复杂  (比如，一个将一个大航空公司的工程、市场和目录的系统和它的供应商相连接的应用)，都需要底层的支持，这样才能发送、接收和理解相关的SOAP消息。为特定目的而开发的企业应用可以从SOAP中得到好处，使用SOAP来创建一般解决方案可能性甚至更加激动人心。服务提供商可以给需要特定服务的用户提供"无特性的"的建筑材料。举一个例子，对于客户认证和为用户跟踪信用卡和交付信息的问题：安全、可靠和正确地实现这个功能是一个重要的任务，对于那些小的交易来说更是如此。一个应用服务供应商  (ASP)  使用SOAP可以为客户认证、付款和交付创建一个通用解决方案，然后出售或提供这个服务。这类的服务适合于任何平台，并且允许ASP客户通过简单地将图标拖放到一个网站上，从而实现和这个网站的电子商务。  ASP的客户在初始化服务的时候就可以回答一些问题(或者，这些问题在客户系统设置好和ASP实体进行通讯的时候能自动解决)。一个设置好，服务将实现在ASP客户的网站上，并且好象是那个网站的一部分。当客户单击网站上的购买按钮，服务将启动：首先得到所需的任何客户信息，然后发送这些信息给ASP进行处理，并且通知服务用户系统交易已经被认可。  SOAP使本次操作的所有人员平稳操作成为可能  (终端客户进行一次购买操作，网络零售商卖出，ASP则为客户认证提供"掩藏"服务)，人员可以使用任何平台。零售商可能需要从ASP那里得到一些代码运行在它的网站上；在客户初始化一次交易时，这些代码将调用在ASP处运行的其他例程  结论虽然DCOM支持者和CORBA支持者之间在那个对象结构应该成为台式机、大型机和网络标准的问题上进行了数年的争论，但是它们对于对方指出的不足没有任何改善。SOAP则为它们提供了和解的机会：任何人既能够坚持使用其喜欢的模型，也能和其他人进行交互  作用。最后，SOAP说明  已经作为一个Internet-Draft递交给IETF。由于SOAP是一个简单协议，整个交互作用中可以低价实现SOAP。

如何使用关键字才算适当呢？

---

　　 搜索引擎通过使用关键字的相关程度来决定网页的先后顺序。例如，如果有人搜索“ butterbeans ”，那么一个标题为“ The Butterbean Bazaar ”，里面有十余处单词“ butterbeans ”的网页，可能就会排在搜索结果顶端；而那种只出现了一两次“ butterbeans ”的网站，则排列在稍后的地方；网站上有“ beans ”单词的，就排在更后面的地方；只有“ beanless ”这样的单词的网站，则根本不会出现在搜索结果中。每个搜索引擎，都有它自己的排列搜索结果的公式，而且它们被作为机密保存起来。但基本规则是，一个网页出现某个关键字的次数越多，那么，该网页与关键字的相关程度就高，该网页在搜索结果中的排列位置就越靠前。另外，网页标题、章节标题中的关键字，相关程度更高。 知道了这个规则，很多“聪明人”就在他们的网页上，布置大量“ mp3 ”、“ free ”之类的热门词汇。有些文章更介绍了诸如“隐形文本”、“隐藏关键字”等提高排名的作弊技巧，这些招数被大量甚至疯狂使用，使搜索引擎的查阅效果大打折扣。显然，如果大家都这样做，那么，搜索引擎迟早会变得毫无用处。到了某天，说不定不管你搜索什么，得到的总是色情网站。所以，搜索引擎展开了一场反作弊的斗争。只要它们怀疑你在有意“制造”关键字，那么，就可能取消你的注册。例如现在，很多搜索引擎不接受使用“隐形文本”网站的注册。



其实，“关键字”的使用，犹如一把“双刃剑”，一方面，为了使网站在搜索引擎的排名靠前，你的网页应该包含尽量多的关键字，但是另一方面，一旦过度，你就可能面临取消注册资格的危险。所以真正关键的，除了网站本身要有好的内容、产品或服务及设计效果外，就是使你的网页与搜索引擎友好相处，说白了，一要适当使用关键字，二要避免“冒犯”搜索引擎，不要使用那些容易让它“误会”的设计技术，例如，框架和某些动态网页注册。



那么，如何使用关键字才算适当呢？



　　找出人们搜索你的这类网站时，可能使用的所有词汇（关键字），并将它们尽可能地串起来，给你的网站写个简短的描述。例如，如果你要销售 butterbeans （棉豆），并且你已经列出了下面的关键字：
　　 Butterbeans
　　 Beans
　　 Lima beans
　　 Biscuits
　　 Southern cooking
你可以这样写描述：
　　“ We sell butterbeans and lima beans, which taste great with biscuits and other Southern cooking. Free butterbean recipes and a butterbean discussion forum 。”



　　注意，如何组合重要的关键字（事实上，你的关键字列表可能更长，可以将其中重要的串起来），如何将最重要的那个（如 butterbeans ）用上两次。但是，这个描述读起来应该跟普通句子一样，不要只是一个关键字列表。



　　这个网站描述会用在好几个地方，因此多话一些精力写好它，是值得的。当你向搜索引擎注册的时候，需要填网站描述，当人们搜索到你的网站的时候，这个描述也会出现，所以，要尽量利用它，吸引人们浏览你的网站，但不要简单使用夸大性的词句。另外，网站描述（或将其修改后）还应该放在 TITLE 标记中。



　　 TITLE 标记位于 HTML 网页的 HEAD 部分。当冲浪者浏览一个网页的时候，它的内容会出现在浏览器最顶端。如果有人将你的网站保存到“书签”（ Netscape ）或“收藏夹”（ IE ）， TITLE 将作为“书签”名或“收藏”名。 TITLE 标记应该以你网站的正式名称开头，并包括网站简要描述。例如：
　　 < TITLE>The Butterbean Bazaar - We sell butterbeans and lima beans, and offer free butterbean recipes and a butterbean discussion forum.< /TITLE>



　　不要将关键字列表放在 TITLE 中，这样做弊大于利。也不要在那里放冗长无用的内容，如“ Welcome to the Web Site ”，这纯粹是浪费网络资源。



　　 HEAD 部分还有两个对网站宣传很重要的标记： META DESCRIPTION 和 META KEYWORDS 标记。某些（但不是所有）搜索引擎，使用这些标记的内容来决定你网站的排列位次。用于 META DESCRIPTION 标记的规则与 TITLE 的基本上一样。而 META KEYWORDS 标记，就是一个关键字列表，注意，在这里放入太多单词，并没有什么益处，因为，大多数专家都认为，搜索引擎对此只作有限量搜索。因此，挑选出人们真正会用的关键字，才是有价值的。多数人认为，这些关键字应该小写，并且用逗号或空格分开。



　　网页上的关键字最重要。但别高兴——必须是普通的、可读的文本，那种将一大堆关键字随便放到网页上的做法，属于作弊行为，将得不到注册。你可以让最重要的关键字在网页出现一到两次，当然，还可以放到网页标题、文章标题中。