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.

CCS/TM4C129ENCPDT: RSA, AES encryption algorithm and File compression ( to create a .zip file) in TM4C129ENCPDT microcontroller

Part Number: TM4C129ENCPDT

Tool/software: Code Composer Studio

Dear all,

I'm currently working on a project that needs RSA and AES for data encryption and after encrypting I have to zip the entire file and should send to customer's HTTP server.

Could anyone tell me suggestions regarding these implementations. I'm new to data Encryption and compression algorithms.

Thanks and Regards,

Renil Raju

 

  • There are several examples using AES encryption for the EK-TM4C129EXL Launchpad in the TivaWare library. If you install TI-RTOS for TM4C into CCS, there are examples for HTTP client. I don't have an RSA example, but there is third party support with it from WolfSSL.

  • Dear Bob,

    Thanks for your quick reply.

    I found some board examples in CCS for AES encryption and I 'll try those codes.

    For RSA, I will try with WolfSSL as per your suggestion.

    But could you please tell me how to compress a file(probably text file with < 5K size) to a common ".ZIP" format in our micro controller or is it possible to compress a file within an Embedded system ?.

    I have tried this with third party application libraries like "miniz", "zlib" etc; but none of them are supported by the embedded systems and also very difficult to implement in our work-space. And also their compression format is different from ".zip" format which is not acceptable in our case.


    I am waiting for your valuable suggestions and Thank you so much again.

    Regards,
    Renil Raju
  • Renil Raju said:
    ...how to compress a file(probably text file with < 5K size)

    You may note that (some) file "overhead" (size addition) occurs during the file compression process.     Thus - w/so small a file (<5K) it is doubtful that you'll, "Get much bang for your <5K, compression bucks."   (likely defeating your, "la raison d'etre.")

    Firm/I attempted such 5-6 years past - operating upon Graphic Images.    (which were NOT JPG)     IIRC much RAM is needed - which often exceeds that of Flash based, embedded MCUs.   As you likely know - systems "starved for resources" (i.e. those here) often must attack such requirements in "fractions and/or chunks" - significantly (slowing AND complicating) the process...

  • Dear cb1,

    Thank you very much for your immediate reply.

    I googled a lot for file compression methods/libraries for an embedded system and as you said I found that it would be very difficult to implement this in our working environment. Even though, the file compression to ".zip" file is a customer requirement so we need to try our best to satisfy their needs.

    Then let me try with the AES and RSA encryption first and I will surely let you know the result.


    Thanks and regards,
    Renil Raju
  • Thank you as well, my friend. You've got an involved & time-consuming project - may I suggest that you attempt to "excise" the ".zip" portion from your embedded design.   (possibly - and sometimes - that .zip file may be handled via the PC - as an integral, secondary operation.   (which always proves: faster, easier)

    When too many items invade a work contract you invite in great risk - do you not?   You may wish to "agree & accept" only those items which are "sure things" - which insures your payment for the bulk of the work you'll perform. Too often the "final mile" (last steps) prove "killer" (that's the ".zip" requirement here - I believe) and inability to deliver that (small) piece must not place your (entire) work-effort's reward in jeopardy...

  • Dear cb1,

    Thanks again for your immediate responses.

    "You may wish to "agree & accept" only those items which are "sure things" - which insures your payment for the bulk of the work you'll perform. "

    - As I said in the first post, I am new to "file encryprion/compression algorithms" and I didn't know about these much of complications behind these goals. That's why I asked in e2e community to get expert suggestions. :)

     Once again Thank you so much cb1 for your valuable reply.

    Thanks and Regards,

    Renil Raju

  • Hi,

    See this link :

    http://bcl.comli.eu

    for a compression library which could be used for embedded systems. I did not tested it. Also search fo zlib, but this one needs bigger  resources.

  • Hi Petrei,

    Thanks for your suggestion. Let me check with "Basic Compression Library" and I'll let you know if any improvement is there.

    Thanks and Regards,
    Renil Raju
  • Hi Petrei,

    Those are all useful resources - yet each/every one extracts (some) size penalty - and "compressing" this user's file (<5K in size) may not prove too useful...   (i.e. the result of the compression is likely to be nominal)

  • Hi cb1,

    Yes, I agree with you, but some clients are so inflexible, I met myself such clients/persons with decisional power (and small brain) and a compromise solution was to accept, despite technical reasons. Maybe you also had some unpleasant experiences of this kind...

  • Indeed Petrei - so much so that it caused me to attend (another) professional school - to learn tactics/methods to reduce (ideally eliminate) contractual obligations which may hold (any) payment hostage - until the entire (laundry list) of deliverables have been presented.

    Usually - but not always - large firms draw such contracts - likely "knowing" that certain elements will over-challenge - enabling payment reduction, extended delay (or worse yet) payment avoidance.

    A "twin" to "asking for the overly complex" is the tendency for these clients to, "Request Changes/Additions to the original project" - without offering (any) increase in payment for the "extra work" forced upon the development team.     (and as you KNOW - such additions will (always) be described as "EASY" by these clients - yet reality teaches that to be (rarely) true!)     A good contract should note that (any) change or addition sought by the buyer is almost certain to, "Add cost & charges AND delay the deliverable!"    (and - may not be accepted by the developer/seller...   a good defense (i.e. well prepared one) proves the best offense, here.)

    Caveat Venditor... (let the Seller (developer here) beware)

  • Dear Petrei and cb1,

    I totally agree with you what you have stated in these previous posts. And I really appreciate for sharing your personal experience here.

    And I am software developer with only less than 2 years experience and trying to learn new things that I am not familiar with. So by doing this project at-least I will get to know, what "should do" and "what should not do" in future from my own experience :).

    I'm sorry guys if at any point, this Post is wasting your valuable time but I believe at-least this may be helpful for the people who are seeking similar requirements.

    @Petrei,

    I tried the "basic compression library" with input of 721 Bytes(later I will try with large amount of data) and following are the results;

    ==============>> Compression Test: 1. RLE Compression !

    Testing test.txt...
    Compression: 463/721 bytes (64.21%) - OK! // output file size/input file size bytes and percentage

    ==============>> Compression Test: 2. Huffman_Compress !

    (Not working, I will check the code implementation)

    ==============>> Compression Test: 3. Rice_Compress 8bit !

    Testing test.txt...
    Compression: 677/721 bytes (93.89%) - OK!

    ==============>> Compression Test: 4. Rice_Compress 16bit!

    Testing test.txt...
    Compression: 700/721 bytes (97.08%) - OK!

    ==============>> Compression Test: 5. Rice_Compress 32bit !

    Testing test.txt...
    Compression: 710/721 bytes (98.47%) - OK!

    ==============>> Compression Test: 6. Rice_Compress 8bit !

    Testing test.txt...
    Compression: 722/721 bytes (100.13%) - OK!
    malloc in freed !!

    ==============>> Compression Test: 7. Rice_Compress 16bit !

    Testing test.txt...
    Compression: 721/721 bytes (100.00%) - OK!

    ==============>> Compression Test: 8. Rice_Compress 32bit !

    Testing test.txt...
    Compression: 721/721 bytes (100.00%) - OK!

    ==============>> Compression Test: 9. LZ_Compress !

    Testing test.txt...
    Compression: 379/721 bytes (52.56%) - OK!
    malloc in freed !!

    ==============>> Compression Test: 10. LZ_CompressFast !

    Testing test.txt...{module#59}: line 307: out of memory: handle=0x2003a6a8, size=265036
    00028.143 mmBulkAlloc(): could not allocate memory.
    00028.143 out of memory: handle=0x0, size=537028716

    (This method requires "mmBulkAlloc( sizeof(unsigned int) * (65536+insize)" currently i don't(wont) have this much of Heap memory so I'm ignoring this)


    And could you please tell me (if you know) what "ISO-7168 Zip format" stands for ? I googled it a lot but could n't get any clue.


    Thanks and Regards,
    Renil Raju
  • Hi,

    Good for you  to succed with compression tests. Use whatever you need, not all methods .

    Also, ISO-7168 Zip format is a standard related to Air quality data exchange format, is described here:

    https://www.iso.org/obp/ui/#iso:std:iso:7168:-1:ed-1:v1:en

    .

    Please note this document is not free, must be baught by your company if really needed to be used.