IEEE - 45670
Modified MD5 algorithm for low end IoT Edge
devices
Viraj Khatri
Electronics and Telecommunication Engineering
College of Engineering
Shivajinagar, Pune 411005
Email: khatrivt15.extc@coep.ac.in
Abstract—Advent of the Information Age and Internet of
Things has lead to an unprecedented increase in flow of data. This
increase in data-flow has been matched with increase in computa-
tional power. However, low-end devices, usually implemented as
a cost-saving alternative, have not been able to keep up with the
increasing security and error detection & correction demands
of MD5 or SHA1/2/3 algorithms. We present the performance
characteristics of modified versions of MD5 message-digest algo-
rithm which have been altered using two different approaches,
reducing lateral register widths or reducing computation cycles.
The metrics for comparison are collisions, synthesis reports and
time required for message-digest calculation.
Index Terms—Internet of Things, IoT Edge Devices Security,
Low End IoT Edge Devices, Modified MD5 Algorithm, Modified
Message-Digest.
I. I NTRODUCTION
For wireless communication between devices, cryptographic
algorithms are widely used to monitor or assist communica-
tion. This is done by the algorithms playing a major role in
verification of integrity of data, which can get corrupted on any
of the many stages of transmissions, owing to internal fault or
external interference. For Internet of Things (IoT) applications,
where data is streamed continuously from various sources, the
data is monitored real-time. This is accomplished by utilizing
Application Specific Integrated Circuits (ASIC) or Graphics
Processing Units (GPU). All these hardware options are used
to generate a hash for a given message signal, while the hash
itself assists with data analysis and decision making during
erroneous data transmission and reception.
There are several algorithms that have been made for this
specific purpose, like Secure Hashing Algorithm (SHA) and
Mesage-Digest 4 (MD4). These were designed with 32-bit
processors in focus, as they require 32-bit variables and
32-bit logical operations. However, as greater progress was
made in computing these algorithms increased in complexity,
like SHA-256 and MD5, which ensure better integrity in
transmission.
Depending on the particular IoT application, the tolerance of
erroneous data changes, resulting in requirement of verification
of data integrity dependent on application. When a non-
tolerant IoT application has various sources of data, sources
who don’t have enough resources to commit to Encryption
along with integrity verification, a trade-off is made. Instead
10th ICCCNT 2019
July 6-8, 2019, IIT - Kanpur
Kanpur,
Authorized licensed use limited to: University of Exeter. Downloaded
on May
Ms. Vanita Agarwal
Electronics and Telecommunication Engineering
College of Engineering
Shivajinagar, Pune 411005
Email: vsa.extc@coep.ac.in
of both, only cryptographic hash functions are used to ensure
integrity of data. For this two algorithms are prevalent in
usage SHA and MD5 [1]. Several generations of the Secure
Hashing Algorithms have been developed and are widely
used. Internally SHA-3 is quite different from SHA-1 and
SHA-2, which makes it more suited to be implemented on
hardware, although it takes more computation time in software
[2]. However due to the recent publication of SHA-3 (2015),
there hasn’t been wide-spread development in this algorithm.
Thus, SHA-2 has been widely implemented as a software
data verification tool, due to it’s software based improved
performance, which leaves IoT hardware applications to be
handled solely by MD5 algorithm.
To further justify the choice of MD5 algorithm, we take
into account the low memory and power IoT edge devices, our
use case. This leads to cryptographic hash algorithms being
disregarded due to the target implementation of data integrity
verification. Furthermore, for the constant bit-rate data streams
associated with the IoT edge device, a fixed length output hash
algorithm is appropriate. The MD5 algorithm satisfies both of
these conditions, as it has been cryptographically broken [3]
and should not be considered a cryptographic hash algorithm.
The MD5 message-digest algorithm was primarily made
to differentiate between two messages using their respec-
tive message-digest. This was achieved by making the same
message-digest output improbable to be produced by two
slightly differing messages [4]. This property has been used
as a error-detecting and security mechanism in various forms
of communications. It has 4 stages with 64 iterations total
at it’s core [4], and then further trivial functions to achieve
the properties the message-digest possesses. By modifying the
MD5 architecture, we aim to make it more feasible to be
implemented as hardware in low power and memory devices,
like IoT edge devices, to add the functionality of data integrity
verification.
We will first discuss the Message-Digest cryptographic
algorithms, Their variations and working, followed by how this
algorithm is implemented in verilog, subsequently showing
how this architecture can be scaled down. Ultimately, perfor-
mance comparison will be done on the metrics of collisions,
synthesis reports and time required.
India
07,2020 at 07:51:50 UTC from IEEE Xplore. Restrictions apply.
 IEEE - 45670
Fig. 1. Data Flow Graph of one of the 64 iterations of the MD5 algorithm.
II. R ELATED W ORKS
Overview and survey articles for hardware designs of se-
curity in IoT Edge devices have been published [5] which
outline the authentication and encryption using cryptography
in Ultra Low Power processors. They also discuss the possible
problems that might be encountered while designing such a
system, however, for our implementation of Data integrity
verification, only the pertinent principles is taken, a lot of
information is impertinent as it is specific to processors.
There have been forays into measuring the performance and
energy consumption of AES, and optimizing AES for IoT
Edge devices, namely in Wireless Sensor Networks. One of
the approaches to optimize AES taken in this publication [6]
is in the same vein as the approach we take, that is Reducing
data types size. This is however done in with the intention
of optimizing compiler processing by eliminating inefficient
storage due to fixed platform bit size. Other optimization, like
Specialization of code, is not applicable to us as it chooses
one between two modes of AES operation (128 or 256-bit).
These publications have covered optimizing AES and simi-
lar encryption standards for low power processors, which has
been well documented and pursued. However, cost concerns of
any deployment can remove the luxury of a processor which
leaves only the option of custom hardware based solutions that
are power and cost efficient to solve this vein of problems. The
core motivation behind this paper is to develop such a system
and comment on it’s reliability.
III. M ESSAGE -D IGEST A LGORITHMS
A. MD4
This algorithm was developed by Ronald Rivest in 1990,
although it was published in 1992 [9]. The main contribution
of the MD4 algorithm in this context is to be a significant
influence on later designs like SHA-1 and MD5. By this virtue
the MD4 algorithm is not discussed further here.
B. MD5
Designed as a replacement for MD4 algorithm by Ronald
Rivest [4], producing a 128-bit hash from a 512-bit message.
A longer message than 448-bits is broken into different pieces
of 448-bit length. If the message length is not a multiple of
448, then it is padded with 1 followed by zeros until it reaches
10th ICCCNT 2019
July 6-8, 2019, IIT - Kanpur
Kanpur,
Authorized licensed use limited to: University of Exeter. Downloaded
on May
a multiple of 448. After it is padded with another 64-bit value
representing the length of the original message in, modulo 264 .
The main operation of MD5 happens on a 128-bit block,
whose values are affected by the 512-bit message (448-bit
message+64-bit representation). The blocks in shown in Fig.1,
namely A, B, C & D, are each 32-bit in size, with predeter-
mined pseudo-random starting values, while the functions F,
G, H & I are given in equations Eq.1, Eq.2, Eq.3 & Eq.4
respectively.
F (B, C, D) = (B ∧ C) ∨ (¬B ∧ D) 1 ≤ i ≤ 16 (1)
G(B, C, D) = (B ∧ D) ∨ (C ∧ ¬D) 17 ≤ i ≤ 32 (2)
H(B, C, D) = B ⊕ C ⊕ D 33 ≤ i ≤ 48 (3)
I(B, C, D) = C ⊕ (B ∨ ¬D) 49 ≤ i ≤ 64 (4)
After computing the above functions, F for first 16 itera-
tions, followed by G, H, I respectively, the result is added
to A. The functions M, k & S from Fig.1 are dependent on
an iterating variable i, which is calculated uniquely for each
of the 16 iteration of the 4 functions. While original 512-bit
message is broken in to 16 32-bit chunks, each stored in a
M function, the function k is made of predetermined pseudo-
random values of 32-bit size. After these M and k are added
to A, it is shifted according to the value provided by S, which
ranges from 5 to 23. After this the 4 blocks are rotated one and
i is incremented, and this process repeats 63 more times. After
these 64 iterations, the values in blocks A, B, C & D together
represent the hash output. For k & S the iteration variable is
not changed, that is it still is given by i. That is, whatever the
value of i it is same value is to be used as iteration variable
for both kLUT & sLUT, while for M the iterating variable is
taken not as i directly, it is taken from iLUT which can be
calculated using Eq.5.
⎧
⎪
⎪ i 1 ≤ i ≤ 16
⎪
⎨(5 × i + 1) mod 16 17 ≤ i ≤ 32
iLU T = (5)
⎪(3 × i + 5) mod 16 33 ≤ i ≤ 48
⎪
⎪
⎩
(7 × i) mod 16 49 ≤ i ≤ 64
Thus, the Look-up Table for i has rearranged values of i,
which are fed to M, to choose a input message chunk, while
normal iterating values of i are used in Look-up Tables for k &
S to find out the predetermined pseudo-random additions and
the shift values to be used in the four MD5 blocks, namely A,
B, C & D.
IV. V ERILOG I MPLEMENTATION
A. Original
The unedited verilog model [10] consists of multiple tiers
of blocks all of which contribute individually to the func-
tioning of the MD5 algorithm. These blocks are md5 ctl,
India
07,2020 at 07:51:50 UTC from IEEE Xplore. Restrictions apply.
 IEEE - 45670

Fig. 2. Block Diagram for Verilog implementation of MD5.

md5 fsm, md5 core & sram, whose hierarchy is shown in

Fig.2, and each handles their respective tasks. The block
md5 core houses the 4 functions (F, G, H & I) and handles the
computation of the values in these blocks during a computation
iteration, though it cannot decide which to use on it’s own,
that signal needs to be fed from outside this block. The next
block, md5 fsm, is responsible for reordering A, B, C & D
as shown in Fig.1 for all 64 iterations, while also feeding
the correct values for these 4 blocks to the block md5 core.
The block sram’s sole purpose is to store the input message
in memory to be later given in required order to the block
md5 fsm. This order is decided by the block md5 ctl, as this
maintains a Look-Up Table (LUT) to find the value of iteration
variable i (iLUT). Along with iLUT, the block md5 ctl also is
responsible for LUT for finding the shift value i.e. S (sLUT),
and LUT for finding the random addition value i.e. k (kLUT).
Further, the block md5 ctl also feeds the message to the block
sram to store and transfers output of the block sram to the
block md5 fsm.
In each iteration, the block md5 ctl feeds values for i, k, S
& M from iLUT, kLUT, sLUT & sram respectively. The value
of i helps the block md5 fsm decide the ordering of A, B, C
& D, and thus the values of A, B, C, D, M, k & S are fed
to the block md5 core. Now, the block md5 core applies the
required function from the 4 to the fed inputs. These output
values are put back into A, B, C & D registers, thus completing
one iteration.
After 64 of such iterations, the output is available to us as
(A,B,C,D). In this implementation, the 512-bit message has to
be held at input for 16 iterations, so that the sram can store
all 16 chunks, and then the hash computation is performed.
However, in the first 16 iterations of i are in ascending order,
which means the block md5 core can take through inputs
along with sram, thus instead of taking input in 16 iterations
and then another 64 iterations for calculating hash, the first
16 iterations are also utilized by giving a through input from
the message to the block md5 core and sram for the first 16
iterations, later taking message from sram only. Using this the
number of iterations can be reduced from 80 (16 catching +
64 computation iterations) to 64, which will save shave some
time off the time required from hash calculation.
B. Edited
Two techniques can be used to reduce the hardware re-
quirements of MD5 algorithm when it is described as shown
in Fig.2. These two techniques are, Reducing the message
size from 512-bits to 128-bits or 64-bits, or Reducing the
Fig. 3. All possible combinations of hardware reductions
computation iterations from 64 to 16. These values, 512-bits
to 128-bits & 64 iterations to 16 iterations, are determined
by a scaling of factor 4, which has been chosen as the test
scaling factor to try and provide the best trade-off between
Computational complexity & Integrity verification of data.
Fig.3 shows the 4 possible combinations that are imple-
mented to be compared against each other on the metrics
collisions, synthesis reports and time required for hash calcula-
tion. The values ×64 or ×16 present below the MD5 block in
Fig.3 signifies the number of iterations for each of the different
combinations of possible hardware reductions.
In the original verilog implementation, all registers and
values (iLUT, kLUT & sLUT) are defined for a block size of
32-bit each (128-bit total) [10]. To scale down by a factor of 4,
the blocks (A,B,C,D) will have a lateral width of 8-bits. Thus
the message must broken into 16 × 8-bit chunks, leading the
input message size to be changed to 128-bit. Simultaneously,
these 4 blocks together also form a output hash of 32-bits
(4 × 8-bit blocks). The values of iLUT are dependent on the
number of iterations, while the values in kLUT & sLUT are
dependent on the block size. Thus while scaling down the
architecture size by a factor of 4, only the latter two are
relevant, while scaling down the number of iterations makes
iLUT relevant.
V. S CALING DOWN
The two methodologies to scale down the original MD5
hash algorithms, namely by Architecture and Iterations, are
elaborated here.

10th ICCCNT 2019

July 6-8, 2019, IIT - Kanpur
Kanpur,
Authorized licensed use limited to: University of Exeter. Downloaded India
on May 07,2020 at 07:51:50 UTC from IEEE Xplore. Restrictions apply.
 IEEE - 45670
A. Architecture
The relevant kLUT and sLUT are discussed changed ac-
cordingly. The values for kLUT are calculated by,
K[i] = 232 × | sin(i + 1)|
In Eq.6, all i are normal iterating constants, taken as radians
for sin, thus giving predetermined pseudo-random values. The
K[i] here is a 32-bit variable, changing which into 8-bit
during definitions transforms all random addition values to 8-
bit without problems. Further, for sLUT, the shift values are in
range 5 to 23, which can’t be mapped straight to the range of 1
to 8 without compromising the extent of properties possessed
by the hash algorithm as a whole. Initially following equation
maps the 5 to 23 range values (for 32-bit blocks) to 0 to 8
shift values.
S8 [i] = S32 [i] mod 8 (7)
In Eq.7, S8 [i] signifies all sLUT values for 8-bit blocks,
while S32 [i] signify all shift values for 32-bit blocks. Due to
non-ideal mapping in Eq.7, some shift values come out as 0 &
8 which both mean no shift at all, and some shift values come
out to be same for previous & next cycle, which disqualifies
this method from being applied. To devise the shift values
for sLUT the original shift values are studied, to find their
relation to next shift values, and their effect on the blocks.
After understanding the relationships between shift values and
their impact, values for S8 [i] emulating similar relationships
and having similarr impact can be determined.
The original sLUT has 4 values which repeat 4 times for one
of 4 functions (F, G, H & I). Thus each of the 4 functions has
a set of 4 values that repeat 4 times to complete 16 iterations.
These 4 values (for each of the 4 functions) are assigned from
one quarter of the range 1 to 32, except the last value, which
belongs to the same range as the third shift value. The first
shift value belongs to 1 to 8, the second belongs to 9 to 16
, and the third & fourth belong to 17 to 23. There is another
limit on the fourth shift value being greater than the third shift
value. Using similar relationships, the sLUT values for 8-bit
blocks are taken from 1 or 2 for the first value, 3 or 4 for
the second, and 5 to 7 for the third and fourth. For the third
and fourth shift values, for ensuring that fourth value can be
greater than the third, while maintaining some change between
the 4 groups according to functions, an extra value from the
fourth quarter of 1 to 8 range is also included.
Similar techniques are used for scaling down the 8-bit
block architecture to 4-bit block architecture. At 4-bit block
architecture, the message size becomes 64-bit (16×4-bit) size,
while the hash becomes 16-bit size (4 × 4-bit). The values for
kLUT can be found similar to Eq.6, by taking the register
lateral width as 4-bit. However, while scaling down sLUT to
shift values in range 1 to 4, scaling down from 32 is not
feasible, thus shift values are found by scaling down from 8.
S4 [i] = S8 [i] mod 4
In Eq.8, Due a very small range (1 to 4), redundancies in
shifting are unavoidable, even after conforming these shift val-
10th ICCCNT 2019
July 6-8, 2019, IIT - Kanpur
Authorized licensed use limited to: University of Exeter. Downloaded
ues to relationships and impact of original shift values (S32 [i]).
Thus, negative impact to the message-digest is expected here
(32-bit block to 4-bit block) more than 32-bit block to 8-bit
block.
(6)
B. Iteration
The relevant look-up table, iLUT, is discussed here, along
with feeding and computation characteristics, as they are also
affected by iteration scale down.
In 64 iterations cycle (×64), the four functions , F, G, H
& I, each get 16 iterations, into which 16 message chunks,
are fed in accordance to order outlined in iLUT. In iLUT, the
values are given according to Eq.5. For scaling these values
down to 16 iterations (×16), we can not simply use I×16 [i] =
I×64 [i] mod 4 as the number of values present in iLUT×64 is
64, while for iLUT×16 is 16. Not only that, as both have to
chose from 16 message chunks, they have to have all values
ranging from 1 to 16. iLUT×16 must have all values from 1
to 16, only in a different order than ascending. This order can
be similar to the one described for iLUT×64 , where instead of
4 groups 16 values each, we take 2 groups, one of 4 values,
and the other consisting of 12 values. This can be achieved in
the following manner.

i 1≤i≤4
iLU T×16 = (9)
(5 × i) mod 12 + 5 5 ≤ i ≤ 16
In Eq.9, we can use any one of the 3 remaining equations
from Eq.5. Any of these will give satisfactory randomness
to the values, while exhausting all the values ranging from
5 to 12. Although this ×16 equation will not give the same
message-digest characteristics as ×64, it is used for lack of
other options.
Moreover, as stated earlier for ×64, the first 16 iterations
are fed straight to the block md5 core while simultaneously
being stored in sram. This cannot be done as for ×16 the first
4 iterations only have ascending order message chunks due
to normal iLUT values, and the remaining are out of order,
which means these chunks must be first stored in sram and
then fed to the block md5 core. This results in ×16 needing
16 iterations for storing, and then another 16 iterations to
compute the message-digest, unlike ×64, which requires 64
iterations for both storage of message chunks (in the first 16)
and computing message-digest.
VI. P ERFORMANCE
The measurements taken for measurement of performance
of these different combinations of architecture need to be
standardized. This is achieved by taken random values as
input to the message-digest algorithm, and then comparing
the collision rate of the message-digests that are outputted
by the algorithm with different architectures. At the same
time an output signal of the message must be available for
(8)
comparison and distinction of different message-digests. Here
either a through output from sram can be established, however
this is complicated to implement, thus the input message must
Kanpur,
India
on May 07,2020 at 07:51:50 UTC from IEEE Xplore. Restrictions apply.
 IEEE - 45670
Fig. 4. 16-bit Fibonacci LFSR
persist till the message-digest is found, that is, it must be
registered.
A. Linear Feedback Shift Register
The random inputs are nearly impossible to simulate as
hardware without significantly impacting performance, which
leads to usage of pseudo-random pattern generator here.
Pseudo-random pattern generator is implemented here as a
Linear Feedback Shift Register (LFSR), whose size is equal
to input message size, that is, it has two sizes, 128-bit & 64-bit.
Here Fibonacci LFSRs, shown in Fig.4[11], are used instead
of Galois LFSRs due to their simplicity in implementation,
and also because in Galois LFSR the output bit needs to be
examined individually [12]. To create a 128-bit LFSR, the
feedback taps are at the 128th, 126th, 101st & 99th bits, while
for a 64-bit LFSR, the feedback taps are at 64th, 63rd, 61st
& 60th bits [13].
The output from LFSR is fed to the block md5 ctl as a
16 message chunk parts. This is best achieved by using a
Multiplexer and counter. After the message is fed, the LFSR
must not be clocked to increment until the output message-
digest and the original message are both saved in the log file
for simulation. The pseudo-random patterns are achieved by
starting the LFSR with pre-loaded value, and then pushing the
LFSR to it’s next state. Due to the nature of LFSR to shift
values, the pseudo-random patterns are available.
B. Measurements
Due to processing limitations, only 5 million message-
digests are simulated, which is a skewed data set. To ensure
fair testing, 1 million random message-hash pairs are chosen
Fig. 5. Message-Digest Collisions
10th ICCCNT 2019
July 6-8, 2019, IIT - Kanpur
Kanpur,
Authorized licensed use limited to: University of Exeter. Downloaded
on May
Fig. 6. Collision Distribution for 16-bit Hash
for the data set. Fig.5 shows the collisions of all recorded
message-digests, out of 1,048,575 total data sets for each
of the 4 implementations. As can be seen in the data, 32-
bit message digests have minimal collisions compared to 16-
bit message digests. In 32-bit architecture, ×64 has 1,164
collisions, that is 2,328 message-digests are same for different
message inputs. This is not comparable to the theoretical
limit of 1 collision for 232 unique messages. However, in the
context of error checking in a IoT edge device bit-stream,
only 0.222% message-digests collide, making the collision rate
acceptable. Similarly, in ×16, there are 1,187 collisions which
arise due to 2,374 unique message-digests, which account for
only 0.2264% of total message-digests recorded. For 16-bit
message-digest, not a single message-digest was found that
was not colliding with the message-digest from a different
input message. Due to the randomly chosen input messages,
it can be assumed that there are no non-colliding message-
digests in 16-bit hash algorithm.
Due to all message-digests having a collision with atleast
one other message-digest for the message-digest size of 16-bit,
the relation between number of message-digests and number
of occurrences is shown in Fig.6. From this graph it can be
seen that not all message-digests have the same distribution
for collisions, it varies with the number of occurrences. In
Fig.6, x-axis shows the number of collisions, that is 100
input messages having the same message-digest gives 100
collisions, while y-axis denotes the number of message-digests
participating in the given number of collisions. As can be seen,
for ×64, more message-digests are present at lower number
of collisions, while for ×16, higher number of collisions
also house some message-digests. This means, in ×64 the
probability of having small collision is more than that in ×16,
and therefore, for such a high collision record, all options to
reduce collisions must be taken. Also, the highest number of
collision in ×64 is 233, while for ×16 the highest number of
collisions is 339.
Fig.7 shows the important parameters from the synthesis
report from all 4 possible combinations of the MD5 algorithm
avenues for scaling down. From the graph, it can be seen that
32-bit architecture utilizes more Registers, LUTs & Flipflops
than the 16-bit architecture, while using lesser Multiplexers.
India
07,2020 at 07:51:50 UTC from IEEE Xplore. Restrictions apply.
 IEEE - 45670
Fig. 7. Synthesis Report
This can be attributed to 32-bit architecture needing more
storage, while the 16-bit architecture requiring more signals
controlling actions, owing to lesser storage, thus requiring
more Multiplexers than 32-bit architecture. Similarly, ×64
iterations require more Registers, LUTs and Flipflops than
×16, while ×16 iterations require more Multiplexers than ×64
iterations. This can be attributed to ×64 requiring architecture
to manage through inputs of message to sram, while ×16
requiring no such architecture.
Fig.8 shows the average time taken to calculate the message-
digest for one input message when the data-set of 1,048,575
is taken. There is no effect of architecture size on time
taken, only the number of iterations. ×64 iterations take
680ns (6.8 × 10−7 seconds), while ×16 iterations take 380ns
(3.8 × 10−7 seconds). For ×64, one iteration takes 10ns,
taking computation cycle to 640ns, with 40ns between two
instances of computation to record, iterate LFSR, and reset the
architecture. Similarly, for ×16, computation cycle is 160ns
long, while the data capture is just as long (160ns), but to
ensure flawless data capture another 20ns are given before
computation cycle starts. The reset and LFSR iterate cycles
take the same time (40ns), thus bringing the total average cycle
time to 380ns.
Fig. 8. Time taken per Message-Digest
10th ICCCNT 2019
July 6-8, 2019, IIT - Kanpur
Kanpur,
Authorized licensed use limited to: University of Exeter. Downloaded
on May
VII. C ONCLUSION
This paper presents the different possibilities of a modified
MD5 algorithm aiming to be implemented on Low-End IoT
edge devices. We have also shown the relative performance
characteristics in terms of message-digest collisions, synthesis
of components and time taken for hashing for the different
scale-down architectures. Reducing the message-digest size
has severe impact on integrity verification property of hashing,
and must be avoided, meanwhile reducing the number of iter-
ations has minimal effect, while highly reducing architecture
and time costs, and should be implemented.
However, one thing left to be noticed is that all con-
clusions made are from simulation alone, and not FPGA
board implementation, which can disrupt simulations with an
unforseen variable. Also, fuzzy hashing can, more efficiently
and effectively, help in identifying files that contain a high
percentage of similarities, whose hardware implementation is
the future work involved in this publication.
R EFERENCES
[1] Rogaway, Phillip, and Thomas Shrimpton. ”Cryptographic hash-function
basics: Definitions, implications, and separations for preimage resistance,
second-preimage resistance, and collision resistance.” International work-
shop on fast software encryption. Springer, Berlin, Heidelberg, 2004.
[2] Bertoni, Guido, et al. ”The keccak sha-3 submission.” Submission to
NIST (Round 3) 6.7 (2011): 16.
[3] Wang, Xiaoyun, and Hongbo Yu. ”How to break MD5 and other hash
functions.” Annual international conference on the theory and applications
of cryptographic techniques. Springer, Berlin, Heidelberg, 2005.
[4] Rivest, Ronald. ”The MD5 message-digest algorithm.” No. RFC 1321.
1992.
[5] Yang, Kaiyuan, David Blaauw, and Dennis Sylvester. ”Hardware designs
for security in Ultra-Low-Power IoT systems: an overview and survey.”
IEEE Micro 37.6 (2017): 72-89.
[6] Didla, Shammi, Aaron Ault, and Saurabh Bagchi. ”Optimizing AES for
embedded devices and wireless sensor networks.” Proceedings of the
4th International Conference on Testbeds and research infrastructures for
the development of networks & communities. ICST (Institute for Com-
puter Sciences, Social-Informatics and Telecommunications Engineering),
2008.
[7] Rivest, Ronald. ”The MD4 message-digest algorithm.” No. RFC 1320.
1992.
[8] Sedov, Stanislav (2011). ”MD5 core in verilog.” GitHub repository,
https://github.com/stass/md5 core
[9] ”Linear-feedback shift register.” Wikipedia contributors. Wikipedia, The
Free Encyclopedia. Wikipedia, The Free Encyclopedia, 19 Feb. 2019.
[10] Goresky, Mark, and Andrew M. Klapper. ”Fibonacci and Galois repre-
sentations of feedback-with-carry shift registers.” IEEE Transactions on
Information Theory 48.11 (2002): 2826-2836
[11] George, Maria, and Peter Alfke. ”Linear feedback shift registers in virtex
devices.” Xilinx apprication note XAPP210 (2007).
India
07,2020 at 07:51:50 UTC from IEEE Xplore. Restrictions apply.