4
$\begingroup$

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.

  1. 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.

  1. 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?
Improve this question
$\endgroup$
1
  • $\begingroup$ Note that a block cipher is a PRP: you can use block decrypt instead of block encrypt if that performs better (but I presume that the creators of PRESENT already chose the best performing direction to be encryption). $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 24, 2018 at 14:59

3 Answers 3

Reset to default
4
$\begingroup$
  1. 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.

  1. 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.

Improve this answer
$\endgroup$
2
$\begingroup$

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.

Improve this answer
$\endgroup$
2
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.