序列号加密中的数学算法

序列号加密中的数学算法

数学算法一项都是密码加密的核心,但在一般的软件加密中,它似乎并不太为人们关心,因为大多数时候软件加密本身实现的都是一种编程的技巧。但近几年来随着序列号加密程序的普及,数学算法在软件加密中的比重似乎是越看越大了。
  我们先来看看在网络上大行其道的序列号加密的工作原理。当用户从网路上下载某个Shareware-共享软件后,一般都有使用时间上的限制,当过了共享软件的试用期后,您必须到这个软件的公司去注册后方能继续使用。注册过程一般是用户把自己的私人信息(一般主要指名字)连同信用卡号码告诉软件公司,软件公司会根据用户的信息计算出一个序列码,在用户得到这个序列号后,按照注册需要的步骤在软件中输入注册信息和注册码,其注册信息的合法性由软件验证通过后,软件就会取消掉本身的各种限制,这种加密实现起来比较简单,不需要额外的成本,用户购买也非常方便,在互联网上的软件80%都是以这种方式来保护的。
  我们注意到软件验证序列号的合法性过程,其实就是验证用户名和序列号之间的换算关系是否正确的过程。其验证最基本的有两种,一种是按用户输入的姓名老生成注册码,再同用户输入的注册码比较,公式表示如下:
  序列号=F(用户名)
  但这种方法等于在用户软件中再现了软件公司生成注册码的过程,实际上是非常不安全的,不论其换算过程多么复杂,解密者只需把您的换算过程从程序中提取出来就可以编制一个通用的注册程序。
  另外一种是通过注册码来验证用户名的正确性,公式表示如下:
  用户名称=F逆(序列号)(如ACDSee)
  这其实是软件公司注册码计算过程的反算法,如果正向算法与反向算法不是对称算法的话,对于解密者来说,的确有些困难,但这种算法相当不好设计。
  于是有人考虑到以下的算法:
  F1(用户名称)=F2(序列号)
  F1、F2是两种完全不同的算法,但用户名通过F1算法的计算出的特征等于序列号通过F2算法计算出的特征字,这种算法在设计上比较简单,保密性相对以上两种算法也要好的多。如果能够把F1、F2算法设计成不可逆算法的话,保密性相当好;可一旦解密者找到其中之一的反算法的话,这种算法就不安全了。一元算法的设计看来再如何努力也很难有太大的突破,那么二元呢?
  特定值=F(用户名,序列号)
  这个算法看上去相当不错,用户名称与序列号之间的关系不再那么清晰了,但同时也失去了用户名于序列号的一一对应关系,软件开发者必须自己维护用户名称与序列号之间的唯一性,但这似乎不是难以办到的事,建个数据库就好了。当然您也可以根据这一思路把用户名称和序列号分为几个部分来构造多元的算法。
  特定值=F(用户名1,用户名2,…序列号1,序列号2…)
  现有的序列号加密算法大多是软件开发者自行设计的,大部分相当简单。而且有些算法作者虽然下了很大的功夫,效果却往往得不到它所希望的结果。其实现在有很多现成的加密算法可以用,如RSADES,MD4,MD5,只不过这些算法是为了加密密文或密码用的,于序列号加密多少有些不同。在这里试举一例,希望有抛砖引玉的作用:
  1、在软件程序中有一段加密过的密文S
  2、密钥=F(用户名、序列号)用上面的二元算法得到密钥
  3、明文D=F-DES(密文S、密钥)用得到的密钥来解密密文得到明文D
  4、CRC=F-CRC(明文D)对得到的明文应用各种CRC统计
  5、检查CRC是否正确。最好多设计几种CRC算法,检查多个CRC结果是否都正确
  用这种方法,在没有一个已知正确的序列号情况下是永远推算不出正确的序列号的。
  mp,lstrlen,memcpy(限于NT)。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

钴60

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值