@Karlos

Quote:

Actually, storing data directly within images is an established technique: Steganography

Interesting read, yes, I could have done something similar. Both methods would destroy the hidden file if the file is edited in a paint program.

With my method, as the paint program would not read in the extra data, when you saved it again, it would be lost. With the Steganography method, if you edit the file and resave using a lossy format like Jpeg, you would most likely loose the data also as lossy formats don't save every pixel, and their exact colours

_________________
Glass coffins, a success?
Remains to be seen.

Sorry for goine over the top before 8(.. Id like to ask something relatively simple.

If you take the password, phrase, then generate the perfect hash, then use that as teh seed in a PRBS generator, and the sequence is then the key to encruypting the file, where the sequence key is the same size as the file,would this be similar to unbrekable One Time Pads.. and also similar to Tumber, as used by Tao, if intent, Elate, AA infamy?

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

@Thread

I've released a lite version of the encryption program for you to try out.

With this program, you can decrypt the test image that I posted earlier if you know the password (Hint "I like ********" )

I am planning a commercial version if there is enough interest, so if there is anything you want to see in that version, please let me know

Amicrypt Lite - OS4 Depot Link

_________________
Glass coffins, a success?
Remains to be seen.

I've been doing some more testing, another good place to hide files is within executeables, I just added a picture into c:soundplayer, which continues working correctly, so you could probably hide files within your C: or other system locations, not that I really recommend messing with your system files as you could easily end up with an unusable system if you stuff up something you shouldn't

_________________
Glass coffins, a success?
Remains to be seen.

@AmigaOneProductions

Hiding data into executables is the best way to have those files detected as infected by viruses/trojan (same might be applied to pictures, as you make them invalid).

The "hiding into executables" method was a common method for the latest viruses we saw under AOS 3.x at the end of the 90s, they were called "link viruses".

Fortunately we don't have viruses anymore under AmigaOS4 so neither we do have anti-viruses

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@AmigaOneProductions

Hiding things in files screams virus and could be viewed as dishonest, should we really be going down that route OS4 is clean at the moment lets keep it that way.

@abalaban

Good point, as the hidden file is encrypted, even if you were to hide an executable inside an executable, there is no way it would be detected as such as it would look like gibberish to anything else that was looking at the file. There is also now way that the hidden part could be "executed".

If a virus checker was to find it, it would just see gibberish at the end of the file, but would not be able to recognise what it was.

_________________
Glass coffins, a success?
Remains to be seen.

@AmigaOneProductions

Harry 'Piru' Sintonen showed up on IRC and said he broke it in 20 minutes. He gave this link as proof:

http://sintonen.fi/pics/Hacked.jpg

_________________
Common sense - So rare it's almost like a super power

@Arnie

Quote:

Hiding things in files screams virus and could be viewed as dishonest,

Well to be honest, the program is meant for personal use, there's not a lot of point in giving someone else the encrypted file without the program to decrypt. The files are perfectly safe as I pointed out earlier, the appended bit of the file is encrypted so would look like giberish and no way executable.

_________________
Glass coffins, a success?
Remains to be seen.

@zerohero

Quote:

Harry 'Piru' Sintonen showed up on IRC and said he broke it in 20 minutes. He gave this link as proof:

Well done that man !

OK, looks like a bit of a rethink is needed, that indeed is the hidden picture.

Now was that using the clue I gave as to the password, or a more brute force method (as I think I might have given too much of a clue for the password.

_________________
Glass coffins, a success?
Remains to be seen.

@AmigaOneProductions

No, he didn't use the password at all. He explained what he did on IRC and wasn't to impressed with this crypto to be honest.

He went through the procedure of what he did on IRC:

Quote:

Piru - first it was obvious that the original jpeg had some extra data appended after it Piru - so first you extract the extra data out, and work with that Piru - next you easily identify a repeating pattern, of which length is 105 bytes Piru - I believe that's the len of the passphrase... but we don't need to know that Piru - next, you find the most repeating pattern for 105 chars Piru - that's very likely representing 0 bytes Piru - which are plentiful in many formats Piru - sure enough blocks 3 onwards contain the same pattern Piru - so extract that byte stream and assume it's 0 bytes "processed" by the algorithm Piru - so try experimenting... the obvious choice for really naive "crypto" is XOR (exclusive or) Piru - so try XORing each block with the 105 byte "key" Piru - this gives you something that can easily be identified as JFIF file Piru - some bytes are off, but every 7th char is correct Piru - next, compare header of a valid JFIF file and the output Piru - you quickly notice that some bytes appear to be bit rotated Piru - see how much and you can easily spot that the shift count depends on the position Piru - 1st byte rotated 1 positions Piru - 2nd byte rotated 2 positions Piru - 7th byte rotated 8 positions Piru - which is why 7th byte is always visible anyway, since rotating a byte by 8 gives the byte itself Piru - so now Piru - we know everything Piru - just run the whole shebang on the data and poof, you get the "encrypted" data out, clear text Piru - without ever knowing the password Piru - interestingly you don't ever need to know the password

Last edited by zerohero on 10-May-2010 at 06:20 PM.
Last edited by zerohero on 10-May-2010 at 06:18 PM.

_________________
Common sense - So rare it's almost like a super power

@zerohero

Hmm, I thought I had it pretty difficult to crack, looks like it will need some more work.

The method used was quite simple, bit xor'ed against the password, but I thought the bit shifting might have slowed down the cracking though.

Granted if you reverse engineer the program then it would give away the method but still, I am surprised it it being hacked so quickly, but that was the aim of the exercise anyway to see if the method was any good.

Does he know what the encryption password was ?

_________________
Glass coffins, a success?
Remains to be seen.

I just read your edit of the description.

Thanks a lot, that is *Very* useful in helping me to make improvements.

_________________
Glass coffins, a success?
Remains to be seen.

@AmigaOneProductions

Quote:

Granted if you reverse engineer the program then it would give away the method but still, I am surprised it it being hacked so quickly, but that was the aim of the exercise anyway to see if the method was any good.

He didn't need to reverse engineer anything.

Quote:

Does he know what the encryption password was ?

No, he realised he didn't need it.

He also suggested you find yourself a book about cryptography and read it. He said this wasn't suitable for commercial level applications at all.

For everyone reading, this last part was not meant as an offense, if anyone thought it was. Just so you know.

_________________
Common sense - So rare it's almost like a super power

@zerohero

Quote:

For everyone reading, this last part was not meant as an offense, if anyone thought it was. Just so you know.

No offense taken

The comments have been most helpful, hopefully he'll have another spare 20 mins when I have given the algorythm a rethink

_________________
Glass coffins, a success?
Remains to be seen.

@AmigaOneProductions

This thread has reminded me of a section in the PGP documentation I read when I first installed PGP ages ago. That section is also available separately online, you may also find it interesting.

The most pertinent parts of it are

Quote:

When I was in college in the early seventies, I devised what I believed was a brilliant encryption scheme. A simple pseudorandom number stream was added to the plaintext stream to create ciphertext. This would seemingly thwart any frequency analysis of the ciphertext, and would be uncrackable even to the most resourceful government intelligence agencies. I felt so smug about my achievement. Years later, I discovered this same scheme in several introductory cryptography texts and tutorial papers. How nice. Other cryptographers had thought of the same scheme. Unfortunately, the scheme was presented as a simple homework assignment on how to use elementary cryptanalytic techniques to trivially crack it. So much for my brilliant scheme.

and

Quote:

I remember a conversation in 1991 with Brian Snow, a highly placed senior cryptographer with the NSA. He said he would never trust an encryption algorithm designed by someone who had not "earned their bones" by first spending a lot of time cracking codes. That made a lot of sense. I observed that practically no one in the commercial world of cryptography qualifies under this criterion. "Yes," he said with a self-assured smile, "And that makes our job at NSA so much easier." A chilling thought. I didn't qualify either.

There is a visual basic book published in the mid 90's that had a crypto challenge offering $1,000 dollars and it was based on the random number generator. I spent *months* when I was a teenager trying to crack that thing. Never did. If I can locate that book, I'll scan in those pages and relevant info, maybe someone on here can win that money (if someone hasn't already).

_________________

@antony

Re: the PGP Documentation.

Thanks, an interesting read, I know that I will never beat PGP, and that was never my intention, but this excerise has shown just how weak the algorythm is that I used.

On reflection, I don't think I will be producing a commercial version based on this experiment, but I may get around to making improvements based on what I have learned.

(Methinks stick to video productions )

_________________
Glass coffins, a success?
Remains to be seen.

@zerohero

say well done to him :) i got as fars as the 105 bytes possibly bein the key, but my brain wasnt in gear(did a charity run in the afternoon, so was half dead)

@amigaoneproductions
So seems like u used a Caeser type Cipher.

As i mentioned before, learn about DES i did this at uni and isnt hard to understand, once u have knowledge of this move on to AES etc, also look into MD5 or SHA hashing.

As for the repeatitious lines of data, look into block encoding methods, like ChainBlockCipher key for one block is XOR`d to form a key for the next block

Last edited by TheAMIgaOne on 10-May-2010 at 11:11 PM.

_________________
Cross-developer on Windows, OS3, OS4, Linux; Current Projects:-
Nephele Cloud App OS4
UserProfile System OS4
AmigaOneXE OS4.1.6

TaoSoftwareBlog Youtube

@Arnie

not really, if i wanted to make a virus it would be easier enough. I use to muck around making Trojans or keyloggers when at school. Embedded a executable into and executable is one thing for security, embedding and then executing without the user knowing is another.

_________________
Cross-developer on Windows, OS3, OS4, Linux; Current Projects:-
Nephele Cloud App OS4
UserProfile System OS4
AmigaOneXE OS4.1.6

TaoSoftwareBlog Youtube