Amiga Format Issue 12, Paul Overaa

[redblade]

Hi

There is a tutorial in AF issue 12 by Paul Overaa, a introduction to encryption on the amiga.

Can some one please scan this please.

Thanks.

[Codetapper]

I don't have that magazine but what exactly do you want the encryption information for? If it's just for your own project you can just do a basic XOR over the data and that would be enough to protect it from the majority of people.

[girv]

Yeah what's it for? Different types of encryption are more suitable for different purposes so what you want will depend very much on what you are trying to achieve...

[alexh]

I remember that Adobe 'Ebooks encryption used to be XOR the data with the string "ENCRYPTED". Some russian got into terrible trouble when he announced this :)

[redblade]

what's it for?!?! it's a secret project :P.

Nah, I just wanna read it, yeah i've read that shit about XORing the data and stuff, but still wouldn't mind reading the article.

[girv]

what's it for?!?! it's a secret project :P.
A secret project or a project involving secrets ? ;)

Nah, I just wanna read it, yeah i've read that shit about XORing the data and stuff, but still wouldn't mind reading the article.
Actually I wouldn't mind either if anyone can oblige...

[redblade]

Okay

that's 2 people on the waiting list :)

[Steve]

I have the article but I don't have a scanner. However I've taken the time to copy the BASIC code at the end of the article to text so you can have a read of something. Enjoy! :)


File Encryption - A simple Example to give you the general idea.
---------------------------------------------------------------

NOTE 1: This example does not contain any error checking!
NOTE 2: I wouldn't recommend such a simple function for serious use but
as an "easily understood" starting point it does serve a useful
purpose. Once you understand the overall ideas you can experiment
with more sophisticated functions.
NOTE 3: You can add all the bells and whistles you want, but the
basic idea is simply this...

OPEN SOURCE AND DESTINATION
READ AND PROCESS EACH CHARACTER IN THE SOURCE FILE WRITING EACH MODIFIED CHARACTER TO THE DESTINATION FILE
CLOSE SOURCE AND DESTINATION FILES

REM First step is to get the filenames and a "key" value.

INPUT "Source file?", SOURCE$
INPUT "Destination file?", DESTINATION$
INPUT "Encryption file?", Key

REM Open the file and initialise a position counter

OPEN "i",£1,SOURCE$: OPEN "o",£2,DESTINATION$: Position = 0

REM Now loop reading the source file byte by byte carrying out the
REM encryption function on each character and writing the encrypted
REM character to the destination file.

WHILE (NOT EOF(1))
CHARACTER$ = INPUT$(1,£1):
X = ASC (CHARACTER$) : Position = 1
X = X XOR ((Key + Position) MOD 256) : PRINT£2,CHR$(X);:
WEND

REM Close the file and quit

CLOSE 1: CLOSE 2: END


Here is the magic line in the code which performs the encryption process:

X = X XOR ((Key + Position) MOD 256) : PRINT£2,CHR$(X);:

[OddbOd]

Off Topic:
I remember that Adobe 'Ebooks encryption used to be XOR the data with the string "ENCRYPTED". Some russian got into terrible trouble when he announced this :) That was Dmitry Sklyarov who was arrested under the provisions of the DMCA after the release DEF CON 9 conference, the case drew a lot of attention as it was the first time somebody had ever been arrested and charged under the Act. The funny part is that the XOR encryption is not even the weakest security handler that was used in eBooks (BTW the security system for eBooks is modular and Adobe did not write the handlers themselves) New Paradigm Resource Group used ROT13 "encryption" with a fixed key that was stored as plaintext in the security plugin and had the audacity to charge US$3000 per document.

On Topic:
In the listing above, aren't those pound signs (£) supposed to be pound signs (#) ?

Another thing, can anyone figure out what the Position variable is supposed to be for? It gets assigned one constant, then another, then....???

[Galaxy]

Scanned and in the Zone - enjoy!

[redblade]

Thanks Steve and Galaxy :).

Galaxy, Is there a ISO you follow for scanning Amiga Tutorials?

I want to buy a scanner, so I can scan in my Amiga magazine Tutorials, because they are really useful.

[Galaxy]

What do you mean by ISO?

There's nothing particularly special about the scans I made - they were scanned as greyscale and then converted to pdf.

[redblade]

any particular DPI ?

[Imran]

300dpi is the standard for good readability and should suit most purposes, if you want to blow it up to a larger than life size then scan at a higher resolution.

[Galaxy]

I usually use 300dpi/black and white for this sort of scanning.

In this case I used 200dpi greyscale.

[girv]

Thanks for the scan :)

Its a sound enough article on basic stream mode encryption. To his credit the author does advise that the algorithms are easily cracked and not to be used for anything you actually want to remain secret :)

Theres one common mistake though: XOR encrypting data more than once with different keys is no more secure than encrypting it once, as the XORs effectively combine all the keys into one.

[redblade]

girv: do you use Amitcp:libs/usergroup.library/crypt() ???

I seem to have problem with that function.

I dissassembled bin/login, and copied the salt(setting).

so when I coded my own routine and tried comparing my crypt() result with the one from bin/login I got a different pw :(.

[girv]

I've never used that function, sorry.

Are you sure youre using the exact same algorithm in your own code as the library does?

[redblade]

I'm actually calling the libraries crypt() function.

but it's interesting because it says in the docs that the salt begins with a underscore '_' let the salt that I get from my code is the first 9 letters of the encrypted password :/

[girv]

Can you post the code you're using? Also where did you get the library and its autodocs?

[redblade]

the library is in the AmiTCP: distrubution on aminet.

AmiTCP 4, :).

the autodocs are available in the AmiTCP-4-sdk which is also available on aminet.

i'll up the source to the zone in zipped -adf format.

it's 'login.s' which has been modified to try to get the 'salt'.

[girv]

I haven't tried it but I can't see anything obviously wrong with the hacked login.s.

Does the exe assembled from your login.s actually work?

Does _LVOOpen maybe corrupt the a3 register?

Can you try stepping through the original login program using a debugger and get the salt that way?

How you could be saving the encrypted password before it is actually created by _LVOcrypt is a mystery!

Why are you trying to get the salt value? Its most likely going to change per password anyway!

[redblade]

I can't use a debugger, because Monam seems to crash, and well it doesn't have support for usergroup.library, so _LVO crypt would look like jsr -$hexvalueofcrypt(a6).

Which would be harder to track down.

I just like playing around with source, poking some code here and there, to see how stuff works.

I wanted to make my login routine to a tool, that used DES crypt(), so the program would continue running, which is why I wanted the salt value

[girv]

You've already tracked the call down in the disassembly so how hard could it be to find it again in the binary? login.s line 568: "JSR -174(A6) ;_LVOcrypt" (-174 = -$ae) ;) Also ISTR IRA can be configured to include binary offsets in the disassembly to make it even easier to find. Ah well :rolleyes

I wanted to make my login routine to a tool, that used DES crypt(), so the program would continue running, which is why I wanted the salt value
Sorry, I know I'm a bit slow but I don't understand what you mean here :confused

[redblade]

I was just replying to your question of you asking me, why I wanted to know the salt value.

[girv]

I was just replying to your question of you asking me, why I wanted to know the salt value.

...and I didn't understand the explanation!

[redblade]

girv: Why are you trying to get the salt value? Its most likely going to change per password anyway!

Red^blade: I just like playing around with source, poking some code here and there, to see how stuff works.

I wanted to make my login routine to a tool, that used DES crypt(), so the program would continue running, which is why I wanted the salt value.

Because you need the initial salt value to encrypt the password typed in, to make sure it is the encrypted password?