High-speed cryptography Do we care about speed? Daniel J. Bernstein - - PowerPoint PPT Presentation

1

High-speed cryptography Daniel J. Bernstein University of Illinois at Chicago & Technische Universiteit Eindhoven with some slides from: Tanja Lange Technische Universiteit Eindhoven

2

Do we care about speed? Almost all software is much slower than it could be. Is software applied to much data? Usually not. Usually the wasted CPU time is negligible. But crypto software should be applied to all communication. Crypto that’s too slow ⇒ fewer users ⇒ fewer cryptanalysts ⇒ less attractive for everybody.

1

High-speed cryptography

• J. Bernstein

University of Illinois at Chicago & echnische Universiteit Eindhoven some slides from: Lange echnische Universiteit Eindhoven

2

Do we care about speed? Almost all software is much slower than it could be. Is software applied to much data? Usually not. Usually the wasted CPU time is negligible. But crypto software should be applied to all communication. Crypto that’s too slow ⇒ fewer users ⇒ fewer cryptanalysts ⇒ less attractive for everybody. Implemento e.g. Variable-length-big-integer arithmetic consumes Includes

• ptimized

1

cryptography Bernstein Illinois at Chicago & Universiteit Eindhoven from: Universiteit Eindhoven

2

Do we care about speed? Almost all software is much slower than it could be. Is software applied to much data? Usually not. Usually the wasted CPU time is negligible. But crypto software should be applied to all communication. Crypto that’s too slow ⇒ fewer users ⇒ fewer cryptanalysts ⇒ less attractive for everybody. Implementors pursue e.g. Variable-length-big-integer arithmetic library inside consumes 50000 lines Includes 38 asm implementations

• ptimized for various

1

Chicago & Eindhoven Eindhoven

2

Do we care about speed? Almost all software is much slower than it could be. Is software applied to much data? Usually not. Usually the wasted CPU time is negligible. But crypto software should be applied to all communication. Crypto that’s too slow ⇒ fewer users ⇒ fewer cryptanalysts ⇒ less attractive for everybody. Implementors pursue speed e.g. Variable-length-big-integer arithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

2

Do we care about speed? Almost all software is much slower than it could be. Is software applied to much data? Usually not. Usually the wasted CPU time is negligible. But crypto software should be applied to all communication. Crypto that’s too slow ⇒ fewer users ⇒ fewer cryptanalysts ⇒ less attractive for everybody.

3

Implementors pursue speed e.g. Variable-length-big-integer arithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

2

Do we care about speed? Almost all software is much slower than it could be. Is software applied to much data? Usually not. Usually the wasted CPU time is negligible. But crypto software should be applied to all communication. Crypto that’s too slow ⇒ fewer users ⇒ fewer cryptanalysts ⇒ less attractive for everybody.

3

Implementors pursue speed e.g. Variable-length-big-integer arithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

e.g. ECDSA verification computes (S−1H(M))B + (S−1R)A. OpenSSL has complicated code for fast computation of S−1. Much simpler code would make verification considerably slower.

2

care about speed? Almost all software is slower than it could be. ware applied to much data? Usually not. Usually the CPU time is negligible. crypto software should be applied to all communication. that’s too slow ⇒ users ⇒ fewer cryptanalysts attractive for everybody.

3

Implementors pursue speed e.g. Variable-length-big-integer arithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

e.g. ECDSA verification computes (S−1H(M))B + (S−1R)A. OpenSSL has complicated code for fast computation of S−1. Much simpler code would make verification considerably slower. Applications e.g. Latest practices” (2012) sa a regular it is estimated can safely at least the Signing and bit key tak 1024-bit (such as four times

2

• ut speed?

are is than it could be. applied to much data? Usually the time is negligible. are should be communication.

• slow ⇒

fewer cryptanalysts attractive for everybody.

3

Implementors pursue speed e.g. Variable-length-big-integer arithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

e.g. ECDSA verification computes (S−1H(M))B + (S−1R)A. OpenSSL has complicated code for fast computation of S−1. Much simpler code would make verification considerably slower. Applications pursue e.g. Latest “DNSSEC practices” recommendation (2012) says “No one a regular 1024-bit it is estimated that can safely use 1024-bit at least the next ten Signing and verifying bit key takes longer 1024-bit key : : : public (such as verification) four times slower.”

2

be. much data? negligible. should be communication. cryptanalysts everybody.

3

Implementors pursue speed e.g. Variable-length-big-integer arithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

e.g. ECDSA verification computes (S−1H(M))B + (S−1R)A. OpenSSL has complicated code for fast computation of S−1. Much simpler code would make verification considerably slower. Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has brok a regular 1024-bit [RSA] key it is estimated that most zones can safely use 1024-bit keys at least the next ten years : : Signing and verifying with a bit key takes longer than with 1024-bit key : : : public operations (such as verification) are about four times slower.”

3

Implementors pursue speed e.g. Variable-length-big-integer arithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

e.g. ECDSA verification computes (S−1H(M))B + (S−1R)A. OpenSSL has complicated code for fast computation of S−1. Much simpler code would make verification considerably slower.

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.”

3

Implementors pursue speed ariable-length-big-integer rithmetic library inside OpenSSL consumes 50000 lines of code. Includes 38 asm implementations

• ptimized for various CPUs.

ECDSA verification computes (M))B + (S−1R)A. enSSL has complicated code ast computation of S−1. simpler code would make verification considerably slower.

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.” DNSSEC 2048-bit controlled

3

pursue speed riable-length-big-integer ry inside OpenSSL lines of code. implementations rious CPUs. verification computes (S−1R)A. complicated code computation of S−1. de would make considerably slower.

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.” DNSSEC key sizes, 2048-bit DNSSEC controlled b

3

eed riable-length-big-integer OpenSSL code. implementations CPUs. computes . code

1.

make slower.

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.” DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master k controlled by U.S.

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S.

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

signature

• 1024-bit “zone-signing key”

4

Applications pursue speed e.g. Latest “DNSSEC operational practices” recommendation (2012) says “No one has broken a regular 1024-bit [RSA] key : : : it is estimated that most zones can safely use 1024-bit keys for at least the next ten years : : : Signing and verifying with a 2048- bit key takes longer than with a 1024-bit key : : : public operations (such as verification) are about four times slower.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

signature

• 1024-bit “zone-signing key”

signatures

• a few *.org sites

4

Applications pursue speed Latest “DNSSEC operational ractices” recommendation says “No one has broken regular 1024-bit [RSA] key : : : estimated that most zones safely use 1024-bit keys for least the next ten years : : : Signing and verifying with a 2048- takes longer than with a 1024-bit key : : : public operations as verification) are about times slower.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

signature

• 1024-bit “zone-signing key”

signatures

• a few *.org sites

2011 Weimerskirch security “V2V safet broadcast second, and 1,000 or second. available amount messages an actual are processed, security messages

4

pursue speed “DNSSEC operational recommendation

• ne has broken

1024-bit [RSA] key : : : that most zones 1024-bit keys for ten years : : : verifying with a 2048- longer than with a public operations verification) are about er.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

signature

• 1024-bit “zone-signing key”

signatures

• a few *.org sites

2011 Weimerskirch security for car communication: “V2V safety applications broadcast 10 messages second, and a vehicle 1,000 or more messages

• second. There are

available to process amount of messages: messages that might an actual impact to are processed, or (2) security hardware to messages is applied.”

4

erational recommendation roken ey : : : zones ys for : : : a 2048- with a erations about

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

signature

• 1024-bit “zone-signing key”

signatures

• a few *.org sites

2011 Weimerskirch survey of security for car communication: “V2V safety applications will broadcast 10 messages per second, and a vehicle will receive 1,000 or more messages per

• second. There are two approaches

available to process such a high amount of messages: (1) only messages that might impose an actual impact to a vehicle are processed, or (2) dedicated security hardware to process messages is applied.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

signature

• 1024-bit “zone-signing key”

signatures

• a few *.org sites

6

2011 Weimerskirch survey of security for car communication: “V2V safety applications will broadcast 10 messages per second, and a vehicle will receive 1,000 or more messages per

• second. There are two approaches

available to process such a high amount of messages: (1) only messages that might impose an actual impact to a vehicle are processed, or (2) dedicated security hardware to process all messages is applied.”

5

DNSSEC key sizes, 2016.11.28: 2048-bit DNSSEC master key controlled by U.S. signature

• 2048-bit “zone-signing key”

signature

• 2048-bit .org master key

signature

• 1024-bit “zone-signing key”

signatures

• a few *.org sites

6

2011 Weimerskirch survey of security for car communication: “V2V safety applications will broadcast 10 messages per second, and a vehicle will receive 1,000 or more messages per

• second. There are two approaches

available to process such a high amount of messages: (1) only messages that might impose an actual impact to a vehicle are processed, or (2) dedicated security hardware to process all messages is applied.” 2014 Gho Pullini–Micheli–Burleson–Ca “A lightw system fo biosensors”: the recently Keccak s implemented encryption the newly scheme, large am testing p standardization

5

sizes, 2016.11.28: DNSSEC master key by U.S. signature “zone-signing key” signature master key signature “zone-signing key” signatures *.org sites

6

2011 Weimerskirch survey of security for car communication: “V2V safety applications will broadcast 10 messages per second, and a vehicle will receive 1,000 or more messages per

• second. There are two approaches

available to process such a high amount of messages: (1) only messages that might impose an actual impact to a vehicle are processed, or (2) dedicated security hardware to process all messages is applied.” 2014 Ghoreishizade Pullini–Micheli–Burleson–Ca “A lightweight cryptographic system for implantable biosensors”: “This the recently standa Keccak secure hash implemented in an encryption mode : the newly standardized scheme, we benefit large amount of analysis testing performed standardization pro

5

2016.11.28: key ey” ey ey”

6

2011 Weimerskirch survey of security for car communication: “V2V safety applications will broadcast 10 messages per second, and a vehicle will receive 1,000 or more messages per

• second. There are two approaches

available to process such a high amount of messages: (1) only messages that might impose an actual impact to a vehicle are processed, or (2) dedicated security hardware to process all messages is applied.” 2014 Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Ca “A lightweight cryptographic system for implantable biosensors”: “This design uses the recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting the newly standardized Keccak scheme, we benefit from the large amount of analysis and testing performed during the standardization process. : : :

6

2011 Weimerskirch survey of security for car communication: “V2V safety applications will broadcast 10 messages per second, and a vehicle will receive 1,000 or more messages per

• second. There are two approaches

available to process such a high amount of messages: (1) only messages that might impose an actual impact to a vehicle are processed, or (2) dedicated security hardware to process all messages is applied.”

7

2014 Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara “A lightweight cryptographic system for implantable biosensors”: “This design uses the recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting the newly standardized Keccak scheme, we benefit from the large amount of analysis and testing performed during the standardization process. : : :

6

eimerskirch survey of y for car communication: safety applications will roadcast 10 messages per second, and a vehicle will receive

• r more messages per
• second. There are two approaches

available to process such a high amount of messages: (1) only messages that might impose actual impact to a vehicle cessed, or (2) dedicated y hardware to process all messages is applied.”

7

2014 Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara “A lightweight cryptographic system for implantable biosensors”: “This design uses the recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting the newly standardized Keccak scheme, we benefit from the large amount of analysis and testing performed during the standardization process. : : : we have

• f rounds

guarantee the Keccak

6

eimerskirch survey of communication: applications will messages per vehicle will receive messages per re two approaches ess such a high messages: (1) only might impose t to a vehicle r (2) dedicated re to process all applied.”

7

2014 Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara “A lightweight cryptographic system for implantable biosensors”: “This design uses the recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting the newly standardized Keccak scheme, we benefit from the large amount of analysis and testing performed during the standardization process. : : : we have used the same

• f rounds for all in

guarantee the securit the Keccak proposal.

6

• f

communication: will er receive er approaches high

• nly
• se

vehicle dedicated cess all

7

2014 Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara “A lightweight cryptographic system for implantable biosensors”: “This design uses the recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting the newly standardized Keccak scheme, we benefit from the large amount of analysis and testing performed during the standardization process. : : : we have used the same numb

• f rounds for all in order to

guarantee the security claim the Keccak proposal.

7

2014 Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara “A lightweight cryptographic system for implantable biosensors”: “This design uses the recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting the newly standardized Keccak scheme, we benefit from the large amount of analysis and testing performed during the standardization process. : : :

8

we have used the same number

• f rounds for all in order to

guarantee the security claim of the Keccak proposal.

7

2014 Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara “A lightweight cryptographic system for implantable biosensors”: “This design uses the recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting the newly standardized Keccak scheme, we benefit from the large amount of analysis and testing performed during the standardization process. : : :

8

we have used the same number

• f rounds for all in order to

guarantee the security claim of the Keccak proposal. However, instead of using the standard sizes for bitrate and capacity, we reduced the overall state size in order to achieve a compact implementation with a security level that would not have been possible at this cost with any

• ther authenticated encryption
• scheme. The data block size and

state size are selected as 4 and 100 bits, respectively.”

7

Ghoreishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara lightweight cryptographic for implantable biosensors”: “This design uses recently standardized SHA-3 Keccak secure hash function implemented in an authenticated encryption mode : : : By selecting newly standardized Keccak scheme, we benefit from the mount of analysis and performed during the rdization process. : : :

8

we have used the same number

• f rounds for all in order to

guarantee the security claim of the Keccak proposal. However, instead of using the standard sizes for bitrate and capacity, we reduced the overall state size in order to achieve a compact implementation with a security level that would not have been possible at this cost with any

• ther authenticated encryption
• scheme. The data block size and

state size are selected as 4 and 100 bits, respectively.” Standards e.g. NIST’s “Security factor in Rijndael adequate Serpent high securit (Emphasis So why didn’

7

ishizadeh–Yalcin– Pullini–Micheli–Burleson–Carrara cryptographic implantable This design uses standardized SHA-3 hash function an authenticated : : : By selecting standardized Keccak enefit from the analysis and rmed during the

• process. : : :

8

we have used the same number

• f rounds for all in order to

guarantee the security claim of the Keccak proposal. However, instead of using the standard sizes for bitrate and capacity, we reduced the overall state size in order to achieve a compact implementation with a security level that would not have been possible at this cost with any

• ther authenticated encryption
• scheme. The data block size and

state size are selected as 4 and 100 bits, respectively.” Standards pursue sp e.g. NIST’s final AES “Security was the factor in the evaluation Rijndael appears to adequate security Serpent appears to high security margin.” (Emphasis added.) So why didn’t Serp

7

alcin– Pullini–Micheli–Burleson–Carrara cryptographic uses SHA-3 function authenticated selecting Keccak the and the : :

8

we have used the same number

• f rounds for all in order to

guarantee the security claim of the Keccak proposal. However, instead of using the standard sizes for bitrate and capacity, we reduced the overall state size in order to achieve a compact implementation with a security level that would not have been possible at this cost with any

• ther authenticated encryption
• scheme. The data block size and

state size are selected as 4 and 100 bits, respectively.” Standards pursue speed e.g. NIST’s final AES report: “Security was the most impo factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win?

8

we have used the same number

• f rounds for all in order to

guarantee the security claim of the Keccak proposal. However, instead of using the standard sizes for bitrate and capacity, we reduced the overall state size in order to achieve a compact implementation with a security level that would not have been possible at this cost with any

• ther authenticated encryption
• scheme. The data block size and

state size are selected as 4 and 100 bits, respectively.”

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win?

8

we have used the same number

• f rounds for all in order to

guarantee the security claim of the Keccak proposal. However, instead of using the standard sizes for bitrate and capacity, we reduced the overall state size in order to achieve a compact implementation with a security level that would not have been possible at this cost with any

• ther authenticated encryption
• scheme. The data block size and

state size are selected as 4 and 100 bits, respectively.”

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win? Maybe side-channel security?

8

have used the same number rounds for all in order to rantee the security claim of Keccak proposal. However,

• f using the standard

for bitrate and capacity, reduced the overall state size r to achieve a compact implementation with a security that would not have been

• ssible at this cost with any

authenticated encryption

• scheme. The data block size and

size are selected as 4 and bits, respectively.”

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win? Maybe side-channel security? “The op are among against timing

8

the same number in order to security claim of

• sal. However,

the standard and capacity,

• verall state size

achieve a compact with a security not have been cost with any authenticated encryption data block size and selected as 4 and tively.”

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win? Maybe side-channel security? “The operations used are among the easiest against timing and

8

number to claim of ever, standard capacity, state size compact security been any encryption size and and

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win? Maybe side-channel security? “The operations used by Serp are among the easiest to defend against timing and power attacks.”

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win? Maybe side-channel security?

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.”

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win? Maybe side-channel security?

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.”

9

Standards pursue speed e.g. NIST’s final AES report: “Security was the most important factor in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : Serpent appears to offer a high security margin.” (Emphasis added.) So why didn’t Serpent win? Maybe side-channel security?

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.” Great! Why didn’t Serpent win?

9

Standards pursue speed NIST’s final AES report: Security was the most important in the evaluation : : : Rijndael appears to offer an adequate security margin. : : : ent appears to offer a security margin.” (Emphasis added.) why didn’t Serpent win? side-channel security?

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.” Great! Why didn’t Serpent win? Aha: Soft

9

pursue speed final AES report: the most important evaluation : : : to offer an y margin. : : : to offer a rgin.” added.) Serpent win? side-channel security?

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.” Great! Why didn’t Serpent win? Aha: Software speed!

9

rt: important : an : : : win? security?

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.” Great! Why didn’t Serpent win? Aha: Software speed!

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.” Great! Why didn’t Serpent win?

11

Aha: Software speed!

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.” Great! Why didn’t Serpent win?

11

Aha: Software speed! “Serpent is generally the slowest of the finalists in software speed for encryption and decryption. : : : Serpent provides consistently low-end performance.”

10

“The operations used by Serpent are among the easiest to defend against timing and power attacks.” Hardware speed: “Serpent is well suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer the highest throughput of any

• f the finalists for non-feedback
• modes. : : : Efficiency is generally

very good, and Serpent’s speed is independent of key size.” Great! Why didn’t Serpent win?

11

Aha: Software speed! “Serpent is generally the slowest of the finalists in software speed for encryption and decryption. : : : Serpent provides consistently low-end performance.” Conclusion: “NIST judged Rijndael to be the best overall algorithm for the AES. Rijndael appears to be consistently a very good performer in both hardware and software [and offers good key agility, low memory, easy defense, fast defense, flexibility, parallelism].”

10

• perations used by Serpent
• ng the easiest to defend

against timing and power attacks.” are speed: “Serpent is suited to restricted-space environments : : : Fully pipelined implementations of Serpent offer highest throughput of any finalists for non-feedback

• des. : : : Efficiency is generally

good, and Serpent’s speed is endent of key size.” Why didn’t Serpent win?

11

Aha: Software speed! “Serpent is generally the slowest of the finalists in software speed for encryption and decryption. : : : Serpent provides consistently low-end performance.” Conclusion: “NIST judged Rijndael to be the best overall algorithm for the AES. Rijndael appears to be consistently a very good performer in both hardware and software [and offers good key agility, low memory, easy defense, fast defense, flexibility, parallelism].” Want fast Bad examples: The pursuit damages e.g. using e.g. using e.g. skipping

10

used by Serpent easiest to defend and power attacks.” eed: “Serpent is restricted-space : Fully pipelined

• f Serpent offer

throughput of any r non-feedback Efficiency is generally Serpent’s speed is ey size.” didn’t Serpent win?

11

Aha: Software speed! “Serpent is generally the slowest of the finalists in software speed for encryption and decryption. : : : Serpent provides consistently low-end performance.” Conclusion: “NIST judged Rijndael to be the best overall algorithm for the AES. Rijndael appears to be consistently a very good performer in both hardware and software [and offers good key agility, low memory, easy defense, fast defense, flexibility, parallelism].” Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit e.g. using 100-bit “SHA-3”. e.g. skipping verification.

10

Serpent defend attacks.” is restricted-space elined ent offer any non-feedback generally speed is ent win?

11

Aha: Software speed! “Serpent is generally the slowest of the finalists in software speed for encryption and decryption. : : : Serpent provides consistently low-end performance.” Conclusion: “NIST judged Rijndael to be the best overall algorithm for the AES. Rijndael appears to be consistently a very good performer in both hardware and software [and offers good key agility, low memory, easy defense, fast defense, flexibility, parallelism].” Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification.

11

Aha: Software speed! “Serpent is generally the slowest of the finalists in software speed for encryption and decryption. : : : Serpent provides consistently low-end performance.” Conclusion: “NIST judged Rijndael to be the best overall algorithm for the AES. Rijndael appears to be consistently a very good performer in both hardware and software [and offers good key agility, low memory, easy defense, fast defense, flexibility, parallelism].”

12

Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification.

11

Aha: Software speed! “Serpent is generally the slowest of the finalists in software speed for encryption and decryption. : : : Serpent provides consistently low-end performance.” Conclusion: “NIST judged Rijndael to be the best overall algorithm for the AES. Rijndael appears to be consistently a very good performer in both hardware and software [and offers good key agility, low memory, easy defense, fast defense, flexibility, parallelism].”

12

Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification. Good examples: Obtain better speed without damaging security. If security level was too low, scale up: better security for the same performance.

11

Software speed! “Serpent generally the slowest of the finalists in software speed for encryption and decryption. : : : ent provides consistently w-end performance.” Conclusion: “NIST judged Rijndael to be the best overall rithm for the AES. Rijndael rs to be consistently a very erformer in both hardware software [and offers good agility, low memory, easy defense, fast defense, flexibility, rallelism].”

12

Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification. Good examples: Obtain better speed without damaging security. If security level was too low, scale up: better security for the same performance. Success Extensive ECC at a ⇒ modern for practically Requires and optimization Not just not just

11

speed! “Serpent slowest of the are speed for

• ecryption. : : :

consistently rmance.” “NIST judged the best overall the AES. Rijndael consistently a very in both hardware [and offers good memory, easy defense, flexibility,

12

Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification. Good examples: Obtain better speed without damaging security. If security level was too low, scale up: better security for the same performance. Success story: ECC. Extensive work on ECC at a high securit ⇒ modern ECC is for practically all applications. Requires serious analysis and optimization of Not just “polynomial not just “quadratic

11

“Serpent the for

• cryption. : : :

consistently

• verall

Rijndael a very rdware good easy flexibility,

12

Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification. Good examples: Obtain better speed without damaging security. If security level was too low, scale up: better security for the same performance. Success story: ECC. Extensive work on speed of ECC at a high security level ⇒ modern ECC is fast enough for practically all applications. Requires serious analysis and optimization of algorithms. Not just “polynomial time”; not just “quadratic time”.

12

Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification. Good examples: Obtain better speed without damaging security. If security level was too low, scale up: better security for the same performance.

13

Success story: ECC. Extensive work on speed of ECC at a high security level ⇒ modern ECC is fast enough for practically all applications. Requires serious analysis and optimization of algorithms. Not just “polynomial time”; not just “quadratic time”.

12

Want fast and secure Bad examples: The pursuit of speed damages security. e.g. using 1024-bit RSA. e.g. using 100-bit “SHA-3”. e.g. skipping verification. Good examples: Obtain better speed without damaging security. If security level was too low, scale up: better security for the same performance.

13

Success story: ECC. Extensive work on speed of ECC at a high security level ⇒ modern ECC is fast enough for practically all applications. Requires serious analysis and optimization of algorithms. Not just “polynomial time”; not just “quadratic time”. RSA and Rabin–Williams are even faster for signature verification, but slower for keygen, signing, sending keys, sending sigs.

12

fast and secure examples: pursuit of speed damages security. using 1024-bit RSA. using 100-bit “SHA-3”. skipping verification. examples: better speed without damaging security. security level was too low, up: better security same performance.

13

Success story: ECC. Extensive work on speed of ECC at a high security level ⇒ modern ECC is fast enough for practically all applications. Requires serious analysis and optimization of algorithms. Not just “polynomial time”; not just “quadratic time”. RSA and Rabin–Williams are even faster for signature verification, but slower for keygen, signing, sending keys, sending sigs. Some signature-syste 1985 ElGamal: 1990 Schno plus various Patented 1991 DSA, later credited with one 1999 ECDSA: DSA with 2011 EdDSA Schnorr

12

secure speed y. 1024-bit RSA. 100-bit “SHA-3”. verification. eed damaging security. as too low, security erformance.

13

Success story: ECC. Extensive work on speed of ECC at a high security level ⇒ modern ECC is fast enough for practically all applications. Requires serious analysis and optimization of algorithms. Not just “polynomial time”; not just “quadratic time”. RSA and Rabin–Williams are even faster for signature verification, but slower for keygen, signing, sending keys, sending sigs. Some signature-syste 1985 ElGamal: F∗

p

1990 Schnorr: ElGamal plus various improvements. Patented until 2008. 1991 DSA, announce later credited to NSA: with one Schnorr imp 1999 ECDSA: replacing DSA with an elliptic-curve 2011 EdDSA (e.g., Schnorr plus more

12

“SHA-3”. . w,

13

Success story: ECC. Extensive work on speed of ECC at a high security level ⇒ modern ECC is fast enough for practically all applications. Requires serious analysis and optimization of algorithms. Not just “polynomial time”; not just “quadratic time”. RSA and Rabin–Williams are even faster for signature verification, but slower for keygen, signing, sending keys, sending sigs. Some signature-system histo 1985 ElGamal: F∗

p signatures.

1990 Schnorr: ElGamal plus various improvements. Patented until 2008. 1991 DSA, announced by NIST, later credited to NSA: ElGamal with one Schnorr improvement. 1999 ECDSA: replacing F∗

p in

DSA with an elliptic-curve group. 2011 EdDSA (e.g., Ed25519): Schnorr plus more improvements.

13

Success story: ECC. Extensive work on speed of ECC at a high security level ⇒ modern ECC is fast enough for practically all applications. Requires serious analysis and optimization of algorithms. Not just “polynomial time”; not just “quadratic time”. RSA and Rabin–Williams are even faster for signature verification, but slower for keygen, signing, sending keys, sending sigs.

14

Some signature-system history 1985 ElGamal: F∗

p signatures.

1990 Schnorr: ElGamal plus various improvements. Patented until 2008. 1991 DSA, announced by NIST, later credited to NSA: ElGamal with one Schnorr improvement. 1999 ECDSA: replacing F∗

p in

DSA with an elliptic-curve group. 2011 EdDSA (e.g., Ed25519): Schnorr plus more improvements.

13

Success story: ECC. Extensive work on speed of at a high security level dern ECC is fast enough ractically all applications. Requires serious analysis

• ptimization of algorithms.

just “polynomial time”; just “quadratic time”. and Rabin–Williams are even for signature verification, wer for keygen, signing, sending keys, sending sigs.

14

Some signature-system history 1985 ElGamal: F∗

p signatures.

1990 Schnorr: ElGamal plus various improvements. Patented until 2008. 1991 DSA, announced by NIST, later credited to NSA: ElGamal with one Schnorr improvement. 1999 ECDSA: replacing F∗

p in

DSA with an elliptic-curve group. 2011 EdDSA (e.g., Ed25519): Schnorr plus more improvements. ElGamal (R; S) is if BH(M) and R; S Here p is B is standa A is signer’s H(M) is Secret key: Public key: To sign M compute S = r−1

13

ECC.

• n speed of

security level is fast enough all applications. analysis

• f algorithms.
• lynomial time”;

ratic time”. in–Williams are even signature verification, eygen, signing, sending sigs.

14

Some signature-system history 1985 ElGamal: F∗

p signatures.

1990 Schnorr: ElGamal plus various improvements. Patented until 2008. 1991 DSA, announced by NIST, later credited to NSA: ElGamal with one Schnorr improvement. 1999 ECDSA: replacing F∗

p in

DSA with an elliptic-curve group. 2011 EdDSA (e.g., Ed25519): Schnorr plus more improvements. ElGamal verification: (R; S) is signature if BH(M) ≡ ARRS and R; S ∈ {0; 1; : Here p is standard B is standard base, A is signer’s public H(M) is hash of message. Secret key: random Public key: A = B To sign M: generate compute R = Br mo S = r−1(H(M) − a

13

• f

level enough applications. rithms. time”; are even verification, signing, sigs.

14

Some signature-system history 1985 ElGamal: F∗

p signatures.

1990 Schnorr: ElGamal plus various improvements. Patented until 2008. 1991 DSA, announced by NIST, later credited to NSA: ElGamal with one Schnorr improvement. 1999 ECDSA: replacing F∗

p in

DSA with an elliptic-curve group. 2011 EdDSA (e.g., Ed25519): Schnorr plus more improvements. ElGamal verification: (R; S) is signature of M if BH(M) ≡ ARRS (mod p) and R; S ∈ {0; 1; : : : ; p − 2} Here p is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Secret key: random a. Public key: A = Ba mod p. To sign M: generate random compute R = Br mod p, S = r−1(H(M) − aR) mod p

14

Some signature-system history 1985 ElGamal: F∗

p signatures.

1990 Schnorr: ElGamal plus various improvements. Patented until 2008. 1991 DSA, announced by NIST, later credited to NSA: ElGamal with one Schnorr improvement. 1999 ECDSA: replacing F∗

p in

DSA with an elliptic-curve group. 2011 EdDSA (e.g., Ed25519): Schnorr plus more improvements.

15

ElGamal verification: (R; S) is signature of M if BH(M) ≡ ARRS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Here p is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Secret key: random a. Public key: A = Ba mod p. To sign M: generate random r, compute R = Br mod p, S = r−1(H(M) − aR) mod p − 1.

14

signature-system history ElGamal: F∗

p signatures.

Schnorr: ElGamal various improvements. atented until 2008. DSA, announced by NIST, credited to NSA: ElGamal

• ne Schnorr improvement.

ECDSA: replacing F∗

p in

with an elliptic-curve group. EdDSA (e.g., Ed25519): rr plus more improvements.

15

ElGamal verification: (R; S) is signature of M if BH(M) ≡ ARRS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Here p is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Secret key: random a. Public key: A = Ba mod p. To sign M: generate random r, compute R = Br mod p, S = r−1(H(M) − aR) mod p − 1. Hash the Tweak: if BH(M) and R; S Signer: as r−1(H(M Speed impact: Hashing Security serious obstacle strategy a particula

14

signature-system history F∗

p signatures.

ElGamal rovements. 2008.

• unced by NIST,

NSA: ElGamal rr improvement. replacing F∗

p in

elliptic-curve group. (e.g., Ed25519): re improvements.

15

ElGamal verification: (R; S) is signature of M if BH(M) ≡ ARRS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Here p is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Secret key: random a. Public key: A = Ba mod p. To sign M: generate random r, compute R = Br mod p, S = r−1(H(M) − aR) mod p − 1. Hash the exponent Tweak: (R; S) is signature if BH(M) ≡ AH(R)R and R; S ∈ {0; 1; : Signer: as before except r−1(H(M) − aH(R Speed impact: negligible. Hashing R is very Security impact: seems serious obstacle to strategy that relies a particular A exponent.

14

history signatures. rovements. NIST, ElGamal rovement. in group. Ed25519): ements.

15

ElGamal verification: (R; S) is signature of M if BH(M) ≡ ARRS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Here p is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Secret key: random a. Public key: A = Ba mod p. To sign M: generate random r, compute R = Br mod p, S = r−1(H(M) − aR) mod p − 1. Hash the exponent Tweak: (R; S) is signature of if BH(M) ≡ AH(R)RS (mod and R; S ∈ {0; 1; : : : ; p − 2} Signer: as before except S = r−1(H(M) − aH(R)) mod p Speed impact: negligible. Hashing R is very fast. Security impact: seems to b serious obstacle to any attack strategy that relies on choosing a particular A exponent.

15

ElGamal verification: (R; S) is signature of M if BH(M) ≡ ARRS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Here p is standard prime, B is standard base, A is signer’s public key, H(M) is hash of message. Secret key: random a. Public key: A = Ba mod p. To sign M: generate random r, compute R = Br mod p, S = r−1(H(M) − aR) mod p − 1.

16

Hash the exponent Tweak: (R; S) is signature of M if BH(M) ≡ AH(R)RS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Signer: as before except S = r−1(H(M) − aH(R)) mod p − 1. Speed impact: negligible. Hashing R is very fast. Security impact: seems to be serious obstacle to any attack strategy that relies on choosing a particular A exponent.

15

ElGamal verification: is signature of M

) ≡ ARRS

(mod p) ; S ∈ {0; 1; : : : ; p − 2}. is standard prime, standard base, signer’s public key, is hash of message. key: random a. key: A = Ba mod p. sign M: generate random r, compute R = Br mod p,

1(H(M) − aR) mod p − 1.

16

Hash the exponent Tweak: (R; S) is signature of M if BH(M) ≡ AH(R)RS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Signer: as before except S = r−1(H(M) − aH(R)) mod p − 1. Speed impact: negligible. Hashing R is very fast. Security impact: seems to be serious obstacle to any attack strategy that relies on choosing a particular A exponent. Prime-order Choose B standard e.g. take Again verify ECC: H( Signer: same S = r−1 Simpler securit Speed advantage: (when q Less time

15

verification: signature of M

S

(mod p) ; : : : ; p − 2}. rd prime, base, public key, message. random a. Ba mod p. generate random r, mod p, − aR) mod p − 1.

16

Hash the exponent Tweak: (R; S) is signature of M if BH(M) ≡ AH(R)RS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Signer: as before except S = r−1(H(M) − aH(R)) mod p − 1. Speed impact: negligible. Hashing R is very fast. Security impact: seems to be serious obstacle to any attack strategy that relies on choosing a particular A exponent. Prime-order subgroup Choose B to have standard prime diviso e.g. take 3000-bit Again verify BH(M ECC: H(M)B = H Signer: same except S = r−1(H(M) − a Simpler security analysis. Speed advantage: (when q is smaller Less time to transmit

15

p) 2}. . random r, d p − 1.

16

Hash the exponent Tweak: (R; S) is signature of M if BH(M) ≡ AH(R)RS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Signer: as before except S = r−1(H(M) − aH(R)) mod p − 1. Speed impact: negligible. Hashing R is very fast. Security impact: seems to be serious obstacle to any attack strategy that relies on choosing a particular A exponent. Prime-order subgroup Choose B to have order q fo standard prime divisor q of p e.g. take 3000-bit p, 256-bit Again verify BH(M) ≡ AH(R) ECC: H(M)B = H(R)A + S Signer: same except now S = r−1(H(M) − aH(R)) mo Simpler security analysis. Speed advantage: Smaller S (when q is smaller than p − Less time to transmit signature.

16

Hash the exponent Tweak: (R; S) is signature of M if BH(M) ≡ AH(R)RS (mod p) and R; S ∈ {0; 1; : : : ; p − 2}. Signer: as before except S = r−1(H(M) − aH(R)) mod p − 1. Speed impact: negligible. Hashing R is very fast. Security impact: seems to be serious obstacle to any attack strategy that relies on choosing a particular A exponent.

17

Prime-order subgroup Choose B to have order q for standard prime divisor q of p − 1. e.g. take 3000-bit p, 256-bit q. Again verify BH(M) ≡ AH(R)RS. ECC: H(M)B = H(R)A + SR. Signer: same except now S = r−1(H(M) − aH(R)) mod q. Simpler security analysis. Speed advantage: Smaller S (when q is smaller than p − 1). Less time to transmit signature.

16

the exponent eak: (R; S) is signature of M

) ≡ AH(R)RS

(mod p) ; S ∈ {0; 1; : : : ; p − 2}. Signer: as before except S = (M) − aH(R)) mod p − 1. impact: negligible. Hashing R is very fast. Security impact: seems to be

• bstacle to any attack

strategy that relies on choosing rticular A exponent.

17

Prime-order subgroup Choose B to have order q for standard prime divisor q of p − 1. e.g. take 3000-bit p, 256-bit q. Again verify BH(M) ≡ AH(R)RS. ECC: H(M)B = H(R)A + SR. Signer: same except now S = r−1(H(M) − aH(R)) mod q. Simpler security analysis. Speed advantage: Smaller S (when q is smaller than p − 1). Less time to transmit signature. Two scala Verify B AR ECC: (H A + Safe to assume ever find No securit if BH(R) then BH Speed advantage:

• utweigh

16

• nent

is signature of M

)RS

(mod p) ; : : : ; p − 2}. re except S = (R)) mod p − 1. negligible. very fast. seems to be to any attack relies on choosing exponent.

17

Prime-order subgroup Choose B to have order q for standard prime divisor q of p − 1. e.g. take 3000-bit p, 256-bit q. Again verify BH(M) ≡ AH(R)RS. ECC: H(M)B = H(R)A + SR. Signer: same except now S = r−1(H(M) − aH(R)) mod q. Simpler security analysis. Speed advantage: Smaller S (when q is smaller than p − 1). Less time to transmit signature. Two scalars Verify BH(R)−1H(M ARH(R)−1S. ECC: (H(R)−1H(M A + (H(R)− Safe to assume that ever find H(R) divisible No security loss: if BH(R)−1H(M) = then BH(M) = AH( Speed advantage:

• utweighing cost of

16

signature of M (mod p) 2}. = p − 1. be attack

• sing

17

Prime-order subgroup Choose B to have order q for standard prime divisor q of p − 1. e.g. take 3000-bit p, 256-bit q. Again verify BH(M) ≡ AH(R)RS. ECC: H(M)B = H(R)A + SR. Signer: same except now S = r−1(H(M) − aH(R)) mod q. Simpler security analysis. Speed advantage: Smaller S (when q is smaller than p − 1). Less time to transmit signature. Two scalars Verify BH(R)−1H(M) = ARH(R)−1S. ECC: (H(R)−1H(M))B = A + (H(R)−1S)R. Safe to assume that nobody ever find H(R) divisible by q No security loss: if BH(R)−1H(M) = ARH(R)−1 then BH(M) = AH(R)RS. Speed advantage: fewer scala

• utweighing cost of H(R)−1

17

Prime-order subgroup Choose B to have order q for standard prime divisor q of p − 1. e.g. take 3000-bit p, 256-bit q. Again verify BH(M) ≡ AH(R)RS. ECC: H(M)B = H(R)A + SR. Signer: same except now S = r−1(H(M) − aH(R)) mod q. Simpler security analysis. Speed advantage: Smaller S (when q is smaller than p − 1). Less time to transmit signature.

18

Two scalars Verify BH(R)−1H(M) = ARH(R)−1S. ECC: (H(R)−1H(M))B = A + (H(R)−1S)R. Safe to assume that nobody will ever find H(R) divisible by q. No security loss: if BH(R)−1H(M) = ARH(R)−1S then BH(M) = AH(R)RS. Speed advantage: fewer scalars,

• utweighing cost of H(R)−1.

17

Prime-order subgroup

• se B to have order q for

rd prime divisor q of p − 1. take 3000-bit p, 256-bit q. verify BH(M) ≡ AH(R)RS. H(M)B = H(R)A + SR. Signer: same except now

1(H(M) − aH(R)) mod q.

Simpler security analysis. advantage: Smaller S q is smaller than p − 1). time to transmit signature.

18

Two scalars Verify BH(R)−1H(M) = ARH(R)−1S. ECC: (H(R)−1H(M))B = A + (H(R)−1S)R. Safe to assume that nobody will ever find H(R) divisible by q. No security loss: if BH(R)−1H(M) = ARH(R)−1S then BH(M) = AH(R)RS. Speed advantage: fewer scalars,

• utweighing cost of H(R)−1.

Precomputing Notation: Send (R; signature: signer instead Verify B ECC: (H Signer computes r−1(H(R

17

subgroup have order q for divisor q of p − 1. 3000-bit p, 256-bit q.

M) ≡ AH(R)RS.

H(R)A + SR. except now − aH(R)) mod q. analysis. advantage: Smaller S smaller than p − 1). transmit signature.

18

Two scalars Verify BH(R)−1H(M) = ARH(R)−1S. ECC: (H(R)−1H(M))B = A + (H(R)−1S)R. Safe to assume that nobody will ever find H(R) divisible by q. No security loss: if BH(R)−1H(M) = ARH(R)−1S then BH(M) = AH(R)RS. Speed advantage: fewer scalars,

• utweighing cost of H(R)−1.

Precomputing quotient Notation: S = H(R Send (R; S) instead signature: i.e., S computed signer instead of verifier. Verify BH(R)−1H(M ECC: (H(R)−1H(M Signer computes S r−1(H(R)−1H(M)

17

for

• f p − 1.

256-bit q.

R)RS.

SR. mod q. S − 1). signature.

18

Two scalars Verify BH(R)−1H(M) = ARH(R)−1S. ECC: (H(R)−1H(M))B = A + (H(R)−1S)R. Safe to assume that nobody will ever find H(R) divisible by q. No security loss: if BH(R)−1H(M) = ARH(R)−1S then BH(M) = AH(R)RS. Speed advantage: fewer scalars,

• utweighing cost of H(R)−1.

Precomputing quotient Notation: S = H(R)−1S. Send (R; S) instead of (R; S signature: i.e., S computed signer instead of verifier. Verify BH(R)−1H(M) = ARS. ECC: (H(R)−1H(M))B = A Signer computes S = r−1(H(R)−1H(M) − a) mod

18

Two scalars Verify BH(R)−1H(M) = ARH(R)−1S. ECC: (H(R)−1H(M))B = A + (H(R)−1S)R. Safe to assume that nobody will ever find H(R) divisible by q. No security loss: if BH(R)−1H(M) = ARH(R)−1S then BH(M) = AH(R)RS. Speed advantage: fewer scalars,

• utweighing cost of H(R)−1.

19

Precomputing quotient Notation: S = H(R)−1S. Send (R; S) instead of (R; S) as signature: i.e., S computed by signer instead of verifier. Verify BH(R)−1H(M) = ARS. ECC: (H(R)−1H(M))B = A+SR. Signer computes S = r−1(H(R)−1H(M) − a) mod q.

18

Two scalars Verify BH(R)−1H(M) = ARH(R)−1S. ECC: (H(R)−1H(M))B = A + (H(R)−1S)R. Safe to assume that nobody will ever find H(R) divisible by q. No security loss: if BH(R)−1H(M) = ARH(R)−1S then BH(M) = AH(R)RS. Speed advantage: fewer scalars,

• utweighing cost of H(R)−1.

19

Precomputing quotient Notation: S = H(R)−1S. Send (R; S) instead of (R; S) as signature: i.e., S computed by signer instead of verifier. Verify BH(R)−1H(M) = ARS. ECC: (H(R)−1H(M))B = A+SR. Signer computes S = r−1(H(R)−1H(M) − a) mod q. From now on: Rename S as S.

18

scalars BH(R)−1H(M) = ARH(R)−1S. (H(R)−1H(M))B = A + (H(R)−1S)R. to assume that nobody will find H(R) divisible by q. urity loss:

)−1H(M) = ARH(R)−1S H(M) = AH(R)RS.

advantage: fewer scalars, ighing cost of H(R)−1.

19

Precomputing quotient Notation: S = H(R)−1S. Send (R; S) instead of (R; S) as signature: i.e., S computed by signer instead of verifier. Verify BH(R)−1H(M) = ARS. ECC: (H(R)−1H(M))B = A+SR. Signer computes S = r−1(H(R)−1H(M) − a) mod q. From now on: Rename S as S. Merge hashes: BH(R;M) ECC: H( Speed advantage: is faster Security attacker innocent with H(M Using H( signs M same signature Using H(

18

(M) = S.

(M))B = )−1S)R. that nobody will divisible by q. = ARH(R)−1S

H(R)RS.

advantage: fewer scalars, cost of H(R)−1.

19

Precomputing quotient Notation: S = H(R)−1S. Send (R; S) instead of (R; S) as signature: i.e., S computed by signer instead of verifier. Verify BH(R)−1H(M) = ARS. ECC: (H(R)−1H(M))B = A+SR. Signer computes S = r−1(H(R)−1H(M) − a) mod q. From now on: Rename S as S. Merge hashes: collision BH(R;M) = ARS. ECC: H(R; M)B = Speed advantage: is faster than H(R Security advantage: attacker somehow innocent M and dangerous with H(M) = H(M Using H(R)−1H(M signs M then attack same signature for Using H(R; M): no

18

dy will q.

−1S

scalars,

1.

19

Precomputing quotient Notation: S = H(R)−1S. Send (R; S) instead of (R; S) as signature: i.e., S computed by signer instead of verifier. Verify BH(R)−1H(M) = ARS. ECC: (H(R)−1H(M))B = A+SR. Signer computes S = r−1(H(R)−1H(M) − a) mod q. From now on: Rename S as S. Merge hashes: collision resilience BH(R;M) = ARS. ECC: H(R; M)B = A + SR. Speed advantage: H(R; M) is faster than H(R)−1H(M). Security advantage: Imagine attacker somehow finding innocent M and dangerous M with H(M) = H(M′). Using H(R)−1H(M): if signer signs M then attacker reuses same signature for M′. Using H(R; M): no problem.

19

Precomputing quotient Notation: S = H(R)−1S. Send (R; S) instead of (R; S) as signature: i.e., S computed by signer instead of verifier. Verify BH(R)−1H(M) = ARS. ECC: (H(R)−1H(M))B = A+SR. Signer computes S = r−1(H(R)−1H(M) − a) mod q. From now on: Rename S as S.

20

Merge hashes: collision resilience BH(R;M) = ARS. ECC: H(R; M)B = A + SR. Speed advantage: H(R; M) is faster than H(R)−1H(M). Security advantage: Imagine attacker somehow finding innocent M and dangerous M′ with H(M) = H(M′). Using H(R)−1H(M): if signer signs M then attacker reuses same signature for M′. Using H(R; M): no problem.

19

Precomputing quotient Notation: S = H(R)−1S. R; S) instead of (R; S) as signature: i.e., S computed by instead of verifier. BH(R)−1H(M) = ARS. (H(R)−1H(M))B = A+SR. computes S = (R)−1H(M) − a) mod q. now on: Rename S as S.

20

Merge hashes: collision resilience BH(R;M) = ARS. ECC: H(R; M)B = A + SR. Speed advantage: H(R; M) is faster than H(R)−1H(M). Security advantage: Imagine attacker somehow finding innocent M and dangerous M′ with H(M) = H(M′). Using H(R)−1H(M): if signer signs M then attacker reuses same signature for M′. Using H(R; M): no problem. Eliminate BS = RA ECC: SB Signer in S = r−1 Signer in S = r + Speed advantage: Skip all inve Security slightly simpler. 2000 Pointcheval–Stern.

19

quotient (R)−1S. instead of (R; S) as computed by verifier.

(M) = ARS.

(M))B = A+SR. S = ) − a) mod q. Rename S as S.

20

Merge hashes: collision resilience BH(R;M) = ARS. ECC: H(R; M)B = A + SR. Speed advantage: H(R; M) is faster than H(R)−1H(M). Security advantage: Imagine attacker somehow finding innocent M and dangerous M′ with H(M) = H(M′). Using H(R)−1H(M): if signer signs M then attacker reuses same signature for M′. Using H(R; M): no problem. Eliminate divisions BS = RAH(R;M). ECC: SB = R + H Signer in previous S = r−1(H(R; M) Signer in this system: S = r + H(R; M)a Speed advantage: Skip all inversions. Security analysis is slightly simpler. See, 2000 Pointcheval–Stern.

19

; S) as computed by

S.

A+SR. mod q. as S.

20

Merge hashes: collision resilience BH(R;M) = ARS. ECC: H(R; M)B = A + SR. Speed advantage: H(R; M) is faster than H(R)−1H(M). Security advantage: Imagine attacker somehow finding innocent M and dangerous M′ with H(M) = H(M′). Using H(R)−1H(M): if signer signs M then attacker reuses same signature for M′. Using H(R; M): no problem. Eliminate divisions BS = RAH(R;M). ECC: SB = R + H(R; M)A. Signer in previous system: S = r−1(H(R; M) − a) mod Signer in this system: S = r + H(R; M)a mod q. Speed advantage: Skip all inversions. Security analysis is similar, slightly simpler. See, e.g., 2000 Pointcheval–Stern.

20

Merge hashes: collision resilience BH(R;M) = ARS. ECC: H(R; M)B = A + SR. Speed advantage: H(R; M) is faster than H(R)−1H(M). Security advantage: Imagine attacker somehow finding innocent M and dangerous M′ with H(M) = H(M′). Using H(R)−1H(M): if signer signs M then attacker reuses same signature for M′. Using H(R; M): no problem.

21

Eliminate divisions BS = RAH(R;M). ECC: SB = R + H(R; M)A. Signer in previous system: S = r−1(H(R; M) − a) mod q. Signer in this system: S = r + H(R; M)a mod q. Speed advantage: Skip all inversions. Security analysis is similar, slightly simpler. See, e.g., 2000 Pointcheval–Stern.

20

hashes: collision resilience

) = ARS.

H(R; M)B = A + SR. advantage: H(R; M) faster than H(R)−1H(M). Security advantage: Imagine er somehow finding cent M and dangerous M′ (M) = H(M′). H(R)−1H(M): if signer then attacker reuses signature for M′. H(R; M): no problem.

21

Eliminate divisions BS = RAH(R;M). ECC: SB = R + H(R; M)A. Signer in previous system: S = r−1(H(R; M) − a) mod q. Signer in this system: S = r + H(R; M)a mod q. Speed advantage: Skip all inversions. Security analysis is similar, slightly simpler. See, e.g., 2000 Pointcheval–Stern. Signature Schnorr (H(R; M Given (h recovers checks h ECC: R Speed advantage when H( No securit anyone can

20

collision resilience . = A + SR. advantage: H(R; M) (R)−1H(M). ntage: Imagine w finding dangerous M′ (M′). (M): if signer attacker reuses for M′. no problem.

21

Eliminate divisions BS = RAH(R;M). ECC: SB = R + H(R; M)A. Signer in previous system: S = r−1(H(R; M) − a) mod q. Signer in this system: S = r + H(R; M)a mod q. Speed advantage: Skip all inversions. Security analysis is similar, slightly simpler. See, e.g., 2000 Pointcheval–Stern. Signature compression Schnorr signature (H(R; M); S) instead Given (h; S): verifier recovers R = BS=A checks h = H(R; M ECC: R = SB − h Speed advantage sending when H(R; M) is sho No security impact: anyone can compress

20

resilience R. ) ). Imagine dangerous M′ signer reuses roblem.

21

Eliminate divisions BS = RAH(R;M). ECC: SB = R + H(R; M)A. Signer in previous system: S = r−1(H(R; M) − a) mod q. Signer in this system: S = r + H(R; M)a mod q. Speed advantage: Skip all inversions. Security analysis is similar, slightly simpler. See, e.g., 2000 Pointcheval–Stern. Signature compression Schnorr signature is (H(R; M); S) instead of (R; Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than No security impact: anyone can compress sigs.

21

Eliminate divisions BS = RAH(R;M). ECC: SB = R + H(R; M)A. Signer in previous system: S = r−1(H(R; M) − a) mod q. Signer in this system: S = r + H(R; M)a mod q. Speed advantage: Skip all inversions. Security analysis is similar, slightly simpler. See, e.g., 2000 Pointcheval–Stern.

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs.

21

Eliminate divisions RAH(R;M). SB = R + H(R; M)A. in previous system:

1(H(R; M) − a) mod q.

in this system: + H(R; M)a mod q. advantage: all inversions. Security analysis is similar, slightly simpler. See, e.g.,

• intcheval–Stern.

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs. Half-size Schnorr e.g., 128 Advantage:

21

divisions . H(R; M)A. revious system: ) − a) mod q. system: )a mod q. advantage: s. is similar, See, e.g.,

• intcheval–Stern.

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs. Half-size H output Schnorr chooses half-size e.g., 128 bits instead Advantage: smaller

21

A. mod q. . r,

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs. Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 Advantage: smaller (H(R; M

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs.

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S).

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs.

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!”

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs.

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!” Not an obvious problem: Recall that Schnorr’s system is collision-resilient.

22

Signature compression Schnorr signature is (H(R; M); S) instead of (R; S). Given (h; S): verifier recovers R = BS=Ah, checks h = H(R; M). ECC: R = SB − hA. Speed advantage sending sigs when H(R; M) is shorter than R. No security impact: anyone can compress sigs.

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!” Not an obvious problem: Recall that Schnorr’s system is collision-resilient. More serious objection: multi-target preimage attacks.

22

Signature compression rr signature is M); S) instead of (R; S). (h; S): verifier recovers R = BS=Ah, h = H(R; M). R = SB − hA. advantage sending sigs H(R; M) is shorter than R. urity impact:

• ne can compress sigs.

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!” Not an obvious problem: Recall that Schnorr’s system is collision-resilient. More serious objection: multi-target preimage attacks. DSA and DSA is ElGamal

• prime-o
• A−1 instead
• two scala

Much wo

• does not
• does not
• is not
• requires
• requires

(or three

22

ession signature is instead of (R; S). verifier =Ah, ; M). hA. advantage sending sigs is shorter than R. impact: compress sigs.

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!” Not an obvious problem: Recall that Schnorr’s system is collision-resilient. More serious objection: multi-target preimage attacks. DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A
• two scalars.

Much worse than Schno

• does not hash R
• does not merge hashes;
• is not collision-resilient;
• requires inversion
• requires inversion

(or three exponents).

22

; S). sigs than R.

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!” Not an obvious problem: Recall that Schnorr’s system is collision-resilient. More serious objection: multi-target preimage attacks. DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A;
• two scalars.

Much worse than Schnorr: DSA

• does not hash R;
• does not merge hashes;
• is not collision-resilient;
• requires inversion for signer;
• requires inversion for verifier

(or three exponents).

23

Half-size H output Schnorr chooses half-size H: e.g., 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!” Not an obvious problem: Recall that Schnorr’s system is collision-resilient. More serious objection: multi-target preimage attacks.

24

DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A;
• two scalars.

Much worse than Schnorr: DSA

• does not hash R;
• does not merge hashes;
• is not collision-resilient;
• requires inversion for signer;
• requires inversion for verifier

(or three exponents).

23

Half-size H output rr chooses half-size H: 128 bits instead of 256 bits. Advantage: smaller (H(R; M); S). Objection: “128-bit hash functions allow collisions!”

• bvious problem:

that Schnorr’s system collision-resilient. serious objection: multi-target preimage attacks.

24

DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A;
• two scalars.

Much worse than Schnorr: DSA

• does not hash R;
• does not merge hashes;
• is not collision-resilient;
• requires inversion for signer;
• requires inversion for verifier

(or three exponents). EdDSA EdDSA is

• complete
• no signature
• double-size
• A as extra
• deterministic

23

• utput

half-size H: instead of 256 bits. smaller (H(R; M); S). “128-bit hash collisions!” problem: Schnorr’s system collision-resilient.

• bjection:

reimage attacks.

24

DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A;
• two scalars.

Much worse than Schnorr: DSA

• does not hash R;
• does not merge hashes;
• is not collision-resilient;
• requires inversion for signer;
• requires inversion for verifier

(or three exponents). EdDSA EdDSA is Schnorr

• complete twisted
• no signature comp
• double-size H output;
• A as extra H input;
• deterministic R.

23

H: 256 bits. ; M); S). system attacks.

24

DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A;
• two scalars.

Much worse than Schnorr: DSA

• does not hash R;
• does not merge hashes;
• is not collision-resilient;
• requires inversion for signer;
• requires inversion for verifier

(or three exponents). EdDSA EdDSA is Schnorr with

• complete twisted Edwards
• no signature compression;
• double-size H output;
• A as extra H input;
• deterministic R.

24

DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A;
• two scalars.

Much worse than Schnorr: DSA

• does not hash R;
• does not merge hashes;
• is not collision-resilient;
• requires inversion for signer;
• requires inversion for verifier

(or three exponents).

25

EdDSA EdDSA is Schnorr with

• complete twisted Edwards curve;
• no signature compression;
• double-size H output;
• A as extra H input;
• deterministic R.

24

DSA and ECDSA DSA is ElGamal plus

• prime-order subgroups;
• A−1 instead of A;
• two scalars.

Much worse than Schnorr: DSA

• does not hash R;
• does not merge hashes;
• is not collision-resilient;
• requires inversion for signer;
• requires inversion for verifier

(or three exponents).

25

EdDSA EdDSA is Schnorr with

• complete twisted Edwards curve;
• no signature compression;
• double-size H output;
• A as extra H input;
• deterministic R.

Extra H input: H(R; A; M). Speed impact: negligible. Alleviates concerns that several public keys could be attacked simultaneously.

24

and ECDSA is ElGamal plus rime-order subgroups; instead of A; scalars. worse than Schnorr: DSA not hash R; not merge hashes; not collision-resilient; requires inversion for signer; requires inversion for verifier three exponents).

25

EdDSA EdDSA is Schnorr with

• complete twisted Edwards curve;
• no signature compression;
• double-size H output;
• A as extra H input;
• deterministic R.

Extra H input: H(R; A; M). Speed impact: negligible. Alleviates concerns that several public keys could be attacked simultaneously. Why no

• 1. ECC signatures

even without 64 bytes using high-securit

• 2. Securit

needs tho

• 3. Double-size

concerns

• 4. Avoiding

allows anoth batch signature

24

A plus subgroups;

• f A;

than Schnorr: DSA R; ge hashes; collision-resilient; inversion for signer; inversion for verifier

• nents).

25

EdDSA EdDSA is Schnorr with

• complete twisted Edwards curve;
• no signature compression;
• double-size H output;
• A as extra H input;
• deterministic R.

Extra H input: H(R; A; M). Speed impact: negligible. Alleviates concerns that several public keys could be attacked simultaneously. Why no signature

• 1. ECC signatures

even without comp 64 bytes for signature using high-security

• 2. Security of shorter

needs thorough analysis.

• 3. Double-size H alleviates

concerns regarding

• 4. Avoiding compr

allows another speedup: batch signature verification.

24

DSA signer; verifier

25

EdDSA EdDSA is Schnorr with

• complete twisted Edwards curve;
• no signature compression;
• double-size H output;
• A as extra H input;
• deterministic R.

Extra H input: H(R; A; M). Speed impact: negligible. Alleviates concerns that several public keys could be attacked simultaneously. Why no signature compression:

• 1. ECC signatures are short

even without compression. 64 bytes for signature using high-security curve.

• 2. Security of shorter H

needs thorough analysis.

• 3. Double-size H alleviates

concerns regarding H securit

• 4. Avoiding compression

allows another speedup: batch signature verification.

25

EdDSA EdDSA is Schnorr with

• complete twisted Edwards curve;
• no signature compression;
• double-size H output;
• A as extra H input;
• deterministic R.

Extra H input: H(R; A; M). Speed impact: negligible. Alleviates concerns that several public keys could be attacked simultaneously.

26

Why no signature compression:

• 1. ECC signatures are short

even without compression. 64 bytes for signature using high-security curve.

• 2. Security of shorter H

needs thorough analysis.

• 3. Double-size H alleviates

concerns regarding H security.

• 4. Avoiding compression

allows another speedup: batch signature verification.