﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-思想比知识更重要 成长比成功更重要-随笔分类-Security</title><link>http://www.blogjava.net/renyangok/category/17028.html</link><description /><language>zh-cn</language><lastBuildDate>Tue, 27 Nov 2007 07:12:21 GMT</lastBuildDate><pubDate>Tue, 27 Nov 2007 07:12:21 GMT</pubDate><ttl>60</ttl><item><title>网络安全协议之比较（SSH、 PKI、SET、SSL）</title><link>http://www.blogjava.net/renyangok/archive/2007/11/26/163242.html</link><dc:creator>保尔任</dc:creator><author>保尔任</author><pubDate>Mon, 26 Nov 2007 09:04:00 GMT</pubDate><guid>http://www.blogjava.net/renyangok/archive/2007/11/26/163242.html</guid><wfw:comment>http://www.blogjava.net/renyangok/comments/163242.html</wfw:comment><comments>http://www.blogjava.net/renyangok/archive/2007/11/26/163242.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/renyangok/comments/commentRss/163242.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/renyangok/services/trackbacks/163242.html</trackback:ping><description><![CDATA[<div>
<h2>网络安全协议之比较（SSH、 PKI、SET、SSL）</h2>
<div><strong>一、SSH介绍 </strong><br />
<br />
什么是SSH？ <br />
传统的网络服务程序，如：ftp、pop和telnet在本质上都是不安全的，因为它们在网络上用明文传送口令和数据，
别有用心的人非常容易就可以截获这些口令和数据。而且，这些服务程序的安全验证方式也是有其弱点的，
就是很容易受到&#8220;中间人&#8221;（man-in-the-middle）这种方式的攻击。所谓&#8220;中间人&#8221;的攻击方式，
就是&#8220;中间人&#8221;冒充真正的服务器接收你的传给服务器的数据，然后再冒充你把数据传给真正的服务器。
服务器和你之间的数据传送被&#8220;中间人&#8221;一转手做了手脚之后，就会出现很严重的问题。 <br />
<br />
SSH的英文全称是Secure <br />
&nbsp;&nbsp;&nbsp;
SHell。通过使用SSH，你可以把所有传输的数据进行加密，这样&#8220;中间人&#8221;这种攻击方式就不可能实现了，
而且也能够防止DNS和IP欺骗。还有一个额外的好处就是传输的数据是经过压缩的，所以可以加快传输的速度。
SSH有很多功能，它既可以代替telnet，又可以为ftp、pop、甚至ppp提供一个安全的&#8220;通道&#8221;。 <br />
<br />
最初SSH是由芬兰的一家公司开发的。但是因为受版权和加密算法的限制，现在很多人都转而使用OpenSSH。 OpenSSH是SSH的替代软件，而且是免费的，可以预计将来会有越 来越多的人使用它而不是SSH。 <br />
<br />
SSH是由客户端和服务端的软件组成的，有两个不兼容的版本分别是：1.x和2.x。 用SSH 2.x的客户程序是不能连接到SSH 1.x的服务程序上去的。OpenSSH 2.x同时支持SSH 1.x和2.x。 <br />
<br />
SSH的安全验证是如何工作的 <br />
从客户端来看，SSH提供两种级别的安全验证。 <br />
<br />
第一种级别（基于口令的安全验证）只要你知道自己帐号和口令，就可以登录到远程主机。所有传输的数据都会被加密， 但是不能保证你正在连接的服务器就是你想连接的服务器。可能会有别的服务器在冒充真正的服务器， 也就是受到&#8220;中间人&#8221;这种方式的攻击。 <br />
<br />
第二种级别（基于密匙的安全验证）需要依靠密匙，也就是你必须为自己创建一对密匙，并把公用密匙放在需要访问的服务器上。
如果你要连接到SSH服务器上，客户端软件就会向服务器发出请求，请求用你的密匙进行安全验证。服务器收到请求之后，
先在你在该服务器的家目录下寻找你的公用密匙，然后把它和你发送过来的公用密匙进行比较。如果两个密匙一致，
服务器就用公用密匙加密&#8220;质询&#8221;（challenge）并把它发送给客户端软件。
客户端软件收到&#8220;质询&#8221;之后就可以用你的私人密匙解密再把它发送给服务器。用这种方式，你必须知道自己密匙的口令。但是，与第一种级别相比，第二种级别不
需要在网络上传送口令。 <br />
<br />
第二种级别不仅加密所有传送的数据，而且&#8220;中间人&#8221;这种攻击方式也是不可能的（因为他没有你的私人密匙）。 但是整个登录的过程可能需要10秒。 <br />
<br />
<strong>二、SSL介绍（Secure socket Layer &amp; Security Socket Layer）</strong><br />
<br />
一个应用程序的安全需求在很大程度上依赖于将如何使用该应用程序和该应用程序将要保护什么。不过，用现有技术实现强大的、 一般用途的安全通常是可能的。认证就是一个很好的示例。 <br />
<br />
当顾客想从 Web 站点购买某个产品时，顾客和 Web 站点都要进行认证。顾客通常是以提供名字和密码的方式来认证他自己。 另一方面，Web
站点通过交换一块签名数据和一个有效的 X.509 证书（作为 SSL 握手的一部分）来认证它自己。
顾客的浏览器验证该证书并用所附的公用密钥验证签名数据。一旦双方都认证了，则交易就可以开始了。 <br />
<br />
SSL 能用相同的机制处理服务器认证（就如在上面的示例中）和客户机认证。 Web 站点典型地对客户机认证不依赖 SSL —
要求用户提供密码是较容易的。而 SSL 客户机和服务器认证对于透明认证是完美的， 对等机 — 如 p2p
应用程序中的对等机之间一定会发生透明认证。 <br />
<br />
安全套接字层（Secure Sockets Layer（SSL）） ，SSL
是一种安全协议，它为网络（例如因特网）的通信提供私密性。SSL 使应用程序在通信时不用担心被窃听和篡改。 SSL
实际上是共同工作的两个协议：&#8220;SSL 记录协议&#8221;（SSL Record Protocol）和&#8220;SSL 握手协议&#8221; （SSL Handshake
Protocol）。&#8220;SSL 记录协议&#8221;是两个协议中较低级别的协议，它为较高级别的协议， 例如 SSL
握手协议对数据的变长的记录进行加密和解密。SSL 握手协议处理应用程序凭证的交换和验证。 <br />
<br />
当一个应用程序（客户机）想和另一个应用程序（服务器）通信时，客户机打开一个与服务器相连接的套接字连接。然后，
客户机和服务器对安全连接进行协商。作为协商的一部分，服务器向客户机作自我认证。客户机可以选择向服务器作或不作自我认证。
一旦完成了认证并且建立了安全连接，则两个应用程序就可以安全地进行通信。按照惯例，我将把发起该通信的对等机看作客户机，
另一个对等机则看作服务器，不管连接之后它们充当什么角色。<br />
<br />
<br />
名为 A 和 B 的两台对等机想安全地进行通信。在我们简单的 p2p 应用程序的环境中，对等机 A 想查询对等机 B 上的一个资源。
每个对等机都有包含其专用密钥的一个数据库（名为 keystore）和包含其公用密钥的证书。密码保护数据库的内容。
该数据库还包含一个或多个来自被信任的对等机的自签名证书。 对等机 A
发起这项事务，每台对等机相互认证，两台对等机协商采用的密码及其长度并建立一个安全通道。完成这些操作之后，
每个对等机都知道它正在跟谁交谈并且知道通道是安全的。 SSL (Secure socket
Layer)安全套接层协议主要是使用公开密钥体制和X.509数字证书技术保护信息传输的机密性和完整性，
它不能保证信息的不可抵赖性，主要适用于点对点之间的信息传输，常用Web Server方式。 <br />
<br />
安全套接层协议（SSL，Security Socket
Layer）是网景（Netscape）公司提出的基于WEB应用的安全协议，它包括：服务器认证、
客户认证（可选）、SSL链路上的数据完整性和SSL链路上的数据保密性。对于电子商务应用来说，使用SSL可保证信息的真实性、
完整性和保密性。但由于SSL不对应用层的消息进行数字签名，因此不能提供交易的不可否认性，这是SSL在电子商务中使用的最大不足。
有鉴于此，网景公司在从Communicator 4.04版开始的所有浏览器中引入了一种被称作&#8220;表单签名（Form Signing）&#8221;的功能，
在电子商务中，可利用这一功能来对包含购买者的订购信息和付款指令的表单进行数字签名，从而保证交易信息的不可否认性。综上所述，
在电子商务中采用单一的SSL协议来保证交易的安全是不够的，但采用"SSL+表单签名"模式能够为电子商务提供较好的安全性保证。<br />
<br />
<strong>三、PKI介绍</strong><br />
<br />
为解决Internet的安全问题，世界各国对其进行了多年的研究，初步形成了一套完整的Internet安全解决方案，
即目前被广泛采用的PKI体系结构，PKI体系结构采用证书管理公钥，通过第三方的可信机构CA，
把用户的公钥和用户的其他标识信息（如名称、e-mail、身份证号等）捆绑在一起，在Internet网上验证用户的身份，
PKI体系结构把公钥密码和对称密码结合起来，在Internet网上实现密钥的自动管理，保证网上数据的机密性、完整性。<br />
<br />
<br />
从广义上讲，所有提供公钥加密和数字签名服务的系统，都可叫做PKI系统，PKI的主要目的是通过自动管理密钥和证书，
可以为用户建立起一个安全的网络运行环境，使用户可以在多种应用环境下方便的使用加密和数字签名技术，
从而保证网上数据的机密性、完整性、有效性，数据的机密性是指数据在传输过程中，不能被非授权者偷看，
数据的完整性是指数据在传输过程中不能被非法篡改，数据的有效性是指数据不能被否认。一个有效的PKI系统必须是安全的和透明的，
用户在获得加密和数字签名服务时，不需要详细地了解PKI是怎样管理证书和密钥的，一个典型、完整、 有效的PKI应用系统至少应具有以下部分： <br />
<br />
公钥密码证书管理。 <br />
<br />
黑名单的发布和管理。 <br />
<br />
密钥的备份和恢复。 <br />
<br />
自动更新密钥。 <br />
<br />
自动管理历史密钥。 <br />
<br />
支持交*认证。 <br />
由于PKI体系结构是目前比较成熟、完善的Internet网络安全解决方案，
国外的一些大的网络安全公司纷纷推出一系列的基于PKI的网络安全产品，如美国的Verisign, IBM ,
Entrust等安全产品供应商为用户提供了一系列的客户端和服务器端的安全产品，为电子商务的发展提供了安全保证。
为电子商务、政府办公网、EDI等提供了完整的网络安全解决方案。<br />
<br />
<br />
PKI是一种新的安全技术，它由公开密钥密码技术、数字证书、
证书发放机构（CA）和关于公开密钥的安全策略等基本成分共同组成的。PKI是利用公钥技术实现电子商务安全的一种体系，
是一种基础设施，网络通讯、网上交易是利用它来保证安全的。从某种意义上讲，PKI包含了安全认证系统，
即安全认证系统-CA/RA系统是PKI不可缺的组成部分。<br />
<br />
PKI（Public Key Infrastructure）公钥基础设施是提供公钥加密和数字签名服务的系统或平台，
目的是为了管理密钥和证书。一个机构通过采用PKI框架管理密钥和证书可以建立一个安全的网络环境。 X.509格式的证书和证书废除列表(CRL)；
CA/RA操作协议； CA管理协议； CA政策制定。<br />
<br />
<strong>四、SET协议介绍</strong><br />
<br />
电子商务在提供机遇和便利的同时，也面临着一个最大的挑战，即交易的安全问题。在网上购物的环境中，
持卡人希望在交易中保密自己的帐户信息，使之不被人盗用；商家则希望客户的定单不可抵赖，并且，在交易过程中，
交易各方都希望验明其他方的身份，以防止被欺骗。针对这种情况， 由美国Visa和MasterCard两大信用卡组织联合国际上多家科技机构，
共同制定了应用于Internet上的以银行卡为基础进行在线交易的安全标准， &#8220;这就是&#8220;安全电子交易&#8221;（Secure Electronic
Transaction，简称SET）。它采用公钥密码体制和X.509数字证书标准， 主要应用于保障网上购物信息的安全性。<br />
<br />
由于SET 提供了消费者、商家和银行之间的认证，确保了交易数据的安全性、完整可靠性和交易的不可否认性， 特别是保证不将消费者银行卡号暴露给商家等优点，因此它成为了目前公认的信用卡/借记卡的网上交易的国际安全标准。<br />
<br />
SET(Secure Electronic
Transaction)安全电子交易协议是由美国Visa和MasterCard两大信用卡组织提出的应用于
Internet上的以信用卡为基础的电子支付系统协议。它采用公钥密码体制和X.509数字证书标准， 主要应用于B to
C模式中保障支付信息的安全性。SET协议本身比较复杂，设计比较严格，安全性高，
它能保证信息传输的机密性、真实性、完整性和不可否认性。SET协议是PKI框架下的一个典型实现，同时也在不断升级和完善， 如SET
2.0将支持借记卡电子交易。</div>
</div>
<img src ="http://www.blogjava.net/renyangok/aggbug/163242.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/renyangok/" target="_blank">保尔任</a> 2007-11-26 17:04 <a href="http://www.blogjava.net/renyangok/archive/2007/11/26/163242.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>RSA加密算法</title><link>http://www.blogjava.net/renyangok/archive/2007/11/21/162056.html</link><dc:creator>保尔任</dc:creator><author>保尔任</author><pubDate>Wed, 21 Nov 2007 03:52:00 GMT</pubDate><guid>http://www.blogjava.net/renyangok/archive/2007/11/21/162056.html</guid><wfw:comment>http://www.blogjava.net/renyangok/comments/162056.html</wfw:comment><comments>http://www.blogjava.net/renyangok/archive/2007/11/21/162056.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/renyangok/comments/commentRss/162056.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/renyangok/services/trackbacks/162056.html</trackback:ping><description><![CDATA[RSA算法是一种非对称密码算法，所谓非对称，就是指该算法需要一对密钥，使用其中一个加密，则需要用另一个才能解密。<br />
RSA的算法涉及三个参数，n、e1、e2。<br />
其中，n是两个大质数p、q的积，n的二进制表示时所占用的位数，就是所谓的密钥长度。<br />
e1和e2是一对相关的值，e1可以任意取，但要求e1与(p-1)*(q-1)互质；再选择e2，要求(e2*e1)mod((p-1)*(q-1))=1。<br />
(n及e1),(n及e2)就是密钥对。<br />
<br />
RSA加解密的算法完全相同,设A为明文，B为密文，则：A=B^e1 mod n；B=A^e2 mod n；<br />
e1和e2可以互换使用，即：<br />
A=B^e2 mod n；B=A^e1 mod n；<br />
<br />
<br />
补充回答：<br />
对明文进行加密，有两种情况需要这样作：<br />
1、您向朋友传送加密数据，您希望只有您的朋友可以解密，这样的话，您需要首先获取您朋友的密钥对中公开的那一个密钥，e及n。然后用这个密钥进行加密，这样密文只有您的朋友可以解密，因为对应的私钥只有您朋友拥有。<br />
2、您向朋友传送一段数据附加您的数字签名，您需要对您的数据进行MD5之类的运算以取得数据的"指纹"，再对"指纹"进行加密，加密将使用您自己的密钥对中的不公开的私钥。您的朋友收到数据后，用同样的运算获得数据指纹，再用您的公钥对加密指纹进行解密，比较解密结果与他自己计算出来的指纹是否一致，即可确定数据是否的确是您发送的、以及在传输过程中是否被篡改。<br />
<br />
密钥的获得，通常由某个机构颁发（如CA中心），当然也可以由您自己创建密钥，但这样作，您的密钥并不具有权威性。<br />
<br />
计算方面，按公式计算就行了，如果您的加密强度为1024位，则结果会在有效数据前面补0以补齐不足的位数。补入的0并不影响解密运算。<br />
<br />
———————————在python中用M2Crypto包实现————————————<br />
这个程序是验证M2Crypto替换POW的效率（时间和内存），结论如下：<br />
<pre>Lib        Time(500x100 times sign&amp;verify)  Mem python used (before threads start)   Mem python used (after thread run, threads closed but python doesn't exit)<br />
<br />
POW                41s                            3.3M - 3.4M                                     3.9M - 4.0M<br />
M2Crypto0.18       44s                            3.3M - 3.4M                                     3.9M - 4.0M<br />
No RSA, just a+b   &lt;1s                            3.3M - 3.4M                                     3.9M - 4.0M</pre>
<br />
<br />
from M2Crypto import BIO, RSA, EVP<br />
import config<br />
import POW<br />
import datetime, threading, time<br />
<br />
private_key = """-----BEGIN RSA PRIVATE KEY-----<br />
MIIBPAIBAAJBAMC3aHYeDQNksuWKNd7amAZWvawuyUFOsbEUN4bTWWPC0noozS1o<br />
d3Bal8q8W7SXx1oDihbm90t90HpwV++RFnECAwEAAQJBAKvyeQf6pA3FCUF44bvn<br />
OgFd33oDfJoChtTCfxCS/ozcuFG9mFeKjqxbqTDrBtrX3Stx644iZV/AFZSQoWFP<br />
smkCIQDqeTC6R6cv4VGyvdzbfEHaY0r8hIdpFOQwJt/462giXwIhANJozqGUq5TG<br />
LcJz4wNVWZgn6FJPjCbxrM4Oaqr+GJkvAiAJOES7PnALiO+eeKrDkqpAPSFItqlg<br />
b2rdndm2vwL0PwIhALHsAl7MEtM5SdSWni5ha+OoS2He9kqwLkoIEtcJCs/tAiEA<br />
qIPk7tyVeR8JlTSUiFTus1JjYDmKObJ+ZyfeJucO3No=<br />
-----END RSA PRIVATE KEY-----"""<br />
<br />
public_key = """-----BEGIN PUBLIC KEY-----<br />
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMC3aHYeDQNksuWKNd7amAZWvawuyUFO<br />
sbEUN4bTWWPC0noozS1od3Bal8q8W7SXx1oDihbm90t90HpwV++RFnECAwEAAQ==<br />
-----END PUBLIC KEY-----"""<br />
<br />
data = "12dfuilfalfjadoighaiwlhtfalihsalkahjflkajgaklaklhalfhawklfhawkfasdaksjlhawifhyawiofhawifhquioghaeughautguoqhfaiofghaiourthq3iothfioahaiwofhawiorhawiofahfioadfhadwiofuawiofaiofhaiofhasdiofhasifhifhifhasdkljfhsadklfasdhashfilsahffhasdkfasdfj;asdfjdas;klfjnsdklnsadklfnsdklfhadl;fsj;lasjf;lkdfjdsa;klfjdlkfjdkfjds;lafhaofhawifwaqfniowfnwafldsaknfdaslkfndaklfjiojioajfaiopfnaklfnaklnfklanfalkfnklanklfdnlakfnklafnaklfnaklfnsklafnkldafinaigvn0irnifgjhaoihaiofjaoifjoiaje[qtobeornottobethat'saquestionjapfjpiofjapfiajipawjaiopjaproiajlafjasdklfjasdklfjdalfjlaa;fjad;lff'alfjkal;fja'luiopdfxghfxdgfdyuiop[afhdmfn9zfinkbdfrmh;io/ljrpjilnj[RQ"<br />
<br />
threads = 500<br />
times = 100<br />
<br />
def verify():<br />
&nbsp;&nbsp;&nbsp; rsa = RSA.load_key_string(private_key)<br />
&nbsp;&nbsp;&nbsp; digest = EVP.MessageDigest('sha1')<br />
&nbsp;&nbsp;&nbsp; digest.update(data)<br />
&nbsp;&nbsp;&nbsp; signature = rsa.sign(digest.digest())<br />
<br />
&nbsp;&nbsp;&nbsp; rsa_pub = RSA.load_pub_key_bio(BIO.MemoryBuffer(public_key))<br />
&nbsp;&nbsp;&nbsp; digest2 = EVP.MessageDigest('sha1')<br />
&nbsp;&nbsp;&nbsp; digest2.update(data)<br />
&nbsp;&nbsp;&nbsp; if not rsa_pub.verify(digest2.digest(), signature):<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; raise Exception("Failed!")<br />
<br />
def verifyByPOW():<br />
&nbsp;&nbsp;&nbsp; digest = POW.Digest(POW.SHA1_DIGEST)<br />
&nbsp;&nbsp;&nbsp; digest.update(data)<br />
&nbsp;&nbsp;&nbsp; private = POW.pemRead(POW.RSA_PRIVATE_KEY, private_key, 'pass')<br />
&nbsp;&nbsp;&nbsp; signature = private.sign(digest.digest(), POW.SHA1_DIGEST)<br />
<br />
&nbsp;&nbsp;&nbsp; public = POW.pemRead(POW.RSA_PUBLIC_KEY, public_key, 'pass')<br />
&nbsp;&nbsp;&nbsp; digest2 = POW.Digest(POW.SHA1_DIGEST)<br />
&nbsp;&nbsp;&nbsp; digest2.update(data)<br />
&nbsp;&nbsp;&nbsp; if not public.verify(signature, digest2.digest(), POW.SHA1_DIGEST):<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; raise Exception("Failed!")<br />
<br />
class ThreadTest(threading.Thread):<br />
&nbsp;&nbsp;&nbsp; def __init__(self, index, times):<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; threading.Thread.__init__(self)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; self.times = times<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; self.id = index<br />
<br />
&nbsp;&nbsp;&nbsp; def run(self):<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a = 1478904489<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for i in xrange(times):<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a += a<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; verify()<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #verifyByPOW()<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; print "Thread test %s Finished at %s" % (self.id, str(datetime.datetime.now()))<br />
<br />
def main():<br />
&nbsp;&nbsp;&nbsp; print ""n&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;"<br />
&nbsp;&nbsp;&nbsp; start = datetime.datetime.now()<br />
<br />
&nbsp;&nbsp;&nbsp; for i in xrange(threads):<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t = ThreadTest(i, times)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t.start()<br />
<br />
&nbsp;&nbsp;&nbsp; time.sleep(300)<br />
&nbsp;&nbsp;&nbsp; end = datetime.datetime.now()<br />
&nbsp;&nbsp;&nbsp; # see the used time between two package<br />
&nbsp;&nbsp;&nbsp; print "total time is %s" % (end - start)<br />
&nbsp;&nbsp;&nbsp; # use linux tools, such as command "top" to see the memory useage before and after the method to see whether M2Crypto<br />
&nbsp;&nbsp;&nbsp; # has momery leak(assume POW has no memory leak problem)<br />
&nbsp;<br />
if __name__ == '__main__':<br />
&nbsp;&nbsp;&nbsp; main()<br />
<img src ="http://www.blogjava.net/renyangok/aggbug/162056.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/renyangok/" target="_blank">保尔任</a> 2007-11-21 11:52 <a href="http://www.blogjava.net/renyangok/archive/2007/11/21/162056.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>RBAC和ACL的比较</title><link>http://www.blogjava.net/renyangok/archive/2006/12/06/85840.html</link><dc:creator>保尔任</dc:creator><author>保尔任</author><pubDate>Wed, 06 Dec 2006 06:30:00 GMT</pubDate><guid>http://www.blogjava.net/renyangok/archive/2006/12/06/85840.html</guid><wfw:comment>http://www.blogjava.net/renyangok/comments/85840.html</wfw:comment><comments>http://www.blogjava.net/renyangok/archive/2006/12/06/85840.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/renyangok/comments/commentRss/85840.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/renyangok/services/trackbacks/85840.html</trackback:ping><description><![CDATA[
		<p>    RBAC：Role Based Access Control，翻译过来基本上就是基于角色的访问控制系统。<br />    ACL：Access Control List，访问控制列表，是前几年盛行的一种权限设计，它的核心在于用户直接和权限挂钩。RBAC的核心是用户只和角色关联，而角色代表对了权限，这样设计的优势在于使得对用户而言，只需角色即可以，而某角色可以拥有各种各样的权限并可继承。ACL和RBAC相比缺点在于由于用户和权限直接挂钩，导致在授予时的复杂性，虽然可以利用组来简化这个复杂性，但仍然会导致系统不好理解，而且在取出判断用户是否有该权限时比较的困难，一定程度上影响了效率。<br />我想理一理思路，看看ACL与RBAC的区别:</p>
		<p>还是以部门新闻来讨论，对于静态授权，在系统设计做需求分析的时候，往往就可以确定一个系统角色的种类，像新闻系统中，根据需求，可能会有新闻发布者(Publisher)，新闻审核者(Reviewer)，新闻浏览者(Visitor)，管理员(Manager)以及超级管理员(Administrator)。</p>
		<p>在设计的时候我们也已经把这些角色与相应的一些Operation绑定在一起。<br />如：Publisher拥有Publish_Operation Modify_Operation<br />Reviewer拥有Review_Operation Modify_Operation Delete_Operation<br />Visitor拥有Visit_Operation,<br />Manager拥有Create_News_System_Instance_Operation <br />Modify_News_System_Instance_Operation <br />Delete_News_System_Instance_Operation<br />Administrator负责Create_User_Operation <br />Delete_User_Operation <br />Assign_Permission_Operation <br />Deassign_Permission_Operation <br />Assign_Role_Operation <br />Deassign_Role_Operation</p>
		<p>在授权时，往往先为一个用户(USER)，赋予一个角色，如:Manager.这样，USER就拥有了对所有News_Instance(也就是部门新闻)操作的权限。现在假设用户(UserA)访问Create_News_System_Instance功能来创建一个新的新闻实例，叫做采购部门新闻.因为我们在设计的时候就确定，该功能只能由Manager来访问，于是，系统中权限的判断部分会首先判断当前用户(UserA)是否Manager角色，是的话就允许访问，否则显示没有授权的错误信息。</p>
		<p>所以，对于Manager这样的应用:<br />[1]在设计的时候，我们就将这样的角色与相应的Permissions(AlistofSubject-Operationpairs)关联在一起了，这里的Subject是所有的新闻实例(News_Instance),Operation就是Create,Modify以及Delete.<br />[2]在授权的时候，超级管理员(Administrator)可以利用Assign_Role_Operation将用户(User)与Manager这个角色关联起来。这样，User就拥有了对所有新闻实例的Create,Modify以及Delete操作的权限。<br />[3]在权限判断的时候，RBAC系统首先判断当前用户是否是设计时确定的角色(这里是Manager),如果是，就允许用户访问，否则就拒绝访问，并显示错误信息。</p>
		<p>
				<br />对于Publisher这样的角色有些不同，Publisher这个角色只与Operation绑定在一起，并没有与具体的Subject相关联，因此，在授权的时候，还需要指定相应的Subject.</p>
		<p>所以，对Publisher这样只能事先确定Operation的应用来说:<br />[1]在设计的时候，我们只能确定该角色能进行哪些操作，而不能确定这些操作实施的对象。<br />[2]在授权的时候:<br />[2.1]首先将Publisher与Subject关联,如将Publisher与采购部门新闻关联产生:采购部门新闻_News_Publisher的角色<br />[2.2]Administrator为用户(User)授于采购部门新闻_News_Publisher角色。从而User拥有了对"采购部门新闻"的发布权限<br />[3]在权限判断的时候，用户访问采购部门新闻_News_Publish_Operation,系统首先判断该用户是否采购部门新闻_News_Publisher?如果是，就允许用户访问，否则就拒绝访问，并显示错误信息。<br />这里用到的方法可能是这个样子:<br />booleancheckPermission(采购部门新闻,Publish_Operation,User){<br />Listpublishers=RBAC.findRole(newPermission(采购部门新闻,Publish_Operation));<br />if(publishers==null)returnfalse;<br />for(Iteratorit=publishers.iterator;it.hasNext();){<br />Rolepublisher=(Publisher)it.next();<br />if(publisher.isAssignedWithUser(User)){<br />returnture;<br />}<br />}<br />returnfalse;<br />}</p>
		<p>假如说，不采用RBAC的做法，考虑一下，使用ACL，那又会是什么样子呢?<br />对于Manager那样能在设计时就确定Subject与Operation的角色，我认为没有必要考虑ACL了.对于Publisher这样，只能事先确定Operation的角色，我们来做个对比.权限系统要灵活，但是也要简洁，要不然就很可能导至失控。因为嵌套的层次太多，有可能发生不可预知的情况.有一天管理员可能会莫明的发现，怎么这个人会有这个权限的?<br />所以，我认为在RBAC里不支持Role的层级关系为妙。</p>
		<p>好了，现在来看看ACL对Publisher应用<br />这里指的ACL是直接将User或Group与Subject关联的做法。<br />User与Subject是多对多的情况，<br />Group与Subject也是多对多的情况，<br />同样的，User与Group也是多对多的情况。</p>
		<p>现在，还是以采购部门新闻为例:<br />[1]在授权的时候，可以有以下操作:<br />[1.1]将User与Subject关联在一起,但是要指定相应的Operation.<br />如:assignPermission(采购部门新闻,Publish_Operation,User)<br />[1.2]将Group与Subject关联在一起:<br />如:assignPermission(采购部门新闻,Publish_Operation,Group)<br />[1.3]将User与Group关联<br />如:<br />assignUserGroup(User,Group)</p>
		<p>[2]在权限判断的时候，用户访问采购部门新闻_News_Publish_Operation，系统做如下检查:<br />booleancheckPermission(采购部门新闻,Publish_Operation,User){<br />booleanhasPermission=false;<br />//usersinclude:<br />//1.PermissiondirectassignedUsers<br />//2.Theuserassignedwiththegroupsthatassignedwithpermission<br />Listusers=getAssignedUsers(newPermission(采购部门新闻,Publish_Operation));<br />hasPermission=users.contains(User)?true:false;<br />}</p>
<img src ="http://www.blogjava.net/renyangok/aggbug/85840.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/renyangok/" target="_blank">保尔任</a> 2006-12-06 14:30 <a href="http://www.blogjava.net/renyangok/archive/2006/12/06/85840.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>漫谈权限系统之技术策略以及基于RBAC的实现 </title><link>http://www.blogjava.net/renyangok/archive/2006/12/06/85838.html</link><dc:creator>保尔任</dc:creator><author>保尔任</author><pubDate>Wed, 06 Dec 2006 06:21:00 GMT</pubDate><guid>http://www.blogjava.net/renyangok/archive/2006/12/06/85838.html</guid><wfw:comment>http://www.blogjava.net/renyangok/comments/85838.html</wfw:comment><comments>http://www.blogjava.net/renyangok/archive/2006/12/06/85838.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/renyangok/comments/commentRss/85838.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/renyangok/services/trackbacks/85838.html</trackback:ping><description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp; 摘要: 根据上面的需求描述以及对需求的分析，我们得知通常的一个中小型系统对于权限系统所需实现的功能以及非功能性的需求，在下面我们将根据需求从技术角度上分析实现的策略以及基于目前两种比较流行的权限设计思想来讨论关于权限系统的实现。																						1.1.       																				技术策略									...&nbsp;&nbsp;<a href='http://www.blogjava.net/renyangok/archive/2006/12/06/85838.html'>阅读全文</a><img src ="http://www.blogjava.net/renyangok/aggbug/85838.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/renyangok/" target="_blank">保尔任</a> 2006-12-06 14:21 <a href="http://www.blogjava.net/renyangok/archive/2006/12/06/85838.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item><item><title>漫谈权限系统之基于ACL的实现 </title><link>http://www.blogjava.net/renyangok/archive/2006/12/06/85835.html</link><dc:creator>保尔任</dc:creator><author>保尔任</author><pubDate>Wed, 06 Dec 2006 06:17:00 GMT</pubDate><guid>http://www.blogjava.net/renyangok/archive/2006/12/06/85835.html</guid><wfw:comment>http://www.blogjava.net/renyangok/comments/85835.html</wfw:comment><comments>http://www.blogjava.net/renyangok/archive/2006/12/06/85835.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/renyangok/comments/commentRss/85835.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/renyangok/services/trackbacks/85835.html</trackback:ping><description><![CDATA[&nbsp;&nbsp;&nbsp;&nbsp; 摘要: 转自：http://myrss.easyjf.com/html/20060226/1140942877093115.htm基于														ACL														的实现																																																														ACL...&nbsp;&nbsp;<a href='http://www.blogjava.net/renyangok/archive/2006/12/06/85835.html'>阅读全文</a><img src ="http://www.blogjava.net/renyangok/aggbug/85835.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/renyangok/" target="_blank">保尔任</a> 2006-12-06 14:17 <a href="http://www.blogjava.net/renyangok/archive/2006/12/06/85835.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>