English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General > Coders. Releases

 
 
Thread Tools
Old 02 March 2015, 19:09   #41
modrobert
old bearded fool

modrobert's Avatar
 
Join Date: Jan 2010
Location: Bangkok
Age: 50
Posts: 414
Thanks for the info.

My release allocates roughly 15kb (+3kb stack) memory when encrypting a 2.5mb zip file with the included aes256.c routines, just checked with 'scout'.

I suggest you post a new thread with your version, or it will get lost in the pages of this release.
modrobert is offline  
AdSense AdSense  
Old 04 March 2015, 14:38   #42
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,964
Quote:
Originally Posted by modrobert View Post
I suggest you post a new thread with your version, or it will get lost in the pages of this release.
No problem. I actually almost posted my previous version. Didn't do it because it wasn't good enough.

Now we'll get competing utilities
Thorham is offline  
Old 09 March 2015, 20:08   #43
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,964
After doing some research, I think that one of the best modes for encryption is CTR HMAC SHA256.

CTR mode is simple. It requires a counter that's unique for each key. The counter doesn't have to be random, and can be a time stamp. It also only needs the AES encryption algorithm because it works as a stream cipher by encrypting the counter and XORing the cipher output with the plain text.

HMAC SHA256 allows the detection of messing with the cipher text.
Thorham is offline  
Old 17 March 2015, 12:33   #44
modrobert
old bearded fool

modrobert's Avatar
 
Join Date: Jan 2010
Location: Bangkok
Age: 50
Posts: 414
Yes, I reimplemented CTR by accident it seems, while thinking it was a new idea by my own design. As long as it is unique for each block, which it is in my code.

http://en.wikipedia.org/wiki/Block_c...nter_.28CTR.29
modrobert is offline  
Old 24 March 2015, 15:23   #45
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,964
Quote:
Originally Posted by modrobert View Post
Yes, I reimplemented CTR by accident it seems, while thinking it was a new idea by my own design. As long as it is unique for each block, which it is in my code.

http://en.wikipedia.org/wiki/Block_c...nter_.28CTR.29
What you're doing isn't CTR, because you're storing the counter for each block in the blocks themselves and there's no IV/nonce. CTR mode takes an IV or nonce that is unique for each plain text that uses the same key and combines this with a block counter. This data is then encrypted, and the result is XORed over the plain text to get the cipher text.

The IV/nonce and counter combination can be constructed like this:

[ 12 byte IV/nonce ][ 4 byte block counter ]

The IV or nonce does not have to be random for CTR mode to work properly, they only have to be unique for each key. They also don't have to be secret. The counter can simply start at zero.

To construct the IV/nonce, you can generate a time stamp on AOS by combining two sources.

First: DateStamp (dos.library)

This returns:

Code:
struct DateStamp {
   LONG	 ds_Days;	      /* Number of days since Jan. 1, 1978 */
   LONG	 ds_Minute;	      /* Number of minutes past midnight */
   LONG	 ds_Tick;	      /* Number of ticks past minute */
}; /* DateStamp */
Second: GetSysTime (timer.device)

This returns:

Code:
struct timeval
   {
        ULONG tv_secs;   /* seconds */
        ULONG tv_micro;  /* microseconds */
   };
From the DateStamp structure you want all bits of ds_Days, 16 lower bits of ds_Minute and 16 lower bits of ds_Tick. From the timeval structure you want all bits of tv_micro. Combine these into the 12 byte IV/nonce.

This has the advantage of allowing you to generate a unique IV/nonce every microsecond. It has the disadvantage of requiring the user to make sure their system's clock is set to the correct time and date. The hardware register method can still be used as an added option to counter the disadvantage.

After that you still need an authentication method to detect whether or not an attacker has changed the cipher text. The HMAC construction is good for this and works properly with CTR mode when implemented correctly.

The basic idea behind HMAC (do look it up when you want to implement it, of course, because there are some details) is to do two hashing operations:

First message to hash: [ HMAC key 1 XOR ipad ][ IV / nonce ][ cipher text ]
Second message to hash: [ HMAC key 2 XOR opad ][ hash generated by first hash operation ]

The second hash is the authentication tag.

The two HMAC keys can be derived from a master key. You have to do this for the AES key anyway, and there's no problem with generating three keys from one password instead of one, when done properly.

Very amusing topic, this encryption thing

Last edited by Thorham; 24 March 2015 at 15:38.
Thorham is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
windows tool to convert ipf to wwp / normal adf file jotd Coders. General 12 08 May 2014 10:02
universe amiga 500 256 colors ! ? turrican3 Retrogaming General Discussion 14 09 April 2014 22:35
How to change default tool for file types AndyFC project.ClassicWB 2 13 February 2013 11:18
Classic OS System.zip file problems FOL project.ClassicWB 2 21 July 2007 18:48
Pal Amiga is 256 redblade Retrogaming General Discussion 9 05 April 2006 17:30

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 01:06.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.20592 seconds with 15 queries