精华内容
下载资源
问答
  • 翻译A Digital Signature Based on a Conventional Encryption Function,在本文中,Merkle提出了著名的Merkle hash树,它在其它方面也有不少应用,值得一读。基于常规加密函数的数字签名 By Ralph C....

    翻译A Digital Signature Based on a Conventional Encryption Function,在本文中,Merkle提出了著名的Merkle hash树,它在其它方面也有不少应用,值得一读。

    基于常规加密函数的数字签名

    By Ralph C.Merkle
    Elxsi
    2334 Lundy Place
    San Jose, CA 95131

    摘要

    本文描述了一种新的基于常规加密函数(比如DES)的数字签名,它和底层加密函数具有相同的安全性——其安全性不是建立在因式分解(factoring)的复杂性基础上,并且避免了模运算(modular arithmetic)的高计算代价。签名系统可以签署任意数量的消息,并且签名大小是消息个数的对数函数。在一个典型的系统中,签名大小可能从几百个字节到几千个字节,生成一个签名可能需要把底层加密函数执行几百到几千次。

    介绍

    数字签名系统已经证明[1,3,5,10],仅依赖常规加密函数(或者单向函数),都没有比较成功的为基于像因式分解[2,4]这样更加复杂的数学难题的系统提供便利性。对安全性仅基于单向函数的系统感兴趣的一个重要原因是,这类函数的存在性是可以保证的,然而因式分解的复杂性和更有效的因式分解算法依然是被广泛研究的待解问题。这并不是纯学术兴趣的问题,特别是鉴于大量的“不可攻破”的加密系统已经被相继攻破。
    第二个优点是,与需要模运算的系统相比的简化计算代价: DES(Data Encryption Standard)的软件实现比模N的指数运算更快,因此一个基于DES的数字签名系统也同样有优势。这种代价的节约在硬件实现上更明显,因为DES芯片已经可以从许多制造商低价买到,并在许多已有系统中运用。当嵌入到一个已有DES芯片(或者任何硬件实现的常规加密函数)的系统中时,这种新的数字签名系统速度确实很快。
    为了确保本文是完备的,我们首先简单回顾一些单向函数和一次性签名的已知结果,然后介绍一次性签名系统如何以一种新的方式来提供一个数字签名系统,它克服了阻碍这种方法被接受和使用的限制和缺陷。

    单向函数

    单向函数F是一个很容易计算,但难以反向求解的函数。给定x,计算y=F(x)是很容易的,而给定y,计算任何满足F(x)=y的x是困难的。
    单向函数可以基于常规加密函数,因为通过明文(plain text)和密文(cipher text)来破解密钥(key)也是非常困难的。如果我们定义一个常规加密函数为:Skey (plaintext)=ciphertext,这样通过Sx (0)=y我们就定义了一个单向函数F(x)=y。也就是,我们用x做为密钥来加密一个常数,输出密文就是单向函数的输出结果。现在给定y来破解x就等同于,已知plaintext=0和ciphertext=y的情况下求解key。
    单向hash函数——比如,一个接受任意大小输入(比如几千KB)并产生固定大小输出(比如64bit)的单向函数——以类似的方式,可以基于常规加密函数的重复应用。设计单向函数时需要注意:大多数方法都不能有效的抵御平方根攻击(square root attack)。比如,我们希望从112bit简化到64bit(使用DES),最明显的技术就是把112bit分解为两个56bit的块,然后重复加密一个常数。也就是,设这两个56bit的块分别为K1和K2,然后计算Sk2 (Sk1 (0))。不幸的是,使用“meet in the middle”和”square root”攻击,在2^28次计算内就可能确定出产生相同结果的新K1’和K2’。然而这种攻击也是可以避免的,重要的是要知道它们的存在,并必须防御之。
    我们假设一个安全的单向hash函数,它可能是基于某些常规加密函数,并用F来标识。

    签署1bit的消息

    本节和下一节为不熟悉的读者简单介绍一次性签名,这两节可以跳过而不会失去连续性。

    【关于一次性签名,可以参看wiki 上的介绍】

    某君A可以使用下面的协议为某君B签署1bit的消息:首先,在预计算阶段,A使用F来单向加密两个值:x[1]和x[2],生成两个对应的值y[1]和y[2]。然后,A公布y[1]和y[2],但要保密x[1]和x[2]。最后,如果那1bit的消息是’1’,A通过把x[1]给B来签署它,如果是消息是’0’,则通过把x[2]给B来签署。
    如果那1bit的消息是’1’,那么B知道A发送的是x[1],于是B通过计算F(x[1])=y[1]来验证。因为F和y是公开的,任何人都可以通过上面的计算验证结果。因为只有A知道x[1]和x[2],B有关x[1]的知识暗示了x[1]是A给B的,基于前面的协定,这个事实证明了A签署了消息’1’。
    【译注:签署消息后,A将不能再次使用这两个x和y来签署其它的消息,因此这被称为一次性签名】

    签署几个bit的消息

    如果A生成了多个x和y,那么A就可以签署包含多个bit的消息。这就是Lamport-Diffie一次性签名[1]。签署一个n-bit的消息需要2n个x和2n个y。
    Merkle[3]提出了该方法的一个改进,将签名大小减少到了差不多1/2。A仅为要签署消息的每bit生成一个x和一个y,而不是2个x和两个y。如果消息的某一个bit为’1’,A公布对应的x值——然而如果该bit为’0’,A不公布任何数据。因为这样B可以假装没有收到某些x,于是把消息中的某些’1’ 假装是’0’,因此A还要必须签署消息中’0’bit的个数count。现在当B假装一个’1’bit是’0’bit时,他必须还要同时增加count的值——这是不可以的。因为count只有logn个bit,因此签名大小被差不多减少了1/2——从2n减少到n+logn。
    举个例子,如果我们想要签署一个8bit的消息‘0100 1110’,我们将首先计算0bit的个数(4),然后向原始的8bit消息追加一个3bit的count域(值为4),从而生成一个11bit的消息‘0100 1110 100’,我们通过公布x[2],x[5],x[6],x[7]和x[9]来签署它。B不能假装没有收到x[2],因为这样将会产生错误的消息——‘0000 1110 100’将含有5个’0’。同样的,假设没有收到x[9]将会产生错误的消息’0100 1110 000’,其count域显示消息应该没有’0’。没有这样的x组合,B可以假装没有收到它们从而编造一个合法的消息。
    【译注:不是很明白啊,比如说,B可以把消息 0100 1110 100假装是 0100 1100 101,即B假装第4个1是0,并且是5个0,不就刚好可以伪装了吗?】
    Winternitz[6]提出了一种改进,可以将签名大小减少到原来的几分之一。不通过计算y[1]=F(x[1])和y[2]=F(x[2])来签名1-bit的消息,A可以通过计算y[1]=F(F(F(F(x[1]))))和y[2]= F(F(F(F(x[2]))))来签名2-bit的消息。符号上,我们用上标来标记函数F的反复调用——F^3= F(F(F(x))),F^2= F(F(x)),F^1= F(x),F^0= x。如果A要签名消息m——肯定等于‘0’,‘1’,‘2’或者‘3’——A就公布F^m(x[1])和F^(3-m)(x[2])。通过计算满足F^n=y的n,B可以容易的验证A使用的函数F的次方。计算x[1]和x[2]的互补次方运算是必须的,因为B可以假装收到一个比A实际发送的更高的次方。也就是,如果A发送给B F^2(x[1]),那么B计算F^3(x[1]),然后假装称A发送的是F^3。然而这样的话,B必须计算F^0(x[2])——如果A发送的消息是‘3’的话,这个值就已经被A计算好并发给B了。因为A实际发送的是F^2(x[1]),这意味着B需要从F(x[2])计算出x[2]——显然不可以。公布x[1]和x[2]的互补次方运算其实就等同于在原Lamport-Diffie方法中公布或者x[1]和x[2]。
    尽管这个例子描述了如何签名一个从0到3的消息,它也能泛化,签名从0到n-1的消息,只需要计算F^(n-1)(x[1])和F^(n-1) (x[2])序列。
    上面Merkle提出的方法其实就是Winternitz一次性签名算法的特例。
    因此,由Lamport-Diffie提出的原签名系统,经过Merkle和Winternitz的改进,可以用来签名任意消息,并具有优秀的安全性。签名一条消息所需的内存和计算代价也是很合适的。不幸的是签名更多的消息就需要更多的x和y,因此公共文件中需要记录更多的信息(y)。要允许A签名1000个消息,大概需要10000个y——如果系统中有1000个用户,每个人都想签名1000个消息,这将使公共文件增加到几百MB——这是很不方便的,并将严重影响系统的应用。

    一次性无穷签名树

    新系统的基本思想是为一次性签名使用一个无穷树。简单起见,我们假设是二叉树,树的根放在一个公共文件中,易于验证。树的每个节点都执行三个功能:(1)验证左子节点,(2)验证右子节点,(3)签名一条消息。因为树中可以有无穷个节点,因此可以签名无穷多的消息。为了执行这三个功能,每个节点都必须包含3个签名信息——‘left’签名、‘right’签名和‘message’签名。‘left’签名用来签左子节点,‘right’签名用来签右子节点,‘message’签名用来签一条用户消息。
    使用下面的方式来编号节点会带来很多便利之处:
    根节点被编号为1;
    节点i的左子节点被编号为2i;
    节点i的右子节点被编号为2i+1;

    数字编号有很多便利的性质。它唯一的标识了树中的每个节点;可以很容易从根节点计算出左右子树;通过简单的除以2就可以方便的从子节点计算出根节点。注意,如果我们从节点1开始,并沿着左子节点遍历,经过的节点编号将是:1、2、4、8、16、32、64…
    我们使用更多的符号约定区分x和y,它们签名树中各节点代表的不同消息——特别的,我们使用x和y的3维数组:数组x[<节点编号>, <left, right 或者message>, <一次性签名的索引>]。如果我们使用原Lamport-Diffie方法(每条消息生成128个x),那么节点i上的所有x将会是:
    x[i,left, 1], x[i,left, 2], x[i,left, 3], …x[i,left, 128]
    x[i,right, 1], x[i,right, 2], x[i,right, 3], …x[i,right, 128]
    x[i,message, 1], x[i,message, 2], x[i,message, 3], …x[i,message, 128]

    我们把节点i上所有‘left’签名的x标记为:x[i, left, *]。类似的,我们用y[i, right, *]表示节点i上的‘message’签名的y【译注:我想这里应该是y[i, message, *]才对,对应与message签名】。我们把节点i上的所有x(left, right和message)标记为x[i, *, *]。
    给定一个签名,我们经常会对所有的y执行一次单向hash函数运算,因此我们使用符号F(y[i, right, *])来表示对节点i上的所有right签名执行单向hash函数F。
    因此,我们的基本数据结构为两个三维的无限数组x和y,其中y是使用F函数从x计算出来的。
    【译注:x[i,message, *]是待签署的用户消息的128bit签名,y[i,message, *]是x[i,message, *]执行hash计算(函数F)后的结果】
    我们经常会在给定节点上计算所有y的全hash值,先将F作用于每个签名上,然后再把F作用于这三个结果上,定义HASH(i):
    HASH(i) = F( F(y[i,left,*]), F(y[i,right,*]), F(y[i,message,*]) )
    这就是节点i的单向全hash值。它具有一个重要的性质:如果我们已经知道了HASH(i),这时有人声称给我们发送了y[i,*,*]值,通过重新计算这些函数我们就能确认他们发送的是正确的值(或者是错误的值)。如果从接收到的数据【译注:就是发送者声称的y[i,*,*]】计算出来的HASH(i)和我们已知的相匹配,我们就能确认收到了正确的y[i,*,*]值。
    在之前,A先把HASH(1)放到一个公共文件中。HASH(1)验证了A的验证树的根节点,并假设可以被任何人获得。
    现在我们可以描述A用签名i签署消息m,以及B验证签名的算法了。

    新的签名算法

    A和B事先商定待签署的消息M,A选择节点i来签署M。【译注:自下而上的验证算法,只要B验证:根据A发送的信息计算出来的HASH(1)和从公共文件取得的HASH(1)匹配,就说明A发送的是正确签名的消息,否则是没有正确签名的】
    1) A向B发送i和y[i, message, *]
    2) A向B发送x[i, message, *]的相应子集,表示签名了消息M【译注:回忆Lamport-Diffie算法,A需要根据消息M的单向hash的128bit结果来选择对应的x】
    3) 在校验y[i, message, *]时,B检查接收到的x[i, message, *]是否正确的签名了M【译注:通过x计算出y(F是公开的),检查是否和接收到的y一致】
    4) A向B发送F(y[i,left,*])、F(y[i,right,*])和F(y[i,message,*]
    5) A计算HASH(i),根据定义它等于:F( F(y[i,left,*]), F(y[i,right,*]), F(y[i,message,*]) )
    6) 如果i是1,B根据从 A接收到的值计算出的HASH(1),并检查是否与从公共文件中取得的相匹配,算法结束
    7) 如果i是偶数【译注:i是左子节点】
       A向B发送y[i/2,left,*]
       A向B发送正确的x[i/2,left,*]子集,表示签署了HASH(i)
       B计算HASH(i),并通过检查x和y[i/2,left,*]来检查HASH(i)是否被正确签署
    【译注:x和y都是从A接收的】
    8) 如果i是奇数【译注:i是右子节点】
       A向B发送y[i/2,right,*]
       A向B发送正确的x[i/2, right,*]子集,表示签署了HASH(i)
       B计算HASH(i),并通过检查x和y[i/2,right,*]来检查HASH(i)是否被正确签署
    9) A和B都将i除以2,并转到步骤4
    算法结束后,B将有log(i)个签名,其中一个是B真正想要的消息M的一次性签名,而其他的每一个签名验证了下一个签名的正确性和合法性——根签名的合法性可以通过公共文件证实。因此,这个一次性签名的审查轨迹从HASH(1)开始持续到HASH(i),最终结束于消息M的一次性签名。
    【译注:关于上面的算法是如何有效验证多个消息的,可以参考论文《method of providing digital signatures 》,其中有一个验证8个消息的例子,本文最后会译出这个例子】
    需要明确的是,这个“元系统”可以利用任何的一次性签名算法,并且对一次性签名算法的性能改进也会对该“元系统”产生相应的改进。没有特殊的理由认为当前的一次性签名系统已经很完善了,因此对一次性签名系统的进一步研究可能会获得有价值的性能改进。
    还需要明确的是,二叉树是随意选择的——使用K叉树也同样简单,可能实际也在用。二叉树需要log(i)个签名,而K叉树只需要logk (i)个——K越大,签名就越小。然而使用K叉树时,HASH(i)的计算将会是:
    F(
    F(y[i, fisrt-sub-node, *]),
    F(y[i, second-sub-node, *]),
    …,
    F(y[i, kth-sub-node, *]) ,
    F(y[i, message, *])
    )
    每个节点的计算会更耗时,因为所有k个子节点的y都需要重新计算,每个节点需要更多的内存来存储签名结果。因此k不能太大——它受限于这些限制。
    在增加k时最小化每个节点需要的附加验证信息,本身就是一个有趣的问题。如上所述,每个节点所需要的签名信息随着k线性增长。在作者之前的“tree-signature”方法[3, 7,P170]中,这已经被减少到log(k)。把这两个系统合并到一个系统中看起来很合适,并且可以有效的利用大的k值。尽管都使用了树,作者之前的“tree-signature”方法和本方法是很不相同的。有意思的是,Goldwasser,Micali和Rivest[8,9]也在数字签名系统中使用了类似于树的结构来达到可行的理论性质。他们的签名系统是“…based on the existence of a “claw-free” pair of[trapdoor] permutations”,通过两个大素数的乘法而构建(就像RSA算法那样)。
    最后,有些读者可能认为两个三维无限数组x和y会让用户A存储起来很不方便——因此最好有个压缩机制。数组y是从数组x计算而来的,因此数组y其实不比存储。数组x是用户A随机选择的,A也可能使用一个安全的伪随机序列来生成x。特别的,A可能这样生成x[i,j,k]:先连接i,j和k,然后使用一个常规加密函数和安全密钥key来加密这个bit串:x[i,j,k] = SA’s security key(<i, j, k>)。如果我们使用DES,A的密钥只需要56bit。即使许多x都已经公开了(随着签名许多不同的消息),也不可能破解A的密钥。(<i,j,k>, x[i,j,k])就是一个plaintext-ciphertext对,定义上即使获得许多这样的对,一个传统函数的密钥也是难以破解的。
    在实际使用中,A需要记录的就是一个安全密钥(可能是56bit)和一个简单计数(可能20或者30bit),以记录追踪树上签名最后一条消息的节点编号。如果计算用正确的顺序组织,生成一个签名只需要少量的内存(128个字节就足够了)。这么小的内存常用于低价高容量系统中,比如智能芯片(带内建电脑的信用卡)。

    结论

    本文描述了一个仅基于常规加密函数的数字签名系统。签名和验证签名算法速度快,而且只需要极少量的内存。签名大小随着待签名消息的个数呈对数增长。签名大小和所用内存可以根据计算需求来权衡。

    参考文献

    照例,免贴。

    【全文完】

    一个merkle树的验证例子

    【译注:下面写一个使用merkle验证树的例子,希望能便于读者理解】
    设Y=Y1Y2,…,Yn为一组待签名的消息(n个),首先定义hash函数H(i,j,Y):
    H(i,i,Y) = F(Yi)                                                        ----(1)
    H(i,j,Y) = F( H(i,i+j-1/2, Y), H(i+j-1/2, j, Y) )    ----(2)

    F(Yi)是一个单向函数,H(i,j,Y)是Yi,Yi+1,…和Yj的单向函数,于是H(1, n, Y)可以验证从Y1到Yn的所有消息。
    树的每个叶子节点代表一个待签名的消息,这个和本文描述的不一致,但更容易理解,感觉更清晰。我们取n=8,那么merkle验证树结构如下图所示:

    如果我们当前要验证Y5,发送者A和接收者B将会以如下的步骤执行:
    1) H(1, 8, Y)已经被验证,并且是已知的(回忆前面讲过根节点的H值是公开的)
    2) 由于H(1, 8, Y) = F( H(1, 4, Y), H(5, 8, Y) ),A向B发送H(1, 4, Y)和H(5, 8, Y);然后B可以通过计算H(1, 8, Y) = F( H(1, 4, Y), H(5, 8, Y) )确认H(5, 8, Y)是正确的。
    -->现在B已经确认了H(5, 8, Y)。
    3) A向B发送H(5, 6, Y)和H(7, 8, Y);然后B可以通过计算H(5, 8, Y) = F( H(5, 6, Y), H(7, 8, Y))确认H(5, 6, Y)是正确的。
    -->现在B已经确认了H(5, 6, Y)。
    4) A向B发送H(5, 5, Y)和H(6, 6, Y);然后B可以通过计算H(5, 6, Y) = F( H(5, 5, Y), H(6, 6, Y))确认H(5, 5, Y)是正确的。
    -->现在B已经确认了H(5, 5, Y)。
    5) A向B发送Y5;然后B可以计算H(5, 5, Y) = F(Y5),确认无误。
    -->现在B已经确认了Y5,验证结束。
    在该方法下,仅需要logN的消息交互,当然上述步骤还有改进空间,但是这样更能说明验证的基本流程。
    如果接下来再验证Y6的话,B已经知道了H(6,6,Y),于是只需要向A请求Y6,然后直接计算H(6, 6, Y) = F(Y6)再判断是否和前面接收到的H(6, 6, Y)相等就可以了。

    展开全文
  • 我的原文所在 ...Arrow Encryption for Data in Transit by Leor Brenman 翻译(卢彦民) March 02, 2016 @ 6:00am Appcelerator mobile apps use Secure Sockets Layer (SSL) for encry...
        

    我的原文所在 http://yanmin.in/archive.html

    Arrow Encryption for Data in Transit

    blog-572x320-arrow-encryption.png

    by Leor Brenman
    翻译(卢彦民)
    March 02, 2016 @ 6:00am

    Appcelerator mobile apps use Secure Sockets Layer (SSL) for encrypting and decrypting all data transmitted and received by the device. However, for certain types of apps, one may wish to add another layer of encryption for added security. This post describes how to programmatically add additional encryption for data in transit between an Appcelerator app and an ArrowDB as illustrated below.

    2016.03.02上午6:00

    Appcelerator的移动应用程序使用安全套接字层(SSL)来加密和解密设备发送和接收的所有数据。然而,对于某些类型的应用程序,可能希望添加另一加密层来增加安全性。这篇文章介绍了如何以编程方式给在Appcelerator的应用程序和ArrowDB之间传输的数据增加额外的加密,正如下图所示。


    2726978-71ac476478693590.png

    Background

    背景

    The basic idea is to add a pre block to your Arrow model for decrypting data on a POST or PUT from the client app. This will decrypt data sent by the client app. Also, add a post block for encrypting data being sent to the client app on a GET.

    其基本思想是给你的Arrow 模型为来自客户端的POST和PUT数据的解密添加一个pre block(解密块),这样将能解密客户端应用程序发送的数据。此外,为了被通过GET发送给客户端应用程序的数据的加密添加一个post block(加密块)

    For the purpose of this post, we will use a very simple XOR encryption JavaScript function from Henry Algus which is also the decryption function and is shown below:

    对于这篇文章的目的,我们将使用一个来自Henry Algus的非常简单的异或加密JavaScript方法,并且这个函数也是一个解密方法,如下所示:

    exports.jsEncode = function(s,k) {
        var enc = "";
        var str = "";
        str = s.toString();
        for (var i = 0; i < s.length; i++) {
            var a = s.charCodeAt(i);
            var b = a ^ k;
            enc = enc + String.fromCharCode(b);
        }
        return enc;
    }
    

    Furthermore, since the Appcelerator Platform is a full stack JavaScript platform, this exact same function is used for both encryption and decryption in both the Appcelerator mobile app and the Arrow app.

    此外,由于Appcelerator平台是一个完整的堆栈JavaScript平台,所以在Appcelerator移动应用和Arrow应用中的加密和解密中都可使用这一相同的方法。

    Note that this XOR encryption should not be used for production apps and is strictly being used for demonstration purposes. In a production app, you may want to look at more secure encryption libraries such as the Appcelerator Premium “Crypto” Module, Securely, crypto-js or sjcl.

    注意,这个异或加密不应该用于制作应用程序并且严格用于演示目的。在制作应用程序中,您可能想要看到更安全的加密库,例如Appcelerator Premium“CRypto”模块、Securely、crypto-js或sjcl。

    Arrow Model

    Arrow 模型

    Here is a simple ArrowDB model, database, and a pre (decrypt) and post ((encrypt)) block that illustrates how to encrypt and decrypt data in Arrow:

    这里是一个简单的ArrowDB模型、数据库和pre(解密)和post((加密))块,说明了如何在Arrow中加密和解密数据。

    database.js

    var Arrow = require("arrow");
    var Model = Arrow.createModel("database",{
        "fields": {
            "name": {
                "type": "String"
            }
        },
        "connector": "appc.arrowdb",
        "actions": [
            "create",
            "read",
            "update",
            "delete",
            "deleteAll"
        ],
        "before": "decrypt",
        "after": "encrypt",
        "singular": "database",
        "plural": "databases"
    });
    module.exports = Model;
    

    decrypt.js

    var ENC_KEY = '123';
    var Arrow = require('arrow');
    var Utils = require('../lib/utils');
    var PreBlock = Arrow.Block.extend({
        name: 'decrypt',
        description: 'will decrypt data from mobile app',
        action: function (req, resp, next) {
            if((req.method==="POST" || req.method==="PUT")) {
                req.params.name = Utils.jsEncode(req.params.name, ENC_KEY);
            }
            next();
        }
    });
    module.exports = PreBlock;
    

    encrypt.js

    var ENC_KEY = '123';
    var Arrow = require('arrow');
    var Utils = require('../lib/utils');
    var PostBlock = Arrow.Block.extend({
        name: 'encrypt',
        description: 'will encrypt data to mobile app',
        action: function (req, resp, next) {
            if(req.method==="GET") {
                var body = JSON.parse(resp.body);
                var data = body[body.key];
                var dataLen = data.length;
                if(dataLen){ //findAll
                    data.forEach(function (_row, _index) {
                        _row.name = Utils.jsEncode(data[_index].name, ENC_KEY);
                    });
                } else { //findOne
                    if(data.name) {
                            data.name = Utils.jsEncode(data.name, ENC_KEY);
                    }
                }
                resp.success(body[body.key], next);
            } else {
                    next();
            }
        }
    });
    module.exports = PostBlock;
    

    In the example above, a key of ‘123’ is used to encrypt and decrypt the data.
    在上面的示例中,一个“123”的key是用来加密和解密数据的。

    Mobile App

    手机应用程序

    The mobile app should encrypt the data prior to POSTing data using the jsEncode function with the same key that is used in the Arrow app (e.g. ‘123’). The example below illustrates encrypting the value of a TextField with an Alloy id of “nameTF” prior to POSTing the data in an Appcelerator mobile app.

    移动应用程序应该在发送数据之前使用jsEncode函数以及和Arrow 应用相同的key(例如“123”)来加密数据。下面的例子演示了Appcelerator手机应用中在发送数据之前加密Alloy id 为“nameTF”的文本字段的值的方法。

    var ENC_KEY = '123';
    var xhr = Ti.Network.createHTTPClient({
        onload: function onLoad() {
            Ti.API.info("Loaded: " + this.status + ": " + this.responseText);
        },
        onerror: function onError() {
            Ti.API.info("Errored: " + this.status + ": " + this.responseText);
        }
    });
    xhr.open("POST","http://127.0.0.1:8080/api/database");
    var authstr = 'Basic ' + Ti.Utils.base64encode('TCDiEh3jpghZ2rQ7ckSr1NhGo2AZURwG:');
    xhr.setRequestHeader("Authorization", authstr);
    xhr.setRequestHeader("Content-Type","application/json");
    xhr.send(JSON.stringify({
        "name": jsEncode($.nameTF.value, ENC_KEY)
    }));
    

    After a GET is called, the encrypted data received by the Appcelerator mobile app must be decrypted as illustrated below. In the example below, the received data is used to populate a TableView with an Alloy id of “TV”.

    在一GET被请求后,Appcelerator移动应用接收到的加密的数据接必须解密,如下图所示。在下面的示例中,接收的数据被用于填充一个Alloy id为 “TV”的TableView的。

    var ENC_KEY = '123';
    var xhr = Ti.Network.createHTTPClient({
        onload: function onLoad() {
            Ti.API.info("Loaded: " + this.status + ": " + this.responseText);
            var body = JSON.parse(this.responseText);
            var data = body[body.key];
            var rows = [];
            if(data.length>0) {
              _.each(data, function(item) {
                  rows.push(Alloy.createController('row', {
                  name: jsEncode(item.name, ENC_KEY)
                }).getView());
              });
            }
            $.TV.setData(rows);
        },
        onerror: function onError() {
            Ti.API.info("Errored: " + this.status + ": " + this.responseText);
        }
    });
    xhr.open("GET","http://127.0.0.1:8080/api/database");
    var authstr = 'Basic ' + Ti.Utils.base64encode('TCDiEh3jpghZ2rQ7ckSr1NhGo2AZURwG:');
    xhr.setRequestHeader("Authorization", authstr);
    xhr.send();
    

    Viewing Data in ArrowDB

    在ArrowDB中查看数据

    Recall that we are only encrypting the data in transit. The data in the ArrowDB is unencrypted. However, since we have added an encryption post block to the model for all GET operations, when we try to view the ArrowDB data in the Arrow console, we will see encrypted data as shown below:

    回想一下,我们只是在运输途中加密了数据。ArrowDB中的数据是未加密的。然而,由于我们为所有的GET操作添加了一个加密块,当我们试图在Arrow控制台中查看ArrowDB的数据时,我们将看到加密了的数据,如下所示:

    So, how do we view/access the unencrypted data?

    那么,我们如何查看/访问未加密的数据?

    One way is to use the Appcelerator Dashboard, select the Arrow app and navigate to the ArrowDB, and view the data in the Manage Data -> Custom Object section as shown below:


    2726978-4048f28bad7310ee.png

    一种方法是使用Appcelerator仪表板,选择ArrowDB应用并导航到ArrowDB,然后在Mamage Data ->Custom Objext 部分中查看数据,如下所示:


    2726978-1221d4ebe7505391.png

    Another technique for programmatically receiving unencrypted data is to modify the post block to look for a specific header and value and then send the data unencrypted. This code is provided here.

    另一种以编程方式接收加密数据的技术是修改post块来寻找特定的header和value,然后把不加密的发送数据。代码如下。

    An example curl command using this technique is shown below:

    一个使用curl命令的技术例子如下所示:

    $ curl -u TCDiEh3jpghZ2rQ7ckSr1NhGo2AZURwG: "http://127.0.0.1:8080/api/database" -H "admin-secret:admin-secret"
    

    Results in the following reply:
    结果如下:

    {
        "success": true,
        "request-id": "b2a5d659-516d-49ba-a33e-629de4bab195",
        "key": "databases",
        "databases": [
            {
                "id": "564357e0dc26a0090d2f5b82",
                "name": "Leor"
            },
            {
                "id": "563d79043d24bb09100b7f6c",
                "name": "Lillian"
            },
            {
                "id": "563d78c8dc26a0090d0adfb3",
                "name": "Kim"
            },
            {
                "id": "563d78afdc26a009050af1b3",
                "name": "Nate"
            }
        ]
    }
    

    Compare this to using the curl command without the header:

    比较一下没有header的curl命令的使用:

    $ curl -u TCDiEh3jpghZ2rQ7ckSr1NhGo2AZURwG: "http://127.0.0.1:8080/api/database"
    

    which returns the following encrypted data:
    它返回的是以下加密的数据:

    {
        "success": true,
        "request-id": "bf8cbf08-d2f2-4a24-a9a5-a37c0841535c",
        "key": "databases",
        "databases": [
            {
                "id": "564357e0dc26a0090d2f5b82",
                "name": "7\u001e\u0014\t"
            },
            {
                "id": "563d79043d24bb09100b7f6c",
                "name": "7\u0012\u0017\u0017\u0012\u001a\u0015"
            },
            {
                "id": "563d78c8dc26a0090d0adfb3",
                "name": "0\u0012\u0016"
            },
            {
                "id": "563d78afdc26a009050af1b3",
                "name": "5\u001a\u000f\u001e"
            }
        ]
    }
    

    Summary

    总结

    This post demonstrates how easy Arrow makes it to encrypt data in transit. Code for this post can be found here.
    这篇文章演示了Arrow在传输途中加密数据是多么的容易。这篇文章的代码可以在这里找到。

    展开全文
  • 认证加密(AE, Authenticated Encryption)

    千次阅读 2019-07-29 00:48:54
    关联数据的认证加密(AEAD, Authenticated encryption with associated data) 认证加密的三种实现方式 一、Encrypt-then-MAC (EtM) 二、Encrypt-and-MAC (E&M) 三、MAC-then-Encrypt (MtE) 本文翻译自:...

    目录

    关联数据的认证加密(AEAD, Authenticated encryption with associated data)

    认证加密的三种实现方式

    一、Encrypt-then-MAC (EtM) 

    二、Encrypt-and-MAC (E&M) 

    三、MAC-then-Encrypt (MtE) 


    本文翻译自:https://en.wikipedia.org/wiki/Authenticated_encryption

     

    认证加密(AE, Authenticated Encryption)或关联数据的认证加密(AEAD, Authenticated Encryptioni with Associated Data)是一种加密形式,它能同时保证数据的机密性(confidentiality)和完整性(integrity或authenticity)。这些属性通过一个单一的易于使用的编程接口来提供。

    AE的需求来源于这么一个观察,即把单独机密性和认证块加密操作模式(authentication block cipher operation modes)安全的组合到一起非常容易出错且非常困难。生产中的协议或应用由于未能正确实现或缺乏认证而遭受的很多实际的攻击(包括SSL/TLS)就证实 了这一点。

    在2000年左右,针对这个概念做了很多努力。尤其是,Charanjit Jutla's IACBC 和 IAPM modes在2000年的发表使得人们对这些模式产生了强烈的兴趣。ISO/IEC 19772:2009 标准化了6种不同的认证加密模式(OCB 2.0,Key Wrap,CCM,EAX,Encrypt-then-MAC(EtM)以及GCM)。为响应NIST的征集,又开发了多种模式。Sponge function可以在双工模式下使用,以提供认证加密。

    AE模式的典型编程接口会提供以下功能:

    1. Encryption
      1. Input:plaintext,key以及可选的明文header,header不被加密,但,会进行完整性验证
      2. Output:ciphertext以及authentication tag
    2. Decryption
      1. Input:ciphertext,key,authentication tag以及可选的header(如果加密时存在)
      2. Output:plaintext,或错误(如果authentication tag不匹配ciphertext或header)

    这里的header部分旨在为不需要机密性,但需要完整性的网络包或存储metadata,提供完整性(integrity)保护。

    除了对消息提供机密性(confidentiality)和完整性(integrity)保护,认证加密还可以针对选定密文攻击(chosen ciphertext attack)提供安全保护。选定密文攻击时,攻击者提交精心选择的密文到“解密神谕(decryption oracle)”然后分析解密的结果从而尝试获得针对加密系统的优势。(住:“oracle”不是指 数据库,而是指拥有超能力,能得到本不应该得到的东西。见这里)。认证加密模式可以识别出错误构建的密文然后拒绝解密。除非攻击者利用加密算法正确构建出了密文,否则,攻击者无法让系统解密任意构建的密文,但,能正确构建出密文其实意味着攻击者早就已经知道明文了。通过阻止攻击者获取他尚未掌握的有用信息,如果能正确实现的话这就使得“解密神谕(decryption oracle)”失效了。

    已经开发了许多专门的认证加密模式(authentication encryption mode)用于对称块加密(symmetric block cipher)。但,认证加密一般可以通过组合加密方案和MAC来实现,但,需要满足下面条件:

    1. 加密方案针对选定密文攻击(chosen ciphertext attack)是语义安全的
    2. MAC功能针对选定密文攻击(chosen ciphertext attack)是不可伪造的

    Bellare 和Namprempre (2000) 分析了这些原语的组成,演示了“加密一条消息然后针对密文应用MAC(即:Encrypt-then MAC)”意味着针对自适应的选定密文攻击是安全的,只要加密方案和MAC满足上述属性即可。Katz和Yung调查了这一概念,并证明“不可伪造的加密”就意味着针对选定密文攻击是安全性的。

    2013年宣布了一项竞赛,鼓励设计认证加密模式。

    关联数据的认证加密(AEAD, Authenticated encryption with associated data)

    AEAD是AE的变体,对于被加密的数据,AEAD即保证机密性,也保证了完整性。AEAD把关联的数据绑定到密文,同时也绑定到数据所出现的上下文,对一条有效的密文"cut-and-paste"到不同的上下文时能够被探测到从而被拒绝。

    例如,网络包就需要这种特性:

    1. Header需要完整性(integrity),且header是可见的明文(即:不需要confidentiality)

    2. Payload则既需要完整性(integrity)也需要机密性(confidentiality)

    3. Header和payload都需要认证发送者的身份(即:authentication)

     

    认证加密的三种实现方式

    一、Encrypt-then-MAC (EtM) 

    EtM approach

    ciphertext=encrypt(key1, plaintext)

    MAC=hash(key2, ciphertext)

    ciphertext+MAC发送到对端

    IPsec即采用该方式(VPN使用该种方式)

    注意:加密的密钥和hash的密钥必须是不同的,否则就有可能不安全(取决于加密方法和hash方法)

     

    二、Encrypt-and-MAC (E&M) 

    E&M approach

    ciphertext=encrypt(key, plaintext)

    MAC=hash(key, plaintext)

    ciphertext+MAC发送到对端

    SSH即采用该方式

    E&M本身尚未被证明是强不可伪造(strongly unforgeable)的,但,可以对SSH做一些小的改动使得SSH强不可伪造

     

    三、MAC-then-Encrypt (MtE) 

    MtE approach

    MAC=hash(key, plaintext)

    ciphertext=encrypt(key, plaintext+MAC)

    ciphertext发送到对端

    SSL/TLS即采用该方式

    EtM本身尚未被证明是强不可伪造(strongly unforgeable)的,但,Krawczyk已证明的,由于编码和MtE机制,SSL/TLS是安全的。不管理论上的安全,深入分析SSL/TLS,其安全模型是MAC-then-pad-then-encrypt,即:plaintext需要先pad到加密函数的block size,但,padding错误经常会导致接收端可以探测的到错误,而这会导致"padding oracle"攻击,例如Lucky 13就是这种攻击。

     

    展开全文
  • 报错:No application encryption key has been specified 翻译过来的意思是:没有指定应用程序加密秘钥 终端切入到项目目录下执行: php artisan key:generate 如若报错为以下形式请继续看下去: 这个报错的意思...

    报错:No application encryption key has been specified
    翻译过来的意思是:没有指定应用程序加密秘钥
    终端切入到项目目录下执行:

    php artisan key:generate
    

    如若报错为以下形式请继续看下去:
    在这里插入图片描述
    这个报错的意思是:putenv()函数被禁用了
    解决方案:
    1。切入到php的配置文件php.ini文件中进行更改disable_functions字符串,将后面的putenv删除,
    2。如果用的宝塔可按照以下方式去进行更改:
    在这里插入图片描述
    在这里插入图片描述
    然后返回终端继续执行生成秘钥
    如下:
    在这里插入图片描述
    复制秘钥粘贴到项目.evn中的以下位置:
    在这里插入图片描述
    保存刷新页面即可;
    因为putenv()是一个“危险函数”,所以建议使用后继续给禁用掉;

    putenv()
    功能描述:用于在 PHP 运行时改变系统字符集环境。在低于 5.2.6 版本的 PHP 中,可利用该函数
    修改系统字符集环境后,利用 sendmail 指令发送特殊参数执行系统 SHELL 命令。
    危险等级:高

    展开全文
  • Android加密,挺实用一功能,e文看着费劲,磕磕巴巴翻译一下。 ----------------------------------------------------------------------------- 原文地址: ...
  • 本文翻译自维基百科:http://en.wikipedia.org/wiki/Triple_DES Triple Des 密码学中,Triple Des是三重数据加密算法(Triple Data Encryption Algorithm)对称块密码的通称,该算法对每个数据块作了3次的DES密码...
  • type=show&...解题报告:输入一个有n个单词的句子,然后再输入这n个单词对应的意思是什么,要你翻译出这个句子最后是什么。 一个裸的map 1 #include<cstdio> 2 #include<...
  • 翻译:基于空间误差扩散对HEVC 4K视频进行稀疏选择性加密 特点:加密内容稀疏,加密过程高效,安全性高,2019年发表。 发表SCI期刊:http://ericdata.com/tw/detail.aspx?no=416588 论文下载链接:...
  • --王成辉翻译整理,转贴请注明出自微软BI开拓者www.windbi.com--原帖地址SQLServer2005里使用with encryption选项创建的存储过程仍然和sqlserver2000里一样,都是使用XOR进行了的加密。和2000不一样...
  • MediaDRM 中文翻译

    千次阅读 2018-07-28 16:25:26
    最近需要做在Android中做DRM相关内容,简单研究了一下MediaDRM文档,翻译如下;个人水平有限,有错误的地方欢迎指正: MediaDRM extends Object 类概述: MediaDRM结合MediaCrypto可以用来获取keys来解密加密的...
  • 翻译 给你一个长度为n的序列,要求你把它分成K段 每段的价值为这段的总权值%P 要求总价值最小 n&lt;=500000 K&lt;=100 P&lt;=100 题解 方程 f[i][j]=min(f[k][j−1]+(sum[i]−sum[k])mod&amp;...
  • 其实官方英文文档的阅读难度其实并不是很高,所以在这里在学习官方文档的过程中,把它翻译成中文,在翻译的过程中加深学习了解,并分享出来和大家一起学习。 中文内容是本人的渣渣英文水平结合有道词典,谷歌翻译的...
  • 常用英文翻译

    2016-10-18 14:30:15
    1.FTP,文件传输协议(File Transfer Protocol...3.ASE,高级加密标准(Advanced Encryption Standard)。 4.HTML,超文本标记语言(HyperText Markup Language)。 5.APT,高级包安装工具(Advanced Packaging
  • 看了一下这篇文章,只对一些信息进行了翻译。希望大家一起学习.引用网址:http://msdn.microsoft.com/msdnmag/issues/03/06/NETRemoting/voidRemoting Execution and Extensibility(Remoting执行和扩展)When a ...
  • Redis 6.0 TLS支持

    2020-09-29 05:40:54
    翻译:Wen Hui 转载:中间件小哥 Redis从版本6开始支持SSL / TLS,这是一项可选功能,需要在编译时启用。 编译 要使用TLS支持进行构建,你需要OpenSSL开发库(例如Debian / Ubuntu上的libssl-dev)。 运行...
  • GreenDao Encrypt

    千次阅读 2016-08-31 13:38:04
    GreenDao Encryption 翻译数据库加密 greenDao支持加密的数据库来保护敏感资料。虽然新版本的Android支持文件系统加密,但是它自身不能提供额外的对数据库文件的安全支持。一旦攻击者持有了数据库文件(在一个root...
  • https://learnku.com/docs/laravel/5.6/localization/1376 // 全景链接$data['share_phone'] = trans('web.host') . '/building/' . $buildings->view_uuid ....key=' . urlencode(Encryption::ecryptdString($...
  • [翻译]xml的加密和解密 ... [原文源码下载] 原文发布日期:2006.12.15 作者:Derek Smyth ...翻译:webabcd ...xml加密(XML Encryption)是w3c加密xml的标准。这个加密过程包括加密xml文档的元素及其子元素,
  • PHP翻译python加密函数

    2013-12-03 13:41:20
    ...before inserting the password to database it is encrypted with the following function ...<p>I'm not familiar with encryption and have no clue how to translate this to PHP</p> </div>
  • IBM存储配件FC号及描述翻译

    千次阅读 2015-11-14 14:53:50
    很多朋友对于IBM海量的描述信息感觉到束手无策,以下信息均可以在www.unix360.com 中使用快查功能查询到,...5900 Transparent LTO Encryption LTO加密许可 5901 Transparent LTO Encryption LTO加密许可 6005 5 m LC
  • 翻译自:Using app encryption in Jelly Bean 关键词 : adb install -l 最新的 Android 4.1(Jelly Bean)版本在上周的 Google I / O 大会上发布了,它有一大堆新功能和改进。 其中一个有趣的功能是应用程序加密,...

空空如也

空空如也

1 2 3 4 5 6
收藏数 110
精华内容 44
关键字:

encryption翻译