Need aes cipher function allow input [6]byte-CodePudding

background

There is a need for a cipher can encode and decode [6]byte.

std function aes.NewCipher not allowed this, because it's definition of blocksize is 16 bytes.

Can't simply padding 6 bytes to 16 bytes. I need print [6]byte as barcode and use barcode for remote and decode in remote.

code

this can run in go playground

// You can edit this code!
// Click here and start typing.
package main

import (
    "bytes"
    "crypto/aes"
    "fmt"
)

func main() {
    plain := []byte("4512wqdeqwbuobouihodqwbuo")[:6]
    encrypt := make([]byte, 6)
    plain2 := make([]byte, 6)

    cipher, err := aes.NewCipher([]byte("4512wqdeqwbuobouihodqwbuo")[:16])
    if err != nil {
        fmt.Println(err)
        return
    }
    cipher.Encrypt(encrypt, plain)
    cipher.Decrypt(plain2, encrypt)

    if bytes.Compare(plain, plain2) != 0 {
        fmt.Println("can't be", plain, plain2, encrypt)
    }
}

error: crypto/aes: input not full block

question

Is there a third party function can match my require?
Or std functions can achieve this in some way?
It's naive to implement this specified function by bit-shift and xor, is there more?
For new, I have implement this function with bit-shift.

CodePudding user response：

There is a need for a cipher can encode and decode [6]byte.

There's a difference between encoding (display data in a different format) and encryption (providing confidentiality). Ciphers are used for encryption. Further I assume you want to encrypt data for the confidentiality reasons.

Is there a third party function can match my require? Or std functions can achieve this in some way?

In theory - there are ways where padding is not required. Please see different modes of operation. There are modes (CTR, OFB, ..) where the padding is not needed effectively turning the block cipher into a stream cipher.

There are even dedicated stream ciphers, such as Salsa or ChaCha.

So - now you could encrypt 6 bytes of the plaintext into 6 bytes of the ciphertext.

There are two issues when you require sending the same amount of encrypted data as the plaintext:

to keep data confidential while reusing the same key for multiple encryptions, each of the ciphers need some initial state (IV), which can be random or a counter. It is imperative that the same Key and IV are not reused. So under normal circumstances this counter or state is sent along the encrypted data. Using some static vector allow to break the encryption (partly or completely). That's the reason people in the comment cannot give you simple answer. There is no proper encryption without additional data transmitted.
Another issue is with data integrity. Without transmitting additional bytes if the ciphertext is modified in transmission (intentionally or not), receiving party has no means to detect the data has been modified. I assume with 6 bytes there is no integrity control anyway, so maybe this is not your concern.

It's naive to implement this specified function by bit-shift and xor, is there more?

Yes, you can encrypt data using a static IV vector, but this is not properly encrypted as we understand it, so the knowing multiple messages or initial information, the data could be completely decrypted.

Using something simple like XOR, matrix operations, ... could as well reveal the key itself.