[2.0] Working with long predefined strings?

[high6]

So I need to have in my program a byte array predefined which is 10,000 bytes. Problem is that it makes the IDE extremely slow, is there a way to speed up the ide while having a load of text?

[vbNeo]

Can't you load the data from say, a textfile, at certain points during execution? Or is it neccessary to have all the data loaded into the memory at once?

[jmcilhinney]

"I must have X but X doesn't work. What do I do?"

How can we answer that? Obviously if your app won't go with this array then you can't have the array. If we don't know what the array is for then how can we provide realistic alternatives? We're just guessing. Provide a full and complete description and then we can provide potential solutions.

[high6]

"I must have X but X doesn't work. What do I do?"

How can we answer that? Obviously if your app won't go with this array then you can't have the array. If we don't know what the array is for then how can we provide realistic alternatives? We're just guessing. Provide a full and complete description and then we can provide potential solutions.

byte[] Key = { 0xB4, 0x3C, 0xC0, 0x6E, ... };

The text that you have entered is too long (393629 characters). Please shorten it to 10000 characters long.

Was too long to post it all.

Anyways I thought of a file but I rather not have to load up a file for the encryption each time it runs.

[jmcilhinney]

Was it just my imagination or did I ask for a "full and complete description" in my previous post? We already know you're using a byte array. Is it a secret what you're doing with it? "I've got a big byte array and my IDE runs slow" is not full or complete. You're asking us to speed up some code that we have never seen and know nothing about. That would be magic, not programming.

[visualAd]

If I were going to guess what you were doing with a 10,000 byte array of hexadecimal values in your program code, I would say that you are writing an exploit to carry out some kind of heap overflow. If that is the case you won't be getting much help from anyone here.

[wossname]

That's a bit of a stretch.

[high6]

If I were going to guess what you were doing with a 10,000 byte array of hexadecimal values in your program code, I would say that you are writing an exploit to carry out some kind of heap overflow. If that is the case you won't be getting much help from anyone here.

Nah, its a key for an encryption.

[visualAd]

AFIK, there is no encryption standard which uses a 80,000 bit key. If you want to use a large file as a key I suggest you read it in 1kb chunks and hash them together.

[high6]

AFIK, there is no encryption standard which uses a 80,000 bit key. If you want to use a large file as a key I suggest you read it in 1kb chunks and hash them together.

Well It is a custom encryption algo.

At this point it looks like only way is to load it.

[wild_bill]

Rather than having a single line of code with 10,000 chunks of data, wouldn't it be more organized to have 10,000 lines of code, each with one peice of data?

byte[9999] Key;
byte[0] = 0xB4;
byte[1] = 0x3C;
byte[2] = 0xC0;
byte[3] = 0x6E;
 ...

[visualAd]

Well It is a custom encryption algo.

At this point it looks like only way is to load it.

There are a 1000 reasons why you shouldn't be using your own algorithm:

1. The encryption algorithms which are now standard have been benchmarked for speed and efficiency.
2. They are also rigorously tested to ensure their security. Security weaknesses in the protocol have been fixed and they are constantly reviewed as technology advances. The Rejndael algorithm using a 256 bit key has a massive 1x10^77 possible keys. Assuming the universe is 13.5 billion years old and you started an exhaustive search for the key the moment of the big bang at a rate of 1 billion keys per second you would have only have searched 0.0000000000000000000000000000000000000000000000000368% of the key space to this date.
   
3. The goal of every encryption standard is to rely solely on the security of the key and not the secrecy of the implementation / algorithm; meaning the key and only the key needs to be kept secret.

From what I can see your system already has problems the implementation already has problems with efficiency; and unless you are using some kind of one time pad (which would make it very easy to crack).- the size of your key would make any encryption operations an order of magnitude slower. Don't say its secret because that is not encryption; it is obfuscation.

I suggest that you look at the MSDN documentation and read up on the System.Security.Cryptography name space. I recommend AES with a key >192 bits. If that is good enough for the US DoD; I am sure it is good enough for you.