In what cases might PRESENT be implemented as encryption-only?

up vote
1
down vote

favorite

In the paper, under section 4.1 Goals and environment of use we read:

In applications that demand the most efficient use of space, the block cipher will often only be implemented as encryption-only.

I presume this is NOT the same as one-way encryption (perhaps I should say hash?) as used for passwords.

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

Furthermore, the quote above continues with ...

In this way it can be used in challenge-response authentication protocols and, with some careful management, it could be used for both encryption and decryption ...

This just added to my confusion.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

asked 2 hours ago

Red Book 1

424414

in CTR mode only encryption
â€“Â kelalaka
2 hours ago

add a commentÂ |Â

up vote
1
down vote

favorite

In the paper, under section 4.1 Goals and environment of use we read:

In applications that demand the most efficient use of space, the block cipher will often only be implemented as encryption-only.

I presume this is NOT the same as one-way encryption (perhaps I should say hash?) as used for passwords.

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

Furthermore, the quote above continues with ...

In this way it can be used in challenge-response authentication protocols and, with some careful management, it could be used for both encryption and decryption ...

This just added to my confusion.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

asked 2 hours ago

Red Book 1

424414

in CTR mode only encryption
â€“Â kelalaka
2 hours ago

add a commentÂ |Â

up vote
1
down vote

favorite

In the paper, under section 4.1 Goals and environment of use we read:

In applications that demand the most efficient use of space, the block cipher will often only be implemented as encryption-only.

I presume this is NOT the same as one-way encryption (perhaps I should say hash?) as used for passwords.

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

Furthermore, the quote above continues with ...

In this way it can be used in challenge-response authentication protocols and, with some careful management, it could be used for both encryption and decryption ...

This just added to my confusion.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

asked 2 hours ago

Red Book 1

424414

In the paper, under section 4.1 Goals and environment of use we read:

In applications that demand the most efficient use of space, the block cipher will often only be implemented as encryption-only.

I presume this is NOT the same as one-way encryption (perhaps I should say hash?) as used for passwords.

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

Furthermore, the quote above continues with ...

In this way it can be used in challenge-response authentication protocols and, with some careful management, it could be used for both encryption and decryption ...

This just added to my confusion.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

symmetric authenticated-encryption lightweight present

asked 2 hours ago

Red Book 1

424414

asked 2 hours ago

Red Book 1

424414

asked 2 hours ago

Red Book 1

424414

asked 2 hours ago

Red Book 1

424414

asked 2 hours ago

Red Book 1

424414

in CTR mode only encryption
â€“Â kelalaka
2 hours ago

add a commentÂ |Â

in CTR mode only encryption
â€“Â kelalaka
2 hours ago

in CTR mode only encryption
â€“Â kelalaka
2 hours ago

add a commentÂ |Â

3 Answers
3

active

oldest

votes

up vote
1
down vote

accepted

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

For example, the CTR mode uses only Encryption, and CFB, OFB.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

The correct sentence is

In this way it can be used within challenge-response authentication protocols and, with some careful state management.

All about the hardware implementation of PRESENT.

This paragraph from the article;

Encryption and decryption with present have roughly the same physical requirements. Opting to support both encryption and decryption will result in a lightweight block cipher implementation that is still smaller than an encryption-only AES. Opting to implement an encryption only present will give an ultra-lightweight solution. The encryption subkeys can be computed on-the-fly.

So they compare their encryption and decryption supported hardware implementation to encryption-only AES claiming that PRESENT has smaller requirements.

edited 2 hours ago

answered 2 hours ago

kelalaka

1,704319

add a commentÂ |Â

up vote
1
down vote

Ciphers that are targeted for light-weight applications often have some common, but one-off, use cases. I have an IC with and ADC that is passively powered via RFID, and then sends encrypted data via SIMON. There's no commands required, so it is strictly one-way. I illuminate the IC electrically, and then it sends me a sample from the sensor. PRESENT is also used for applications like this, but I've never personally implemented it.

answered 1 hour ago

b degnan

1,2941521

add a commentÂ |Â

up vote
0
down vote

A bona fide use case for encryption only is inside a true random number generator (TRNG). If you have something small like:-

trng

it's common to whiten the raw entropy signal using a cryptographic primitive. PRESENT could be used in some form of CFB mode, although there are examples of vanilla ECB mode being used. The designers of these simple key type TRNGs often fail to appreciate the nuances of modes of operation and their consequences. So you'd effectively encrypt the output signal with no requirement to ever decrypt. The key would probably be fixed, rather than intermittently cycled around.

PRESENT has small resource requirements so would be a valid solution.

This image is only a representative example of the form factor.

answered 46 mins ago

Paul Uszak

6,26811332

add a commentÂ |Â

Your Answer

StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\$","\$"]]);
);
);
, "mathjax-editing");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f63409%2fin-what-cases-might-present-be-implemented-as-encryption-only%23new-answer', 'question_page');

);

Post as a guest

Name

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

up vote
1
down vote

accepted

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

For example, the CTR mode uses only Encryption, and CFB, OFB.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

The correct sentence is

In this way it can be used within challenge-response authentication protocols and, with some careful state management.

All about the hardware implementation of PRESENT.

This paragraph from the article;

Encryption and decryption with present have roughly the same physical requirements. Opting to support both encryption and decryption will result in a lightweight block cipher implementation that is still smaller than an encryption-only AES. Opting to implement an encryption only present will give an ultra-lightweight solution. The encryption subkeys can be computed on-the-fly.

So they compare their encryption and decryption supported hardware implementation to encryption-only AES claiming that PRESENT has smaller requirements.

edited 2 hours ago

answered 2 hours ago

kelalaka

1,704319

add a commentÂ |Â

up vote
1
down vote

accepted

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

For example, the CTR mode uses only Encryption, and CFB, OFB.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

The correct sentence is

In this way it can be used within challenge-response authentication protocols and, with some careful state management.

All about the hardware implementation of PRESENT.

This paragraph from the article;

Encryption and decryption with present have roughly the same physical requirements. Opting to support both encryption and decryption will result in a lightweight block cipher implementation that is still smaller than an encryption-only AES. Opting to implement an encryption only present will give an ultra-lightweight solution. The encryption subkeys can be computed on-the-fly.

So they compare their encryption and decryption supported hardware implementation to encryption-only AES claiming that PRESENT has smaller requirements.

edited 2 hours ago

answered 2 hours ago

kelalaka

1,704319

add a commentÂ |Â

up vote
1
down vote

accepted

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

For example, the CTR mode uses only Encryption, and CFB, OFB.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

The correct sentence is

In this way it can be used within challenge-response authentication protocols and, with some careful state management.

All about the hardware implementation of PRESENT.

This paragraph from the article;

Encryption and decryption with present have roughly the same physical requirements. Opting to support both encryption and decryption will result in a lightweight block cipher implementation that is still smaller than an encryption-only AES. Opting to implement an encryption only present will give an ultra-lightweight solution. The encryption subkeys can be computed on-the-fly.

So they compare their encryption and decryption supported hardware implementation to encryption-only AES claiming that PRESENT has smaller requirements.

edited 2 hours ago

answered 2 hours ago

kelalaka

1,704319

So in what cases might we need only encryption but not decryption? It seems strange we would encrypt something that does not need decrypting at some point.

For example, the CTR mode uses only Encryption, and CFB, OFB.

It seems PRESENT can decrypt a ciphertext by running it in reverse. So why the need for some careful management for PRESENT to be used for both encryption and decryption?

The correct sentence is

In this way it can be used within challenge-response authentication protocols and, with some careful state management.

All about the hardware implementation of PRESENT.

This paragraph from the article;

Encryption and decryption with present have roughly the same physical requirements. Opting to support both encryption and decryption will result in a lightweight block cipher implementation that is still smaller than an encryption-only AES. Opting to implement an encryption only present will give an ultra-lightweight solution. The encryption subkeys can be computed on-the-fly.

So they compare their encryption and decryption supported hardware implementation to encryption-only AES claiming that PRESENT has smaller requirements.

edited 2 hours ago

answered 2 hours ago

kelalaka

1,704319

edited 2 hours ago

answered 2 hours ago

kelalaka

1,704319

answered 2 hours ago

kelalaka

1,704319

answered 2 hours ago

kelalaka

1,704319

add a commentÂ |Â

up vote
1
down vote

answered 1 hour ago

b degnan

1,2941521

add a commentÂ |Â

up vote
1
down vote

answered 1 hour ago

b degnan

1,2941521

add a commentÂ |Â

up vote
1
down vote

answered 1 hour ago

b degnan

1,2941521

answered 1 hour ago

b degnan

1,2941521

answered 1 hour ago

b degnan

1,2941521

answered 1 hour ago

b degnan

1,2941521

answered 1 hour ago

b degnan

1,2941521

add a commentÂ |Â

up vote
0
down vote

A bona fide use case for encryption only is inside a true random number generator (TRNG). If you have something small like:-

trng

PRESENT has small resource requirements so would be a valid solution.

This image is only a representative example of the form factor.

answered 46 mins ago

Paul Uszak

6,26811332

add a commentÂ |Â

up vote
0
down vote

A bona fide use case for encryption only is inside a true random number generator (TRNG). If you have something small like:-

trng

PRESENT has small resource requirements so would be a valid solution.

This image is only a representative example of the form factor.

answered 46 mins ago

Paul Uszak

6,26811332

add a commentÂ |Â

up vote
0
down vote

A bona fide use case for encryption only is inside a true random number generator (TRNG). If you have something small like:-

trng

PRESENT has small resource requirements so would be a valid solution.

This image is only a representative example of the form factor.

answered 46 mins ago

Paul Uszak

6,26811332

A bona fide use case for encryption only is inside a true random number generator (TRNG). If you have something small like:-

trng

PRESENT has small resource requirements so would be a valid solution.

This image is only a representative example of the form factor.

answered 46 mins ago

Paul Uszak

6,26811332

answered 46 mins ago

Paul Uszak

6,26811332

answered 46 mins ago

Paul Uszak

6,26811332

answered 46 mins ago

Paul Uszak

6,26811332

add a commentÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky