轻量级加密算法PRESENT的设计与性能分析资源-CSDN文库

需积分: 5 117 浏览量 2024-11-06 09:47:35 上传评论收藏 246KB PDF 举报

资源推荐

资源详情

资源评论

PRESENT: An Ultra-Lightweight Block Cipher

A. Bogdanov

, L.R. Knudsen

, G. Leander

, C. Paar

, A. Poschmann

M.J.B. Robshaw

, Y. Seurin

, and C. Vikkelsoe

Horst-G¨ortz-Institute for IT-Security, Ruhr-University Bochum, Germany

Technical University D enmark, DK-2800 Kgs. Lyngby, Denmark

France Telecom R&D, Issy les Moulineaux, France

leander@rub.de, {abogdanov,cpaar,poschmann}@crypto.rub.de

lars@ramkilde.com, chv@mat.dtu.dk

{matt.robshaw,yannick.seurin}@orange-ftgroup.com

Abstract. With the establishment of the AES the need for n ew block

ciphers has been greatly diminished; for almost all block cipher appli-

cations the AES is an excellent and preferred choice. However, despite

recent implementation advances, the AES is not suitable for extremely

constrained environments such as RFID tags and sensor networks. In

this paper we describe an ultra-lightweight block cipher, present. Both

security and hardware eﬃciency have been equally important during the

design of the cipher and at 1570 GE, the hardware requirements for

present are competitive with today’s leading compact stream ciphers.

1 Introduction

One deﬁning trend of this century’s IT landscape will be the extensive deploy-

ment o f tiny computing devices. Not only will these devices featur e routinely in

consumer items, but they will form an integral part of a pervasive — and unseen

— communication infrastructure. It is already recognized that such deployments

bring a range of very particular security risks. Yet at the same time the cryp-

tographic solutions, and particularly the cr yptographic primitives, we have at

hand are unsatisfactory for extremely resource-constrained environments.

In this paper we propose a new ha rdware-optimized blo ck cipher that has

been carefully designed with area and power constraints uppermost in our mind.

Yet, at the same time, we have tried to avoid a compromise in security. In

achieving this we have looked back at the pioneering work embodied in the

DES [34] and complemented this with features from the AES ﬁnalist candidate

Serpent [4] which demonstrated excellent performance in hardware.

At this point it would be reasonable to ask why we might want to design a

new blo ck cipher. After all, it has become an “ accepted” fact that stream ciphers

are, potentially, more c ompact. Indeed, r e newed eﬀorts to understand the design

of compact stream ciphers are underway with the eSTREAM [15] project and

several promising proposals oﬀer appealing performance proﬁles. But we note a

couple of reasons why we might want to consider a compact block cipher. First,

a block cipher is a versatile primitive and by running a block cipher in counter

mode (say) we ge t a stream cipher. But second, and perhaps more importantly,

the art of block cipher design se ems to be a little better understood than that

of stream ciphers. For instance, while there is a rich theory under-pinning the

use of linear feedback shift registers [29] it is not easy to combine these building

blocks to give a secure proposal. We suspect that a carefully designed block

cipher could be a less risky undertaking than a newly designed stream cipher.

Thus, we feel that a block cipher that requires similar hardware resources as a

compact stream cipher could be of consider able interest.

It is important to realis e that in developing a new block cipher, particularly

one with aggressive performance characteristics, we are not just looking for inno-

vative implementation. Rather, the design and implementation of the cipher go

hand-in-hand and this has revealed several fundamental limits and inherent con-

tradictions. For instance, a given secur ity level places lower bounds on the block

length and key length. Just processing a 64-bit state with an 80-bit key places

fundamental lower limits on the amo unt of space we r e quire. We also observe

that hardware implementation — particularly co mpact hardware implementa-

tion — favours repetition. Even minor variations can have an unfortunate eﬀect

on the space required for an implementation. Yet, at the same time, the crypta n-

alyst also favours repetition and seeks mathematical structures that propagate

easily across many rounds. How much simple, repetitive structure can we include

without compromising its security?

In this paper we describe the compact block cipher

present. After a brief

survey of the existing litera tur e , the rest of the paper is organised in a stan-

dard way. present is described in Section 3 with the design decisions des c ribed

in Section 4. The security analysis follows in Section 5 along with a detailed

performance analy sis in Section 6. We clo se the paper with our conclusions.

2 Existing Work

While there is a growing body of work on low-cost cryptography, the numbe r of

papers dealing with ultra-lightweight ciphers is surprisingly limited. Since our

fo c us is on algor ithm design we won’t refer to work on low-cost communication

and authentication protocols. Some of the mo st extensive work on compact im-

plementation is c urrently taking place within the eSTREAM project. As part of

that initiative, new stream ciphers suitable for eﬃcient hardware implementation

have been proposed. While this work is ongoing, some promising candidates are

emerging [7, 19]. While the tra de-oﬀs are complex, implementation pape rs [18]

suggest that a round 1300-2600 gate equivalents (GE) would be req uired for the

more compact ciphers within the eSTREAM project.

With re gards to block ciphers it is well-known that DES was designed with

hardware eﬃciency in mind. Given the very limited state of semiconductor cir-

cuits in the early 1970s, it is not surprising that DES possesses very competitive

implementation properties. Work on DES reveals an implementaton of around

The name reﬂects its similarity to Serpent and the goal of ﬁt ting everywhere; the

very nature of u biquitous computing.

generateRoundKeys()

for i = 1 to 31 do

addRoundKey( state,K

)

sBoxLayer(state)

pLayer(state)

end for

addRoundKey( state,K

)

plaintext

sBoxLayer

pLayer

sBoxLayer

pLayer

ciphertext

key register

addRoundKey



update

addRoundKey



Fig. 1. A top-level algorithmic description of present.

3000 GE [42] while a serialized implementation can be realized with around 2300

GE [37]. The key length of DES limits its usefulness in many applications and

makes proposals such as DESXL (2168 GE) of some considerable interest [37].

For modern block ciphers, the landmark paper of [16] gives a very thorough

analysis of a low-cost implementation of the AES [35]. However, the resources

required for this cipher are around 3600 GE, which is an indirect consequence

of the fact that Rijndael was designed for software eﬃciency on 8- and 32-

bit processors. Implementation requirements for the Tiny Encryption Algorithm

tea [43, 44] are not known, but a crude estimate is that tea needs at least 2100

GE and xtea needs

at le ast 2000 GE. Four dedicated proposals for low-cost

implementation are mCrypton [30], hight [22], sea [4 1], and cgen [40], though

the latter is not primarily intended as a block cipher. mCrypton has a precise

hardware assessment and requires 2949 GE, hight requires around 3000 GE

while sea with parameters comparable to present requires around 2280 GE.

3 The Block Cipher present

present is an example of an SP-network [33] and cons ists of 31 rounds. The

block length is 64 bits and two key lengths of 80 and 128 bits are supported. Given

the applications we have in mind, we recommend the version with 80-bit keys.

This is more than adequate se c urity for the low-security applications typically

required in tag-based deployments, but just as importantly, this matches the

design goals of ha rdware-oriented strea m ciphers in the e STREAM project and

allows us to make a fairer comparison. T he security claims and performance

attributes of the 128-bit version ar e provided in an appendix.

These ﬁgures and others in Section 2 are “back-of-an-envelope” where we assume

the following requirements: 32-bit XOR = 80 GE, 32-bit arithmetic ADD = 148 GE,

192-bit FF = 1344 GE, SHIFT = 0 GE. All estimated ﬁgures lack any control logic

which might signiﬁcantly increase the required area.

Each of the 31 rounds consists of an xor o peration to intro duce a round

key K

for 1 ≤ i ≤ 32, where K

is used for post-whitening, a linear bitwise

permutation and a non-linear substitution layer. The non-linear layer uses a

single 4-bit S-box S which is applied 16 times in parallel in each round. The

cipher is described in pseudo -code in Figure 1, and each stage is now speciﬁed

in turn. The design rationale are given in Section 4 and throughout we numb e r

bits from zero with bit zero on the right of a block or word.

addRoundKey. Given round key K

= κ

. . . κ

for 1 ≤ i ≤ 32 and cur rent

state b

. . . b

, addRoundKey consists of the operation for 0 ≤ j ≤ 63,

→ b

⊕ κ

sBoxlayer. The S-box used in present is a 4-bit to 4- bit S-box S : F

→ F

The action of this box in hexadecimal notation is given by the following table.

x 0 1 2 3 4 5 6 7 8 9 A B C D E F

S[x] C 5 6 B 9 0 A D 3 E F 8 4 7 1 2

For sBoxLayer the current state b

. . . b

is consider ed as sixteen 4-bit words

. . . w

where w

= b

4∗i+3

||b

4∗i+2

||b

4∗i+1

||b

4∗i

for 0 ≤ i ≤ 15 and the output

nibble S[w

] provides the updated state values in the obvious way.

pLayer. The bit permutation used in present is given by the following table.

Bit i of state is moved to bit position P (i).

i 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

P (i) 0 16 32 48 1 17 33 49 2 18 34 50 3 19 35 51

i 16 17 18 19 20 21 22 23 24 25 26 27 28 2 9 30 31

P (i) 4 20 36 52 5 21 37 53 6 22 38 54 7 23 39 55

i 32 33 34 35 36 37 38 39 40 41 42 43 44 4 5 46 47

P (i) 8 24 40 56 9 25 41 57 10 26 42 58 11 27 43 59

i 48 49 50 51 52 53 54 55 56 57 58 59 60 6 1 62 63

P (i) 12 28 44 60 13 29 45 61 14 30 46 62 15 3 1 47 63

The key s chedule. present can take keys of either 80 or 128 bits. Howe ver

we focus on the version with 80-bit keys. The user- supplied key is stored in a

key register K and represented as k

. . . k

. At round i the 64 -bit round key

= κ

. . . κ

consists of the 64 leftmost bits of the current contents of

= κ

. . . κ

= k

. . . k

After extracting the round key K

, the key register K = k

. . . k

is updated

as follows.

剩余17页未读，继续阅读

评论收藏

内容反馈

进击的铁甲小宝

粉丝: 1410
资源: 9

轻量级加密算法PRESENT的设计与性能分析

论文研究-轻量级PRESENT加密算法功耗攻击研究.pdf

PRESENT加密算法

present加密算法

present轻量级密码算法verilog实现

PRESENT密码算法的Verilog实现

轻量级分组密码

轻量级PRESENT加密算法功耗攻击研究 (2014年)

密码学超轻量级密码——present

PRESENT 密码算法代码

基于有限域逆映射的轻量级加密SOPT-S盒构造与研究

S盒差分分布表_ des s盒的差分均匀度, present算法s盒差分分布表-C代码

基于PRESENT 算法的安全标签基带设计1

PB15111604_金泽文_“RFID密码算法”读书报告1

轻量级分组密码GIFT的一种白盒实现方案.docx

EPCBC密码算法的FPGA优化实现研究.pdf

BS ISO IEC 29167-11_2023信息技术.第11部分：空中接口通信的加密套件PRESENT-80安全服务.rar

类似于PRESENT的密码的差分密码分析

分组密码的加解密关系Similarities between Encryption and Decryption_ How far can we go

物联网感知层安全概述.pptx

Lightweight Cryptography in Radio Frequency Identification (RFID) Systems

八面堡垒：轻巧的分组密码

应用程序外观与现在的表现类似的区分器

JDK 1.8 64位.rar

SoftCnKiller2.54.zip（因为要下载码，弃用不更新了）

最新资源