views:

113

answers:

4

OK, now I have coded for an implementation of AES-128 :) It is working fine.

It takes in 128 bits, encrypts and returns 128 bits

So how do i enhance my function so that it can handle more than 128 bits?

How do i make the encryption algorithm handle larger strings?

Can the same algorithm be used to encrypt files? :)

The function definition is

public byte[] Cipher(byte[] input)
{

}
+5  A: 

There are various "chained" or "codebook" modes that you can run a block cipher in. You'll need to read about them and decide which you're going to support. You'll also need to decide what sort of block padding you'll do for partially filled terminal blocks.

Have a read of http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation to start with.

Yes, of course you can encrypt files. You just write the blocks out to another file.

Get a copy of Applied Cryptography if you've not already got one. It's the best intro into this sort of thing that I've read even though it's quite long in the tooth now.

Trevor Tippins
+1 For answering the question. If your doing anything more than research....you'll also want to get ~4 PhDs in theoretical and applied mathematics, ~3 in computer science, 2 in cryptography followed by 15+ years working for the NSA or the like...Then you might be about ready :)
Rusty
+1  A: 

If this is a learning exercise, great - do what everyone else said.

If this is going anywhere near production systems, confidential data, etc - stop right there. DO NOT WRITE YOUR OWN ENCRYPTION CODE, EVER. There are a million very subtle ways to screw it up and only one way to get it right. I'm sure you're a regular genius and all, but the strong likelihood is that you will unintentionally write subtly broken, easily compromised code without even knowing it; everyone does - that's just how it works.

If this is for a real project, do yourself a massive favour and use some tried and tested encryption libraries which have suffered the slings and arrows of outrageous fortune, survived the trials of life in the wild world, been attacked, patched and are still standing.

Besides, I'm sure you've got enough to do already :)

dflock
I completely agree :)
Ranhiru Cooray
There are no encryption algorithms that have been cracked and then fixed (at least not once they've made it to AES/DES standard). They are broken and then not used anymore.
Noon Silk
And don't think about making a rocket ship, that's for the NASA experts, and don't think about cooking from raw ingredients, microwave a ready meal instead.
Pete Kirkham
No, really. Use someone else’s password system. Don’t build your own.Most of the industry’s worst security problems (like the famously bad LANMAN hash) happened because smart developers approached security code the same way they did the rest of their code. The difference between security code and application code is, when application code fails, you find out right away. When security code fails, you find out 4 years from now, when a DVD with all your customer’s credit card and CVV2 information starts circulating in Estonia. (Source: http://www.securityfocus.com/blogs/262)
Daniel Brückner
@Daniel: That's some pretty bad advice.
Noon Silk
What? Not to develop security-related code yourself? Why?
Daniel Brückner
@Daniel: To "use someone else's password system". But I really don't care to go into it. You may decide for yourself if I am correct or not.
Noon Silk
@silky - I'm not sure what you think is wrong with Daniels advice? Maybe you could explain?
dflock
@dflock: I quite honestly can't be bothered. I've noticed that almost exclusively when I explain something in detail like this, I do not receive a response, and I suspect no opinions have been changed. I really don't care anymore. I should withdraw the previous comment. You are all free to make your own mistakes. It's the only way to learn, I suppose.
Noon Silk
Not to provide substantive arguments really weakens your position - but that is your decision. Nonetheless I want to quote another famous story. When Jon Bentley assigned it as a problem in a course for professional programmers, he found that an astounding ninety percent failed to code a binary search correctly after several hours of working on it, and another study shows that accurate code for it is only found in five out of twenty textbooks (Kruse, 1999).
Daniel Brückner
Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contains an error that remained undetected for over twenty years. (Source: http://en.wikipedia.org/wiki/Binary_search_algorithm#The_algorithm) And implementing the binary search algorithm is a piece of cake compared to implementing cryptographic algorithms.
Daniel Brückner
@Daniel: Anecdote-based argumentation is possibly the most counter-productive process ever conceived.
Noon Silk
While this may be true in the general case I can not think of something much better than giving examples to argue that even very smart developers are usually not nearly smart enough to get critical code absolutely correct. And although I did probably not provide the best possible arguments to support my point I at least tried to do in contrast to you.
Daniel Brückner
+1  A: 

First, don't implement cryptographic algorithms yourself - use an implementation created by experts. Chances are good that you will make errors and build an insecure system. The .NET Framework has extensive build-in support for cryptography in the System.Security namespace including an AES algorithm imlementation. (The former does not apply if you are doing it for the sake of fun ;)

The encode data larger the block size you have to choose an operation mode. Wikipedia lists the most common ones here and some more usually used for disc encryption here.

Daniel Brückner
+1  A: 

There is a C++ open source library Crypto++ http://www.cryptopp.com/ Athough it seems that you are trying to implement it in Java, I think maybe it worth while to take a look. After all, it is all about algorithm...

Michael
http://www.pgp.com/ is a commercial crypto product.http://www.openpgp.org/ is a email encryption standard.http://www.gnupg.org/ is an open source implementaion of OpenPGP.And never trust an encryption system until you've seen the source code.
Michael
To some extent, cryptography technology is sensitive...http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States#Current_status
Michael