• State Resolved
  • Locked Locked
  • Replies 21 replies
  • Subscribers 101 subscribers
  • Views 2049 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Which stream ciphers are supported in am335x cryptographic accelerator ?

Rakshith rao
Intellectual 390 points

I want to use cryptographic accelerator in aes cfb mode [or any other stream cipher]. According to this guy cfb is supported in am335x. I used EVP_aec_256_cfb cipher in both command line and C program.  In command line it executed in default software implementation. In C program the context initialization could not be done. So is cfb mode or any other stream cipher supported in am335x crypto accelerator? Or any problem in cryptodev.ko module?

Thank you. 

  • 0
    Intellectual 390 points
    Sorry. The link I have posted in my question is e2e.ti.com/.../658334
  • 0 in reply to Biser Gatchev-XID
    Intellectual 390 points
    That link doesn't have anything about aes stream ciphers.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 390 points
    What about processors.wiki.ti.com/.../Cryptography_Users_Guide link? It confirms only AES implementation. In hardware accelerator it works only for AES in CBC mode. No other cipher mode or algorithms work. Can you please clarify regarding this.

    Thank you.
  • 0 in reply to Rakshith rao
    TI__Guru**** 393215 points

    I have asked the factory team to look at this thread.

  • 0 in reply to Biser Gatchev-XID
    Intellectual 390 points
    HI,
    I am looking for the information regarding the hardware implementation of CFB/OFB mode of AES in am335x. Could you please clarify this?

    Thank you.
  • 0 in reply to Rakshith rao
    Mastermind 8020 points

    The stream cipher modes supported by the AES crypto accelerator hardware are CTR (16, 32, 64, or 128-bit counter), F8, and CFB-128. Other supported modes are CBC and XTS encryption, GCM and CCM encryption-with-authentication, F9 authentication, and various flavours of CBC-MAC authentication. OFB and CFB-1 are not supported by the hardware.  You can find more information about the module in this thread.

    The linux driver is currently much more limited, it only supports ECB, CBC, and CTR.

  • 0 in reply to Matthijs van Duin
    Intellectual 390 points
    Thank you so much. I am using linux-3.12 . So for stream cipher I can just concentrate on CTR mode. Regarding openssl configuration I think CTR mode is supported in openssl versions starting from 1.0.2. But the latest ocf patch is for openssl-0.9.8r. Also the latest patch for kernel is for version 3.2.1. How to deal with it? Could you please help me out?
  • 0 in reply to Rakshith rao
    Mastermind 8020 points

    I'm not sure I understand why you specifically need a stream cipher yet apparently do not specifically care which, except that it needs to be a mode of AES? Can you give a bit more context what you're trying to achieve?

    Also, beware that, as I observed in my most recent post in the thread I linked to, the AES accelerator may not actually give superior performance compared to a software implementation of AES (let alone compared to a high performance stream cipher such as salsa20). The overhead of the kernel and openssl will make this situation even worse. (I still intend to do some benchmarks on the AES module accessed directly from userspace instead of using the kernel driver, but it's not at the top of my priorities right now.)

  • 0 in reply to Matthijs van Duin
    Intellectual 390 points
    Actually I am working in an embedded project where the data of the SD card has to be encrypted. The problem with CBC mode is it decrypts the data in a fixed size of block which I don't want because of some device architectural issue.
    Thats why I preferred stream cipher where I can get variable size of data chunk.

    Regarding performance I can conclude only after its implementation and testing in the device.
  • 0 in reply to Rakshith rao
    Mastermind 8020 points

    Why not use dm-crypt, which implements XTS ?

  • 0 in reply to Rakshith rao
    Mastermind 8020 points

    CBC mode can btw also be used when the data is not an integral multiple of the block size (using ciphertext stealing).

    Both CBC and stream cipher modes such as CTR are however unsuitable for disk encryption (unless it is encrypted once and then read-only), since the IV is required to be unique for each invocation under the same key (for CBC it is moreover required to be unpredictable). Violating this rule breaks their security.

    XTS is currently the best option for disk encryption as far as I know.

  • 0 in reply to Matthijs van Duin
    Mastermind 8020 points

    Matthijs van Duin said:
    Why not use dm-crypt, which implements XTS ?

    Ah, I just noticed this comment in the linux xts implementation: "sector sizes which are not a multiple of 16 bytes are, however currently unsupported"

    (In other words, it just implements XEX rather than XTS)

    Adding ciphertext stealing to support such odd block sizes should not be very hard though (but I guess it is sufficiently uncommon that nobody has cared so far).

  • 0 in reply to Matthijs van Duin
    Intellectual 390 points

    Thank you so much. I am looking into it.

  • 0 in reply to Matthijs van Duin
    Intellectual 390 points
    Hi, For the time being I am working on CTR mode in hardware accelerator. When I looked into the driver code there was a condition check if the data block is a multiple of AES_BLOCK_SIZE. Even when I decrypt also if the data block is in multiple of AES_BLOCK_SIZE it works fine and for other values it decrypts till the multiples of block size. After that it gives junk values. So what might be the issue?
  • 0 in reply to Rakshith rao
    Mastermind 8020 points

    The accelerator only works in 16-byte blocks. In case of CTR mode, the last input block can be padded with arbitrary data and the output truncated. To be honest, this is a detail that the API ought to have dealt with, it's a bit lazy that they didn't.

    I want to reemphasize that, based on the limited information you provided w.r.t. your application, the use of CTR mode most likely will result in broken security (depending a bit on the implementation details and the attack scenario(s) you're trying to defend against).

    In general, constructing a cryptographic system from low-level primitives is a subtle art and one needs to be very aware of the requirements imposed by a primitive. Using a cryptographic primitive incorrectly, or in a way it was not designed for, can weaken its security or even completely obliterate it. A particularly notorious example is the Sony Playstation 3 crack, where Sony's failure to use the ECDSA signature scheme correctly allowed their firmware signing key, "usually stored in a vault at the company's HQ", to be recovered by attackers using simple algebra.

    I do not know what constraints you are facing that are leading you to design a custom solution, but I strongly urge you to consider this strategy as a last resort only.

  • 0 in reply to Matthijs van Duin
    Intellectual 390 points
    Thank you. As I explained about the device, it stores files and encrypts it. It receives data chunks each time which are not multiples of 16 (because the packet is 512 bytes and after removing the header the data packet becomes 509). So each time I have to encrypt 509 bytes. Padding is fine only at the end of the file.

    One thing that astonished me is that the accelerator encrypts 509(or some other random number) bytes and when I decrypt that buffer immediately after encryption I was able to get the original plaintext ! But when I write the encrypted bytes to file and try to decrypt it, the condition happens as I told in the previous comment.

    By the way in omap aes hardware accelerator driver I commented out the condition checking for if the block size is multiple of 16 :-P
    And one more thing is that the key and iv remain the same as the device stores the file and decrypts whenever required.
  • 0 in reply to Rakshith rao
    Mastermind 8020 points

    What exactly are your access patterns here? Are the 509-byte blocks written sequentially to a file? Are they also read in 509-byte blocks? (sequentially or random-access?) Are files modified after having been written once?

    Rakshith rao said:
    By the way in omap aes hardware accelerator driver I commented out the condition checking for if the block size is multiple of 16 :-P

    Depending on how the driver is written exactly that may be a very bad idea. (I'll see if I have a moment later to inspect the driver and comment on this)

  • 0 in reply to Matthijs van Duin
    Intellectual 390 points
    The files are read/written sequentially. They are not going to be modified once encrypted. So during reading just read 509 bytes(or whatever remaining in the file) and decrypt it.
  • 0 in reply to Matthijs van Duin
    Intellectual 390 points
    Ok. After some modifications in application now I am able to use CBC mode. I could trace the control flow till driver/omap-aes.c. But for "cat /proc/interrupts" I got the entry for sham@53100000 bot not for aes@53500000. What was the reason for this. How to make sure that the hardware accelerator for AES is being used?