Encryption :-)

I am really new to encryption and I wanted to know how well this works,

Code:

---

Public Function NewEncry(TheText As String, TheKey As String)

Dim TheLetter As String
Dim TheEnd As String

  Randomize
  Rnd -1

  For i = 1 To Len(TheText)
    For j = 1 To Len(TheKey)
      TheLetter = Chr((Asc(Mid(TheText, i, 1)) Xor Int(Rnd * Asc(Mid(TheKey, j, 1)))))

    Next
   
    TheEnd = TheEnd & TheLetter

  Next
  NewEncry = TheEnd

End Function

---

for me it works pretty damn good :D but I dont know if this is enough for other people.......

since this is my first encryption program(I am writing an encrtption program :)) I need to know if this is strong enough encryption...

what I like about this is if you get one letter in the key wrong, it screws the whole message up.... :)

please give feed back on this....

:D

It's not too bad for text but binary files often have large numbers of nulls and anything Xor'd with 0 is the origional number. So, if you encrypted an exe file and there was a chunk of nulls in the beginning (first place I'd look) then the password characters would pop up there. You have the little Rnd seed thing happening so the order would be jumbled but if someone had a password like GOD555 or something lame like that then it would be guessable.

If it's text and you're not making fincial transactions with it then I think you'd be fine.

If you want something serious, go download the DES spec from the US govt web site, it's not hard to understand, but it runs sort of slow compared to this thing you have.

thanks for replying :)

but the way this works is,
if there are three letters in a row (hhh for example) it makes them all different characters when encrypted.

thanks again for replying :)

For really fast encryption, go to my site

ok, I got fast encryption,
how about REALLY GOOD encryption, that isnt copyrighted or illegal to export(I heard 128bit encryption is illegal to export to other countries)?

and BTW what do the bits mean?

The bits comes with how many bytes*8 are read and written to the file at each encryption loop.

I don't know that much about encryption but I think that PGP(Pretty Good Privacy) is suppose to be the best. You can buy a book that has the source code here. Although it is out of print, you can place your order with amazon.com and they will try to get for you.

There are ways that are better, but they're often patented or snapped up by the Military.
PS: denniswrenn - 128bits was illegal to export, but not anymore (I'm using the 128bit version of IE5 in the UK)

This is an algorithm for encryption, and it's pretty good:

Add/Subtract a value to each Ascii code
Add the same random number to each ascii code
Add/Subtract again
Save the random number as the first two characters in the file
Encrypt them, but without the randomness.

There is a copy of the DES spec here:

http://www.cerberussystems.com/INFOSEC/stds/fip46-3.htm

That is 56bit and triple DES which is basically the same algorithm is 112 - 168bit depending on how it is used. That way you could make an international version depending on currently changing laws and a US version with basically the same code.

I learned a lot about how encryption works from going through this spec.

as for your "hhh", yes of course it has three different letters, because they are Xored with different parts of the key, but xoring against a null (chr(0)) will bounce the key chr back, like I said, you won't have much of a problem with text but try opening some binary files in an editor and check all the nulls that often appear. I'm not saying that the encryption level drops to zero but it does give you a path to crack

If you want to make it even more daring for hackers, after everything is done, reverse the string and put the ascii codes on backwards. Here is an example of what to do:

ASCII CODES:

023 056 095 052 052
=== === === === === Add 30
053 086 125 082 082
=== === === === === Random: Minus 23
030 063 102 059 059
=== === === === === Add 15
045 078 117 074 074
=== === === === === Redisplay backwards (Adding)
097 130 212 130 097
=== === === === === If we're done, we'll store the decryption in the file

so.. how many bit's is my encryption?

It looks like 8, I think.

how do I make the bit's go up?

The bits of encryption are calculated from the number of bits in the key.

EG: (DES again, sorry)
A key in DES is 8 bytes (64 bits) long and the 8th bit of every byte is used as parity leaving 56 bits. To brute force this you would need to attempt to decrypt the cypher text with each possible combination of the bits. This is 2^56 or 72,057,594,037,927,900 combinations. at 1,000,000 tests per second it would take 2342.7 years to search the whole key space (then of course you have to know which of the decrypted plain texts is correct as all will pass you a result of some sort). 56bit encryption is considered weak too, as 2^128 gives about 340,282,366,920,938,000,000,000,000,000,000,000,000 combinations and at 1,000,000 tests per second it would take 11,063,071,125,966,800,000,000,000 years to search the whole space (by which time the sun would have engulfed the earth!

But a key is only as secure as it's algorithm. If the method of encyphering the plain text with the key is poor then obviously better methods than brute force will be employed.

As for PGP, well, it's bit length is huge! this is because the public key is handed out and people can encrypt a message like "AAAAAAAAAAAAAAA" with the public key and see, the encrypted result. because you have the plain text and cypher text, and you can choose your plain text you are on your way to crypto-analising the private key, and if you crack it then everything encrypted with that key is yours to read (problem is you need maths at a level of a rocket scientist to attempt it)

But you get the idea about bit lengths. Remember, once the bit length gets to a certain size it become impossible to brute force in your life time, because of this, the algorithm becomes much more important than how strong in bits a certain system is.

Sorry, got a bit carried away... :D

So the bit length in your aglorithm would be

Code:

---


    8 * Len(TheKey)

---

As your algorithm has varying key length a longer key would produce a higher bit strength.

BUT!!! (Ready to rave on again)
your key is a password in text and therefor using less than half of the bit combinations in a byte so it would be more like "6 * Len(TheKey)" Many algorithms pass out a key written in HEX so that you have more combinations

so 48 bit key might look like
5A 8F 33 0C 22 E3

There are also often bad passwords, in DES there are about 16 keys that should be avoided as once they go through the algorithm they produce almost the same or backwards text.

Quote:

---

Originally posted by Sastraxi
If you want to make it even more daring for hackers, after everything is done, reverse the string and put the ascii codes on backwards. Here is an example of what to do:

ASCII CODES:

023 056 095 052 052
=== === === === === Add 30
053 086 125 082 082
=== === === === === Random: Minus 23
030 063 102 059 059
=== === === === === Add 15
045 078 117 074 074
=== === === === === Redisplay backwards (Adding)
097 130 212 130 097
=== === === === === If we're done, we'll store the decryption in the file

---

That method isn't secure. It is only secure if the hacker/cracker doesn't know the encryption algorithm. The can easy find it by disassembling the exe. Everybody can know how encryption algorithms like DES and Blowfish work. But they can't decrypt the files, because they don't have got the key.


[/B][/QUOTE]

Quote:

---

Originally posted by denniswrenn
I am really new to encryption and I wanted to know how well this works,

Code:

---

Public Function NewEncry(TheText As String, TheKey As String)

Dim TheLetter As String
Dim TheEnd As String

  Randomize
  Rnd -1

  For i = 1 To Len(TheText)
    For j = 1 To Len(TheKey)
      TheLetter = Chr((Asc(Mid(TheText, i, 1)) Xor Int(Rnd * Asc(Mid(TheKey, j, 1)))))

    Next
   
    TheEnd = TheEnd & TheLetter

  Next
  NewEncry = TheEnd

End Function

---

for me it works pretty damn good :D but I dont know if this is enough for other people.......

since this is my first encryption program(I am writing an encrtption program :)) I need to know if this is strong enough encryption...

what I like about this is if you get one letter in the key wrong, it screws the whole message up.... :)

please give feed back on this....

:D

---

Your code is just like PGP. The only difference is that your code uses XOR, and PGP uses +. They are secure for plain text documents. Most file formats like .doc, .gif, .jpg, .bmp, etc. use headers that are in the very beginning always the same an the rest guessable. If you know the file format of the original file. You can just XOR the encrypted data with the header and you got the key!

It's not the best strategy of encryption: Posting the source-code on an open-access website ;)

WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG! WRONG!

First (or there abouts) rule of modern encryption, if the its strength is based on a secret algorithm then it's weak. An encryption algorithm should be able to be passed to many people and groups for input so that it can be improved. One of the problems with the DVD encryption algorithm is that it was proprietry so when the linux people wanted to make a version Panasonic (Matsushita kotobuki) and hitachi told the freeware communitry where to go and that they wouldn't release it. So the linux comunity reverse engineered it (legal in the US copyright laws) then there was a big stink and the linux community said - The algorithm was rubbish to start with, if it was opened to the open source people from the start this never would have happened. But then the DVD code is a crock anyway, ask youself "what do benefit to the customer do 'zones' have?" (do you know how many millions of foreigners around the world this pisses off) US can't export zone 1 so US citizens living in other countries are screwed, the reverse situation is an even bigger problem.

The major algorithms in play at the moment are published! PGP, DES, Blowfish etc are all there for you and knowing them lets you impliment them in software but it doesn't help you crack them.

If the strength of your algorithm relies on it being a secret then it's poor... its "welcome back to stone age encryption" stuff

As I've never tried encryption, i read somewher so many years ago something about random? randomize? rnd()? but using the current time as a seed

What effect does this have if any?

DocZaf
{;->

By using randomize and rnd, you would just use the algoritm that produces (pseudo)random values, You should use it with already encrypted data to get any effects. Current time would just be as an addition to the key

Kedaman

So is it better to use time or worse?
or no difference?

DocZaf?
{;->

I don't recommend you put time, you would have to either store the date somewhere or write it up, i think it would just be a mess. On the other hand the rnd algoritm is good.

I don't get it quite yet...

Is this used to move confidential data from UserA to UserB?

If so, then UserB will need to know the Key.

Since it'll take (according to kedaman) until the earth dies to unencrypt this, how does UserB get the key from UserA?

you could encrypt the key ;)

very basic,

You've just stumbled across the whole point of pubic key encryption (like PGP).

Many people who have little clue about encryption argue about which is better when actually they are used for very different things.

Algorithms like DES or blowfish are used to keep information secret, not to transfer it. Public key encrytion has a public key and a private one, the public one which anyone can know, can only encrypt data, it takes the private key of the set to decrypt it. So I can pass you my public key and you can encrypt messages with it, if anyone else get's that key then they can only encrypt messages too. Only the private key which isn't given to anyone can decrypt the message you wrote, so even you can't decrypt the message you encrypted for me.

The algorithm in the question of this thread uses the same key to encrypt and decrypt so its use is where both ends are secure and it's just the transfer stage that needs protecting. it implicitly trusts anyone with a key to encrypt and decrypt.

varitions on this theme are like Windows NT challenge response system to passwords to avoid passing the key (password) over a LAN, but I'll leave that for later, I've rambled too much for this thread already

Quote:

---

Originally posted by denniswrenn
you could encrypt the key ;)

---

And how would you make UserB know the Key you used to encrypt the key? ;)

you could use the same key that you encrypted ;)

Instead of writing your own encryption functions, which will EXTREMELY slow in VB, you can use the Crypto API which is provided for free by Microsoft. This allows for very high quality encryption as well as managing and creating keys. It also performs file signing which allows you to veryify the integrity of files.

Look for information on it on MSDN. It's fairly complicated, but some examples are available a various websites. Sorry I'm not providing some specific links.

naaaaa... i like writing my own stuff.... because then I not only know it works, but i know how it works.

and anyway the best part of programming is saying

"wow I did this, without any outside components...."
which is why I am learning C++
because writing alot of programs in VB is pretty simple, but in C++ its a little harder, actually alot harder, but if you successfully write a good C++ program, you are really proud of yourself.

How can I make my encryption better without using a copyrighted/patented algo.????

Quote:

---

Originally posted by denniswrenn
you could use the same key that you encrypted ;)

---

:<

And how would you unencrypt the encrypted key, if the key used to encrypt it was also encrypted?

Although that makes no sense, I think logically I win.

UserB will always have to know at least one key in an unencrypted form, and that reomves the integrity of all of the encrypted files.

I hope you know i was kidding......


;)

I'm using this:

rnd(-1)
randomize seed 'seed is a number, choosen by the user
For i = 1 To lentxt) 'txt is the text which is encrypted
a = asc(Mid(txt, i, 1))
If a > 31 Then
Char = a + Int(Rnd * 224)
If Char > 255 Then
Char = Char - 224
End If
newtext = newtext & Chr(Char)
Else:
newtext = newtext & Mid(txt, i, 1) 'it doesn't encrypt
End If 'special characters

Next i
txt= newtext

For decrypting you subtract Int(Rnd * 224) instead.

I don't really know how safe it is, or how many bits.
Perhepas someone could tell me.
Then of course it can be made better by encrypting many times.

I am even newer to encryption than denniswrenn.
Can anyone explain to me how it works?
For example, if my key is: 34 212 67 253
then what do i do with it? do i divide my text into sections that each consists on a four char string and XOR it with the key?

And another question:
In the first post, what are the Rnd and Randomize used for?

Code:

---

Public Function NewEncry(TheText As String, TheKey As String)
'declare my variables
Dim TheLetter As String
Dim TheEnd As String

'not really sure, just saw this somewhere once :)
  Randomize
  Rnd -1

'first loop for the main text
  For i = 1 To Len(TheText)
'second loop, for the key
    For j = 1 To Len(TheKey)
      TheLetter = Chr((Asc(Mid(TheText, i, 1)) Xor Int(Rnd * Asc(Mid(TheKey, j, 1)))))
'get one letter at a time from each the key and the text and xor them,
'one of them is multiplied by a random number
'the sequence of random numbers are the same every time
'but if you remove "Rnd *" then the encryption algo. wont work very well

    Next
   
    TheEnd = TheEnd & TheLetter
'make sure you get all of the characters

  Next
  NewEncry = TheEnd

End Function

---

you dont divide the text into any sections, you need to read each of the characters, I do it using Mid, I have seen some cases where people use StrConv to convert the string into a byte array.
I have also written a very bad simple encryption algorithm.

It was my first encryption function, and it worked OK..

it doesnt really need to be explained, it just subtracts or adds 128 depending on the value of the ascii code.

Code:

---

Public Function Enc(TheText As String) As String
Dim TheLetter As String
Dim TheEnd As String

  For i = 1 To Len(TheText)
    TheLetter = Mid$(TheText, i, 1)
  If Asc(TheLetter) < 128 Then
    TheLetter = Chr$((Asc(TheLetter) + 128))
  ElseIf Asc(TheLetter) >= 128 Then
    TheLetter = Chr$((Asc(TheLetter) - 128))
  End If
 
  TheEnd = TheEnd + TheLetter
Next
Enc = TheEnd
End Function

---

it is very very simple.

Okay I'm confused. Paul282 has stated that an algorithm is just as good if not better if it is public vs. secretive for an encryption program. But let's say I have created an encryption program that adds one to the ASCII value of each character to encrypt a message to a file and it also encrypts a password to the file so that you must know the password to unencrypt it. If everyone knows that the encryptor adds one to each ascii value to encrypt the message, what keeps them from creating a program to simply reverse the process and automatically unencrypt all encrypted files? And by the way, this is an EXAMPLE, I wouldn't actually create an encryptor that's that simple.

I think you've just given yourself a perfect example, say you decide on that algorythm and keep it secret, then encode your messages with it, they would be cracked straight away, If you made that algorythm public someone would email you and say "You're algorithm's absolutley crap, here's an improvement on it, using a key. even if someone knows the algorithm it's very hard to crack a good one without the key. so even though your algorithm is ublic it is better than being private because people will tell you its weaknesses and improve on it.