单向加密的一点思考(md5)

在百度网盘中上传文件的时候、我发现那上传的速度真是一个快。

快到让我吃惊之外、还多了一份好奇。使用百度上传文件的时候的用户体验是非常不错的

除了带宽的问题、这其中是不是还有些别的呢。在我学习到的知识当中我自然而然的想到

了单向加密算法(MD5)。

我们知道MD5加密的一个特征就是:雪崩效应(一旦被加密的内容发生一丁的点变化、将引起加密结果巨大的变化)

我们不妨设想一下:

在用户的本机电脑上有3个文件(Test1.txt | Test2.txt | Test3.txt)、用户只是修改了其中的一个:Test3.txt

尽管另外的2个用户并没有做任何修改、但是用户也把它拖入了上传的队列当中。

我的思考:

假设(Test1.txt | Test2.txt | Test3.txt)这3个文件服务器上已经存在一份了、只是Test3.txt这个文件不是最新

的。为了得到最好的用户体验最好的做法就是跳过(Test1.txt | Test2.txt)这2个文件,直接上传Test3.txt就行了。

但是我们首先需要解决的一个问题就是:我们知道Test3.txt被用户修改了、但是电脑并不清楚。

此处我再次假设一下:

如果我们有一种方法可以比对(服务器上已经存的文件 和用户端上需要上传的同名文件的)特征码(即:MD5加密结果)

:如果两者MD5加密的结果一致我们就认为该文件没有被修改、所以不需要上传。

:如果两者MD5加密的结果不一致我们就认为该文件被修改了、需要上传。

这样一来本来需要上传3个文件、现在只需上传一个文件(被修改的那一个)就可以了、如此一来速度显然要快上很多了。

总结:

百度网盘上传速度如此之快 自然离不了那些高大上的技术,并非我所能了解的,此不必多说了。

我的想法有些异想天开,但不并妨碍我求知的欲望... (^V^)

下面是一个有关于MD5的一个小例子:

第1次向 1.txt 写入的是"12345678" ;第2次向 1.txt写入的是 "12345678 "多一个空格.

[[email protected] wbq]# touch 1.txt

[[email protected] wbq]#

[[email protected] wbq]# echo "12345678" > 1.txt

[[email protected] wbq]#

[[email protected] wbq]# cat 1.txt

12345678

[[email protected] wbq]#

[[email protected] wbq]# md5sum 1.txt

23cdc18507b52418db7740cbb5543e54  1.txt

[[email protected] wbq]#

[[email protected] wbq]# md5sum 1.txt

23cdc18507b52418db7740cbb5543e54  1.txt

[[email protected] wbq]#

[[email protected] wbq]# echo "12345678 " > 1.txt

[[email protected] wbq]#

[[email protected] wbq]# md5sum 1.txt

0a248abc4cfd2c83de82a5748b141cea  1.txt

时间: 2024-10-11 12:33:04

单向加密的一点思考(md5)的相关文章

数字签名、数字证书、对称加密算法、非对称加密算法、单向加密(散列算法)

数字签名是什么? 1. 鲍勃有两把钥匙,一把是公钥,另一把是私钥. 2. 鲍勃把公钥送给他的朋友们----帕蒂.道格.苏珊----每人一把. 3. 苏珊给鲍勃写信,写完后用鲍勃的公钥加密,达到保密的效果. 4. 鲍勃收信后,用私钥解密,看到信件内容. 5. 鲍勃给苏珊回信,写完后用Hash函数,生成信件的摘要(digest). 6. 然后,鲍勃使用私钥,对这个摘要加密,生成"数字签名"(signature). 7. 鲍勃将这个签名,附在信件下面,一起发给苏珊. 8. 苏珊收信后,取下数

基于http协议通信的APP安全策略的一点思考

声明一点,我没做过过任何商业APP,以下想法仅仅是个人业余时间的一点思考,若你是专业人员,不吝赐教. 概述 微信开发过程中,会使用到微信服务器提供的API,这些API都是基于HTTP协议调用的,为什么我们自己的APP服务器不采用这种方式呢? 这种方式最直观的好处就是,API设计得足够好时,服务器只需要开发一次,无论前端是 WEB,APP ,APK...都通过http调用API请求数据并响应. 这种方式类似于传统C/S模型的开发,服务端/客户端定义相同序列的数据结构(称之为通信协议),差别在于现在

单向加密 对称加密 非对称加密

单向加密: 单向加密又称为不可逆加密算法,在加密过程中不使用密钥,明文由系统加密处理成密文,密文无法解密.一般适合于验证,在验证过程中,重新输入明文,并经过同样的加密算法处理,得到相同的密文并被系统重新认证.广泛使用于口令加密. 一:base64 常见于邮件.http加密,截取http信息,你就会发现登录操作的用户名.密码字段通过BASE64加密的. 主要就是BASE64Encoder.BASE64Decoder两个类 BASE加密后产生的字节位数是8的倍数,如果不够位数以=符号填充 二:md5

【WP开发】加密篇:单向加密

单向加密,简单地说就是对数据进行哈希处理,平时我们见得较多的有MD5.SHA1等,都属于单向加密.上一篇文章中,老周跟大家扯了有关双向加密的事,本文咱们就扯一下单向加密吧. 要对数据进行哈希处理也不是很复杂,应该说挺easy的.与双向加密的处理有着相同的规律. 要进行哈希运算,你应该: 1.调用HashAlgorithmProvider类的OpenAlgorithm()方法产生一个HashAlgorithmProvider实例.OpenAlgorithm方法是公共静态的,可以直接调用,参数是一个

java加密算法入门(一)-算法概念及单向加密

说起加密,我的第一印象就是电视剧各种密码本破解解密的场景,这两天在看加密相关的东西,做下笔记以便以后查看,也提供给大家个参考. 本文是java加密的第一篇,主要讲述下消息编码Base64以及简单的消息摘要算法MD5,SHA,MAC等,如果有不对的地方还望大家指正. 1.算法概念简述 1.1.加密算法分类 消息编码:Base64 消息摘要:MD类,SHA类,MAC 对称加密:DES,3DES,AES 非对称加密:RSA,DH密钥交换 数字签名:RSA signature,DSA signature

关于后台系统自动生成的一点思考

大量实践发现后台管理程序,其实90%的代码都是相同的,当然是在抛弃复杂逻辑业务的情况下,那么如何能高效的节约这些时间呢,那就是接下来我要说的,对于后台系统自动生成的一些思考. 适用情景: 1.表编号id为自增(基于现在大部分表编号都是自增的情况): 2.没有太复杂业务关联关系,比如表的某一个字段,存储了一个json对象,为了平衡后台用户使用,需要友好的分段展示给用户的定制ui界面:还比如表中存储了外键的多个id,但为了方便用户使用,只能已标签name的方式,给用户展示,等等这些超强业务黏合逻辑的

关于前端的一点思考

关于前端的一点思考 Author:tkorays 最近写前端代码,写着写着就突然开始惆怅.忧伤.愤怒.发狂,我TMD到底在干什么啊! 很多东西写了n遍了,但是还是在不停地写着.自己写过的代码也不想再修改完善.重新利用,只是觉得,可能重新写一遍可能要好点.面对这很多库以及框架,虽然喜爱,但是也是有所顾忌,我只要使用其中的一个功能,根本不需要引入这么大的整个库. 事实上,我们可能在动手写任何代码之前,先要思考下,我们到底要的是什么! 0x00 界面真的需要这么炫酷么 在使用某个界面库之前,我们可能先

单向加密和双向加密

在现阶段,有两种加密方式,单向加密和双向加密.双向加密是加密算法中最常用的,它将可以直接理解的明文数据加密为不可直接理解的密文数据,然后,在需要的时候,可以使用一定的算法将这些加密以后的密文解密为原来可以理解的明文.双向加密适合于隐秘通信,例如,用户在网上购物时,需要向网站提交信用卡密码,用户当然不希望自己的数据直接在网上明文传送,因为这样很可能被别的用户“偷听”,用户希望自己的信用卡密码是通过加密以后,再在网络传送,因此网站接收到用户的数据以后,通过解密算法就可以得到准确的信用卡账号.单向加密

c#加密 可逆与不可逆MD5 加密

1.方法一 (不可逆加密) srxljl public string EncryptPassword(string PasswordString,string PasswordFormat )     {      string   encryptPassword = null;     if (PasswordFormat="SHA1"){           encryptPassword=FormsAuthortication.HashPasswordForStoringInCo