Hi,
I have encrypted a file using Winzip with AES-128 encryption. The password i applied is "12345678".
The SALT value stored in the encrypted zip archive is 8 bytes i.e. [0xa4 0x94 0x72 0xce 0x84 0x16 0x84 0x05].

Now i tried using the following:

    fcrypt_ctx ctx;
int mode = 1;
unsigned char pwd[8] = {'1','2','3','4','5','6','7','8'};
    unsigned char salt[8] = {0xa4,0x94,0x72,0xce,0x84,0x16,0x84,0x05};
unsigned char pwd_ver[2] = { 0 };

       fcrypt_init(mode,pwd,8,salt,pwd_ver,&ctx);
       printf("Password Verifier : 0x%02x 0x%02x\n",pwd_ver[0],pwd_ver[1]);

The output i.e. "Password verification value" comes out to be [0XEA,0X43] which is not the same Password verification value i extracted from the ZIP archive [0X97,0XB1] using the same SALT and PASSWORD.
The fileenc header and source are attached herewith.
filenc.zip

yasm-1.3.0-win32.exe -Xvc -f win32 -o aes_x86_v1.obj aes_x86_v1.asm
aes_x86_v1.asm(560) : warning: section flags ignored on section redeclaration

Where can I find aes_encrypt function? I am using aes for file encryption, specifically the aesxam file.

The Password Verification value comes out to be correct once i replaced the previous SHA1 with the new one as we discussed in the previous thread i.e. https://github.com/BrianGladman/aes/issues/38
, but the Authentication Code for an encrypted data comes out to be different.

I have made an archive (using WinZip) with an encryption method AES-128. The actual data size is 5 bytes and the compressed+encrypted data size is of 7 bytes length i.e.
Actual data ASCII bytes = { t e x t 1 }
Encrypted data = {0xd4, 0xbb, 0xbf, 0xdb, 0xf6, 0x16, 0x50}

The Salt value is
{0xa4, 0x94, 0x72, 0xce, 0x84, 0x16, 0x84, 0x05}

I have encrypted the archive with a password "12345678"

After using your implementation, the Password Verification value comes out to be correct i.e. {0x97 0xB1} but the Authentication Code generated from your implementation doesn't match the Authentication Code value of Zip archive.

Here is how i am generating the Authentication Code

fcrypt_init(mode,Password,8,salt,pwd_ver,&ctx);
fcrypt_decrypt(Encrypted_Data_bytes, Encrypted_Data_Size, &ctx);
fcrypt_end(mac,&ctx);
I assume the mac contains the Authentication code.

Authentication code generated from your implementation
{0xe6, 0x52, 0xb1, 0x91, 0xa1, 0xdc, 0x65, 0xa7, 0x31, 0x81}

Authentication Code extracted from the Zip archive is
{0xc2, 0x36, 0xec, 0x48, 0xb8, 0xb2, 0x04, 0xcc, 0xb7, 0xf4}

Here is the zip archive
NewZip_aes128_12345678.zip

I hope GCC isn't messing with your implementation.

Hi Brian,
The aes_CBC_encrypt and aes_CBC_decrypt routines in aes_ni.c take in a "key" and a "number_of_rounds" rather than the ctx. Can these routines be changed to take in the ctx, like the CBC routines in aes_modes.c?
I'm passing "ctx->ks" for the key and "ctx->inf.b[0] >> 4" for the number_of_rounds. Is that correct?
If so, the aes_CBC_encrypt routine passes my verification tests, however the aes_CBC_decrypt routine does not. I think the problem is the index needs to decrement rather than increment, at aes_ni.c, lines 495-496, as follows -
data = _mm_xor_si128(last_in, ((__m128i*)key)[number_of_rounds]);
for(j = number_of_rounds -1; j >= 1; j--)
with this change the aes_CBC_decrypt routine did pass my verification tests.
Please advise. Thanks.

Building with gcc version 7.5.0 or 9.3.0 and the -Wall flag, I see several warnings of the form:

aeskey.c: In function ‘aes_decrypt_key192’:
aeskey.c:407:34: warning: operation on ‘ss[4]’ may be undefined [-Wsequence-point]
     cx->ks[v(48,(4))] = ff(ss[4] = word_in(key, 4));
aesopt.h:363:25: note: in definition of macro ‘to_byte’
 #  define to_byte(x)  ((x) & 0xff)
                         ^
aesopt.h:737:12: note: in expansion of macro ‘bval’
   ^ tab[2][bval(vf(x,2,c),rf(2,c))] \
            ^~~~
aesopt.h:737:17: note: in expansion of macro ‘vf1’
   ^ tab[2][bval(vf(x,2,c),rf(2,c))] \
                 ^~
aesopt.h:759:29: note: in expansion of macro ‘four_tables’
 #  define inv_mcol(x)       four_tables(x,t_use(i,m),vf1,rf1,0)
                             ^~~~~~~~~~~
aeskey.c:242:17: note: in expansion of macro ‘inv_mcol’
 #define ff(x)   inv_mcol(x)
                 ^~~~~~~~
aeskey.c:407:25: note: in expansion of macro ‘ff’
     cx->ks[v(48,(4))] = ff(ss[4] = word_in(key, 4));
                         ^~

four_tables() uses its first argument four times, so using it with a side-effecting expression may be the source of the complaint.

Hey Brian,

I think that I can not change the block size.

aes/aes_modes.c
aes_ecb_decrypt
aes_cbc_encrypt

int nb = len >> 4;
I think this is wrong.

int nb = len / AES_BLOCK_SIZE;
I think this is correct.

There are other places that are hard-coded in 16.

Thanks heaps,

Tomoaki

AES_ENCRYPT and AES_DECRYPT macros are redefined when including both https://github.com/BrianGladman/aes and https://github.com/openssl/openssl.

Cocoapods recommandation:

Can I workaround ‘Duplicate Symbol’ errors with static libraries?
[...]
in general, the vendor should really prefix any dependencies it includes, so you don’t need to deal with it. When this happens, please contact the vendor and ask them to fix it on their side.

So my request is: can you prefix AES_ENCRYPT and AES_DECRYPT macros please?

related: openssl/openssl#4441

This is from code inspection, so apologies if I've read something wrong.

Per the comments, IS_ENCRYPTION_CTX() and IS_DECRYPTION_CTX() are intended to be useful to some category of callers. aeskey.c sets the corresponding bit in cx->inf.b[2] where it calls MARK_AS_ENCRYPTION_CTX() and MARK_AS_DECRYPTION_CTX().

If USE_VIA_ACE_IF_PRESENT is defined, the public API for key schedules lives in aes_ni.c. The aeskey.c functions are bypassed completely unless has_aes_ni() returns false. The aes_ni.c functions don't appear to touch cx->inf.b[2] (they only use ctx->inf.b[0]).

Also, from reading the code I think the caller is responsible for initializing cx->inf.b[2] to zero (perhaps by zeroing the whole context), as the macros used by aeskey.c modify that byte rather than initialize it. I don't see any documentation of that.

hi, i am working on aes code in VS2015 provided here, but its showing this error:
Severity Code Description Project File Line Source
Error LNK1104 cannot open file 'D:\FYP\AES-master\lib\Win32\Debug\lib_asm_amd64_c.lib'

when I open the folder D:\FYP\AES-master\lib\Win32\Debug, it is empty. where will i find this library lib_asm_amd64_c ? please help ASAP

Похоже, строку 27 можно закомментировать. Понял, когда обнаружил, что эта строка вызывает конфликт в одном UEFI проекте.

Hi

I wanted to know whether your AES code is FIPS tested?
Thanks a lot, seems you did amazing job BTW!

I am working on CipherShed, a fork of TrueCrypt. Our goal is to re-license under an OSI approved license (likely BSD or Apache).

The manual indicates you contributed (maybe they just copied your source) some of the code. I tried to download older copies of your crypto libraries, but could only find the current ones.

Do you have archive of you libraries that you may share?

https://github.com/CJ42/solidity/blob/de7e2dbef570233be341ff11ba1f53c46ea3c9a3/.github/CODEOWNERS

The documentation is not clear for minimal libraries.
For example, I only need AES or RSA but I have to import the complete library set into my project which makes the binary quite heavy.

Any minimal module available or compilation of minimal features for these two available?

I want to c++ code,how can I get that. I have got the aescpp.h ,but I can not use it. My English is not very well ,sorry . Thank you !

On pycrypto and pycryptodome you can get away with base64 on the data and then encrypt. It seems that the data from base64 does not work right after encrypting (trying to decrypt provides invalid bytes)

bytearray(b'eNrtWllv2zgQfg+Q/0Ao6FpCVMFx2qIw4gJBNymCbtoCafuSDQRZpm01kmiQdGL31+/wEEVdPpAgD4s6D5bImW+Gw7lI5wjFZJLks9GST1+/Pzw4QvckmxKaRTxYrA8PHMc5PPhMMnSZpBhdygn0bc3nJEc38XrBA02TZAtCOZphThbcvBJmHhmny7icYety6neajA8PphTErLI0mJAsyJI8gW+kKRYRZdhHf5N4meEcUMRfnEaMoYuc0/VPTE9dMv6FY+4NDw8QfKRW4uEGc4b+jniEYF0IuGmCWVAjmuApCkMQysPQZTid+iiPMhC5zGOSLShmDE9ClvyGocYAxWnEkwcckumUYe6jKRgr5Ingj9IZoQmfZ4Ve4iMEBAIfjaSY2kxDJpA1xmo8TY7N9DWdgb42UqM3SwJK81yjMWsFGvOs9krYN4vucajt78Y0DjH15X6sw5gs8+bOXQMDK3YMcYKuOKYRx4jPKVnO5vCN0eev18o5tdcq1iF4TJQhJWUo3ApNhAswvpxOqzSWBkOUL7MxpohMa44ypJgvaT5U1ChNGEdRPjFGQ8poUkuhlRBW97FiISN0e6dGaibHlMJkX80doSiOYfsKo+th4cMrlOSIRvkMuy3mK0StgakMDmUJ2EbK+Md5kk7sR4jacw7KjZccu84X8EjH80u05mcPtBvwvS1oSc730e+jcWyFvR28aednVUi43/dEGg2dvHtW6PMijGCZXnV/hXNGiwXOJ8oLrOmmAIoz8oDl80bxFkiLcx6PlGcFrblFhQhytXJ+C4JXZoNlvojie0zDLEpyN6Kzh5b4Bz//oenQN0pmIl4vIRXyhOTVKBYAQ3ROZ7JANML2C+FzKHP1kEymKMVaOjpDJ1YILajYKucHi2Z4+G8OZRGvOI1iHub4Eb1+DaqdidwjkqFM4h9gkCw5Orsk6QT0lWOOZVAoeQFeJdwd6EGwpCUQ6iasCswWFYuAAFb1NFBfUk8f9ZIhGfZ8dNtL8hF890DqqHenQfEqxouiEAef5NcFpYQON2iS5OEi4nMQ+IXkejsBtTko0o9StNRTZCOtvCUDTKsGxbTbS4Siwmo9O09VZReAnSBEgYBmDRRL2ypMMnVzwo0U0F+8GvLinQXiNUiY2E9XU3ti2i3mwGKMM7dg9WQBAGajSAkySWhJ53kv61Y4Zdj2KxaIygsqWbqr6cdEWABSSLFgMC8d92BlTBV51VJZYHJUVtKRTQH5JZq4GtV0FKaSPWDKxCaOdBcYqOAPRcvnjntng3ds8G7V80t4X6N4t/27CiqkoLeDsp7q2teJfPVmZ9iTQaGu6W9oN+6uqG/UADQgMlOGcl+fCxU6DY1gbF7QVCVu325RFMQmYjtPlIMBw/je1QpVCbQ3WLTSGSryG/7mAHkAJA6o8GipEAMvJ3Ud9GjwCKUQu4XQbtDNK5LbKk8UbknjVXo0v70129rBlklSdWAQzZq83pyFdiS55uW2saXHuuTWFBo2CTe1He0gO/HUav2dtf1HJp1JTaDAolcscNArzSpylVfJ5mrcOihAlqhl8qZ5xPkwmOBCEbdG4VX55bguBUVG/kWgxyiSn9+uXS1t7gjlBI4acktQX4S3fm+c2zx7tjwdVtq70qWNBlactGdmo6/OyCpW2k2ld+1CVR6RmUVPnYKbB47Vou3WoH17sfZssLGOLqpF1C6XRQmtFtY/vdmTejOcPkt3hjZ0Zy+431qRagtXtIEvqAdUFTBScdHllqMqiJN8SlSxDWRRxBcploTyEMqckl6fDcsjn+HXNKC6GivvJfrljJW17FQ87vVKZ5MT8hpLeBkLxK1Ih9k6M6npRAxYtWDUGnOD47WlPn3zVfBAnIkRi6nm3VOL7axZiaQlSc6TfImrM9Xs0JJ+hRb1/C1arQ6mLR21CTmVP66+1pOG8c6IsRpLs6oZqcLa0nNH5XsHqbZsv81A9YvHFiL7ZrBlut2c9hYVqgbg0kyUR7cXnDbSTOcKoeSvuOUZbJFCdVxxt0Ll7YzW5m17Y9pGEUkFeG9PhncbOIp+ay+ttZqGT7xvkdMR/OZ5J04tVxTwNrwO8bKqdG754M+W/x+3vDVFbdFMHgrMkWCbjLpp0iI3b+F50uJ0upaa4o6M3Z61t5ilUbrF9UU3aasFj0etlm1HMdNwFI9PB4X5o0mK6emg3R4I/YX6q6n+gCM/EnoP7R8clCeyfUgYW2J0MugP2oVWmhb9xHHW3f443l5AAWv+7OGjXQJtN0D564Q67RnX856EWPvlQ2HXz5dPkzDH8T1bZoDtvOq/X4mzfG3zn4Rvfiqx8PtPQix/IVHmsI7UO8B2d8mlwMb9Qh6laVvDUlQu3QImTB4pxAFtuCGsdL8Xp4Rh19tKWDnygcRGLviA+vJmWiSqruj3BFXtWsxOriLAOFllqa1Qs0traXjLmxF5X1GlF+rM5XWbOEo4n79+Qp8+ou8X59fo+vzm5vLqnwv0M+gHp4HTyXhsLk/F9YS8PX672iCohV5cs9bN5qOTGoZdRWXSt21Udy7LyHZ9KhLkeM31jaF1vduT/3PR8/bR/VTo3vcb8kSqvdQfX6nubbsbKgVtJd1H/3ZBW0pme1DtFVA7BVNXIFlHe/nPBKq6TOR12H8NyDRx')

It also seems to avoid the error from this base64 stuff I have to do an while not loop to check if it is / 16 to get an even number and if not append an null byte on the end.

Also it seems that doing this right after zlib also results in zlib error -3

Hi,
Is this open source code NIST or FIPS certified?

Hello, I would love to use this in my project, but how does one get started?

What is the directory structure?
Which files do I need to embed and which ones don't I?

Not sure if it is my code or not but after needing to convert an str object to bytes to satisfy 1 Exception then his one shows up.

class AESCipher:
    def __init__(self, key): 
        self.key = hashlib.sha256(key.encode()).digest()

    def encrypt(self, raw):
        iv = bytearray(os.urandom(16))
        cipher = AES(mode='cbc', key=self.key, iv=iv)
        data = raw.encode('ascii')
        output = cipher.encrypt(data=data)
        return iv + output

    def decrypt(self, enc):
        iv = enc[:16]
        cipher = AES(mode='cbc', key=self.key, iv=iv)
        try:
            return cipher.decrypt(data=enc[16:]).decode('utf-8')
        except UnicodeDecodeError:
            return None

Edit: seems what I had to do was make the bytes object become an bytearray.

An old version of this code was used to implement AES support in Winzip.
The implementations I know are reliant on the particularities of the codebase at the time.

Can you please provide a migration guide how one would switch from that code to the current one?

In particular, how does one get the password verification data with the modern code?

Here's a piece of code I'd like to see converted:

fcrypt_init(mode, password, length_of_password, salt, password_verification, context);
fcrypt_decrypt(buf, bufsize, context);
fcrypt_end(mac, context);

Thank you!

Code is not working with 256 bit key

Hi Brian, I know this is not the appropriate place for this, but I wanted to ask you a question about some of your GSL Visual Studio project files but couldn't find your contact info anywhere.

I was wondering if you or the GSL team have any intention of integrating your build files into the GSL repository, making it easier for people to use GSL on windows?

Again, sorry about the location for this, but I saw no other way of contacting you.

Thanks.

It be nice if I could know how to compile the AES c extension for my python 3.6+ embedded interpreter to elimiate the need to ship with things like pycryptodome that wastes distribution space a ton.

I need to know this so I got more portibility in loading up encrypted python scripts, yes encrypted python script loading is possible with an import hook that I made for within zip files.

However it is a means of well (installing it) which the install function takes in an encrypted key for any encrypted python scripts (*.pye files).

And yes the *.pye format was made by me for users who want to ship secured python code within their applications that might cover things like security means or something (like hiding secured functions used in their code that should remain private and sensitive information).

https://github.com/luuquocviet79/aes.git

Please allow me to refer you to the issue I created in the minizip repository:
zlib-ng/minizip-ng#362

I already tried nmoinvaz's suggestions, tried to change the optimization level, but nothing of that helped. A simple cc fails on aes_ni.c:

[root@d50e2017a6ae minizip-1.2]# cc -c -O aes/aes_ni.c
cc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

Do you have any idea what the problem might be?

Hello, I can get the python CFB and OFB tests working with the aes_ni implementation, but somehow it fails with the C and amd64.asm implementation.

I have a Dockerfile reproducing this (my CPU is 12th Gen Intel(R) Core(TM) i9-12900H, but I've reproduced this on a few other machines, and with gcc 9.3)

FROM gcc:13.2.0
RUN apt-get --allow-unauthenticated update && apt-get --allow-unauthenticated install -y python3-dev git yasm python3-psutil
RUN git clone https://github.com/BrianGladman/aes
WORKDIR /aes/python_binding
RUN git checkout 646c5d4

# This uses the aes_ni implementation
RUN gcc -fPIC -shared -I.. -O2 -Wall -g -I/usr/include/python3.11 -D__PROFILE_AES__ -march=skylake ../aes_ni.c ../aes_modes.c ../aescrypt.c ../aeskey.c ../aestab.c ./aesmodule.c -o aes.cpython-311-x86_64-linux-gnu.so
RUN python3 demo.py  # works
RUN python3 test_aes.py  # works

# This uses the amd64 asm implementation
RUN yasm -f elf64 -a x86 -D__GNUC__ ../aes_amd64.asm -o asm.o
RUN gcc -fPIC -shared -I.. -O2 -Wall -g -I/usr/include/python3.11 -D__PROFILE_AES__ -march=skylake -U__AES__ -DASM_AMD64_C ./asm.o ../aes_modes.c ../aescrypt.c ../aeskey.c ../aestab.c ./aesmodule.c -o aes.cpython-311-x86_64-linux-gnu.so
RUN python3 demo.py  # works
RUN python3 test_aes.py  # fails

# This uses the C implementation, and doesn't
RUN gcc -fPIC -shared -I.. -O2 -Wall -g -I/usr/include/python3.11 -D__PROFILE_AES__ -march=skylake -U__AES__ ../aes_ni.c ../aes_modes.c ../aescrypt.c ../aeskey.c ../aestab.c ./aesmodule.c -o aes.cpython-311-x86_64-linux-gnu.so
RUN python3 demo.py  # works
RUN python3 test_aes.py  # fails

Am I doing something wrongly?

It appears that hmac.h has problems compiling if SHA2 support is not necessary. There is a compiler error that SHA2_MAX_DIGEST_SIZE is not defined. Adding something like the following should fix it:

#if defined(SHA_224) || defined(SHA_256) || defined(SHA_384) || defined(SHA_512)
#define HMAC_MAX_OUTPUT_SIZE SHA2_MAX_DIGEST_SIZE
#define HMAC_MAX_BLOCK_SIZE SHA2_MAX_BLOCK_SIZE
#else 
#define HMAC_MAX_OUTPUT_SIZE SHA1_DIGEST_SIZE
#define HMAC_MAX_BLOCK_SIZE SHA1_BLOCK_SIZE
#endif

And hmac_ctx should use HMAC_MAX_BLOCK_SIZE instead of SHA2_MAX_BLOCK_SIZE.

Thanks!

Hello Brian,

Why your sources do not have makefile or cmake to build the code? It could be a project with cross-platform build.

Hello, I submitted this at https://github.com/nmoinvaz/minizip where aes code is used and was redirected here. I am building Linux 64 version and getting warnings about macros, but I got quite lost in the definitions and don't know what's the reason behind it:

/aes/aesopt.h:353:25: note: in definition of macro ‘to_byte’
# define to_byte(x) ((x) & 0xff)
^
/aes/aesopt.h:727:12: note: in expansion of macro ‘bval’
^ tab[2][bval(vf(x,2,c),rf(2,c))] \
^~~~
/aes/aesopt.h:727:17: note: in expansion of macro ‘vf1’
^ tab[2][bval(vf(x,2,c),rf(2,c))] \
^~
/aes/aesopt.h:749:29: note: in expansion of macro ‘four_tables’
# define inv_mcol(x) four_tables(x,t_use(i,m),vf1,rf1,0)
^~~~~~~~~~~
/aes/aeskey.c:232:17: note: in expansion of macro ‘inv_mcol’
#define ff(x) inv_mcol(x)
^~~~~~~~
/aes/aeskey.c:491:25: note: in expansion of macro ‘ff’
cx->ks[v(56,(7))] = ff(ss[7] = word_in(key, 7));
^~
/aes/aeskey.c:491:34: warning: operation on ‘ss[7]’ may be undefined [-Wsequence-point]
cx->ks[v(56,(7))] = ff(ss[7] = word_in(key, 7));

Hi Brian, awesome work!

There is any .NET implementation or some bindings for .NET?

Hey Brian,

I have tried to set up your example for aes encryption and decryption.
I got your example working and the encryption works but for some reason it errors out and stops the program from running when I try to decrypt?

Any ideas?

Thanks heaps,

Steph

Dear Brian,

I see that you have (assembly) code for linux and Windows.
Do you also have code for OSX?

How does the performance of your aes code compare to e.g.
this code?

Thanks in advance for your answer

Can only disable Intel AES and VIA ACE to support ARM platform?

Xcode 8.3.3, using compiler default ([-std=gnu99]), is reporting me warnings for aes_via_ace.h:

Function cannot return qualified void type 'volatile void'

Stack Overflow got a specific question regarding volatile void in AES... with a direct link to aes_via_ace.h, and it says we should use __attribute__((noreturn)) void instead.

Yet, this step is only changing the warning to another one:

Function declared 'noreturn' should not return

The same StackOverflow thread is concerned that:

• this code is insane
• Declaring a function as doesn't return when it does return to convince the optimizer to do something specific is asking for trouble.
• Extensive use of this technique is definitely discouraged. First, it depends on customization for each compiler. Second, it depends on those compilers not changing how they handle the 'no return' case. Third, it's potentially confusing to subsequent maintainers.

Finally, a comment reveals:

• In later AES implementations, I haven't seen this sort of 'trick' used at all.

It was unspecified what are those later AES implementations. Could be any of those:

• https://github.com/ARMmbed/mbedtls/tree/development/library
• https://github.com/kokke/tiny-AES128-C
• https://github.com/B-Con/crypto-algorithms
• https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src
• https://github.com/openssl/openssl/tree/master/crypto/aes
• https://github.com/libressl-portable/openbsd/tree/master/src/lib/libcrypto/aes
• https://gitlab.com/gnutls/gnutls/tree/master/lib/nettle/int
• https://github.com/jedisct1/libsodium/tree/master/src/libsodium/crypto_aead/aes256gcm/aesni
• https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Sources_Building_Testing
• https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=tree
• ...

Would it be possible to get inspiration from those to get rid of the volatile void?

I have tried your implementation of RFC2898 (pwd2key.c) in order to verify the derive_key() function. In your implementation you had placed a test case to verify it and i had executed that. Unfortunately it shows that the "key is bad" which shows that there is something wrong in the derive_key() function.
The pwd2key.c file

pwd2key.txt

Here is the structure

strut.txt

main function

main.txt

Output

Hi !
I have used your created modules and it works just fine. I have used it along with some zlib modules as well. Now i am trying to add some cuda-kernels to it but i face a little problem which i am unable to identify the reason behind this.

In order to move gradually, at this point, i haven't embed any kernels. I have just replaced the .c extension to .cu in order to pass it to the nvcc compiler. The building process stuck with these two files (aescrypt.cu and aeskey.cu).
I have searched for these elements 't_fn' 't_fl' `t_rc' in your code but couldn't found it !

Here are the screenshots

Note: I haven't modified the above files, the files are as-it-is.