GreenthumbUK
MIS
I have written some scrpits within Excel that I dont want anyone to be able to see or access, how can i do this??
cheers
cheers
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Security !!! 5
- Thread starter GreenthumbUK
- Start date
- Status
Well - how do you "undo" what has been done without storing the key somewhere. You could write it out to a text file somewhere or maybe even hide it in the registry but most will have the password / key residing in the file somewhere
Rgds, Geoff
Never test the depth of water with both feet
Help us to help you by reading FAQ222-2244 before you ask a question
Rgds, Geoff
Never test the depth of water with both feet
Help us to help you by reading FAQ222-2244 before you ask a question
>how do you "undo" what has been done without storing the key somewhere
Loads of ways of doing this. e.g. for example, picture an algorithm which takes a plain text password and creates a 128-bit hash from it. This hash is then used as an ancryption key to do a symetrical encryption of whatever it we neeed to be encrypted. We send off this encrypted item. Neither the password used nor hashed version used as the encryption key is included with that file.
As long as I remember the password I can decrypt the file by letting my algorithm dynamically recreate the 128-bit hash from my password, and using that hash to do the decryption.
>password/key residing in the file
Not if they are using a decent encryption method they wouldn't. Keeping the password in the encryted files is one of the surest ways of seriously weakening the encryption
Loads of ways of doing this. e.g. for example, picture an algorithm which takes a plain text password and creates a 128-bit hash from it. This hash is then used as an ancryption key to do a symetrical encryption of whatever it we neeed to be encrypted. We send off this encrypted item. Neither the password used nor hashed version used as the encryption key is included with that file.
As long as I remember the password I can decrypt the file by letting my algorithm dynamically recreate the 128-bit hash from my password, and using that hash to do the decryption.
>password/key residing in the file
Not if they are using a decent encryption method they wouldn't. Keeping the password in the encryted files is one of the surest ways of seriously weakening the encryption
Geoff, (reply to strongm later in post)
Don't worry - I wasn't feeling attacked in any way. I really enjoy being challenged, especially regarding this encryption technique. Nobody's shot it down yet, but I want to be the first to know if someone finds a way!
Having said that, I do want to reply to two comments you made (if you haven't tired of the discussion yet!):
"Basically, it'll probably take a cracker apprx the same amount of time to crack a file as you spend protecting it.... ". My routine takes about three seconds to encrypt a range containing 13000 cells (A1:Z500, which is my routine's default) with a 40-character key. Brute-forcing a 40-character key (where each character is one of over a hundred possible values), with the additional constraint of having to close/reopen the file after every attempt, could take weeks on a really high-powered computer, much longer on a PC. . .
"at the end of the day, it still relies on a password and that password must reside in the file" - but it doesn't, which is precisely the beauty of this approach! It simply uses the key phrase (or more correctly, the ASCII values of it's characters) as the "wildcard" in an algorythm that scrambles the data. The only thing stored in the file is the "residue", if you will, of the interaction between the original data and the key phrase. The key phrase isn't stored in the file anywhere. It's supplied by the user at the time of encryption, and again at the time of decryption by whoever is opening it. If you're sending the file to someone it's up to you to work out/communicate what the key phrase will be. Which leads to my comment for strongm:
strongm,
I can't remember what it's called, but it's a technique I read about some time back. The sender and the reciever would both have identical copies of a book (preferrably with at least 365 pages). To encrypt a message, sender goes to correct page of book for that day (i.e. if it's Feb 1, he goes to page 32) and counts to a predetermined word (ex. they might always use a combination of the 5th, 8th, and 9th words on the page) as his key phrase. Then he converts the key phrase to numbers (so "abc" becomes "123") and his message to numbers (assume spaces are zeros, so "Hi dad" becomes "890414"). Then he uses the key numbers ("looping" them as necessary) to modify the message numbers: 8+1=9, 9+2=11, 0+3=3, 4+1=5, 1+2=3, and 4+3=7. Finally, he converts the numbers back to characters: 9=i, 11=k, 3=c, 5=e, 3=c, and 7=g. So applying the key phrase "abc" to our original text "Hi dad" gives us the encrypted "ikcecg". Notice how identical characters get encrypted differently, and different characters can be represented by the same encrypted character! Decryption just reverses the process, taking the correct key from the book based on the date of the message, and subtracting the appropriate values. Using the wrong key just further munches the data.
Of course, being computer-driven, I can afford to make my method is a bit more complex (for example, adding in random "padding" characters every 4 characters to make it even harder to decode if they haven't obtained my algorythm, or making it case-sensitive to double the number of possible characters a key character could be).
Why not just use a commercial file-encryption application? Well, I wanted to see if I could program something myself, and this method has the added advantage of requiring nothing more than Excel (and my add-in) on the computers of the sender and receiver.
I think this might be the longest post I've ever done![[lol]](/data/assets/smilies/lol.gif "[lol] [lol]")
Sorry for being long-winded!
VBAjedi![[swords]](/data/assets/smilies/swords.gif "[swords] [swords]")
Don't worry - I wasn't feeling attacked in any way. I really enjoy being challenged, especially regarding this encryption technique. Nobody's shot it down yet, but I want to be the first to know if someone finds a way!
Having said that, I do want to reply to two comments you made (if you haven't tired of the discussion yet!):"Basically, it'll probably take a cracker apprx the same amount of time to crack a file as you spend protecting it.... ". My routine takes about three seconds to encrypt a range containing 13000 cells (A1:Z500, which is my routine's default) with a 40-character key. Brute-forcing a 40-character key (where each character is one of over a hundred possible values), with the additional constraint of having to close/reopen the file after every attempt, could take weeks on a really high-powered computer, much longer on a PC. . .
"at the end of the day, it still relies on a password and that password must reside in the file" - but it doesn't, which is precisely the beauty of this approach! It simply uses the key phrase (or more correctly, the ASCII values of it's characters) as the "wildcard" in an algorythm that scrambles the data. The only thing stored in the file is the "residue", if you will, of the interaction between the original data and the key phrase. The key phrase isn't stored in the file anywhere. It's supplied by the user at the time of encryption, and again at the time of decryption by whoever is opening it. If you're sending the file to someone it's up to you to work out/communicate what the key phrase will be. Which leads to my comment for strongm:
strongm,
I can't remember what it's called, but it's a technique I read about some time back. The sender and the reciever would both have identical copies of a book (preferrably with at least 365 pages). To encrypt a message, sender goes to correct page of book for that day (i.e. if it's Feb 1, he goes to page 32) and counts to a predetermined word (ex. they might always use a combination of the 5th, 8th, and 9th words on the page) as his key phrase. Then he converts the key phrase to numbers (so "abc" becomes "123") and his message to numbers (assume spaces are zeros, so "Hi dad" becomes "890414"). Then he uses the key numbers ("looping" them as necessary) to modify the message numbers: 8+1=9, 9+2=11, 0+3=3, 4+1=5, 1+2=3, and 4+3=7. Finally, he converts the numbers back to characters: 9=i, 11=k, 3=c, 5=e, 3=c, and 7=g. So applying the key phrase "abc" to our original text "Hi dad" gives us the encrypted "ikcecg". Notice how identical characters get encrypted differently, and different characters can be represented by the same encrypted character! Decryption just reverses the process, taking the correct key from the book based on the date of the message, and subtracting the appropriate values. Using the wrong key just further munches the data.
Of course, being computer-driven, I can afford to make my method is a bit more complex (for example, adding in random "padding" characters every 4 characters to make it even harder to decode if they haven't obtained my algorythm, or making it case-sensitive to double the number of possible characters a key character could be).
Why not just use a commercial file-encryption application? Well, I wanted to see if I could program something myself, and this method has the added advantage of requiring nothing more than Excel (and my add-in) on the computers of the sender and receiver.
I think this might be the longest post I've ever done
Sorry for being long-winded! VBAjedi
No need to be sorry. And if simple encryption is all you need and you learned something then even better. However, what you have here is basically a Gronsfield cypher, and can actually be broken fairly easily (it can be broken by hand, using pencil and paper, no computer required...)
Thanks for the info! You must have some background in cryptology - Googling "Gronsfield cypher" only turns up one passing reference, so it's apparently not a common one. Do you have any links that would give me more information on it, and the methods (or at least the general approach) used to crack it? The material I read on the method didn't use that name, and held that it was still a viable encryption method.
And no, I don't need unbreakable security (just something more secure than the built-in Excel tools), but I would like to know where the limitations/weaknesses of my tool lie (which is why I jumped into this thread in the first place!). You're the first person that's ever offered some insight into what those might be.
Thanks!
VBAjedi
And no, I don't need unbreakable security (just something more secure than the built-in Excel tools), but I would like to know where the limitations/weaknesses of my tool lie (which is why I jumped into this thread in the first place!). You're the first person that's ever offered some insight into what those might be.
Thanks!
VBAjedi
This is a very interesting thread.
VBAJedi,
Not sure with threads you found, but I think the name has been confused, as I found plenty of links for the Gronsfeld Cipher.
About Gronsfeld:
And here's a link about cracking a Gronsfeld cipher:
VBAJedi,
Not sure with threads you found, but I think the name has been confused, as I found plenty of links for the Gronsfeld Cipher.
About Gronsfeld:
And here's a link about cracking a Gronsfeld cipher:
Luke - time to crack = time to protect.....I should've said "including time taken to develop and code the encryption" ;-)
I guess I've just never handled data that sensitive
Rgds, Geoff
Never test the depth of water with both feet
Help us to help you by reading FAQ222-2244 before you ask a question
I guess I've just never handled data that sensitive
Rgds, Geoff
Never test the depth of water with both feet
Help us to help you by reading FAQ222-2244 before you ask a question
>What encryption does it employ?
Depends which release you have access to...
CryptoAPI 1.0, released with W95 and NT4, is the basic provider. It supports number of hashing algorithms such as MD5, symmetric key algorithms such as RC2, RC4, and the Data Encryption Standard (DES), and RSA for an asymmetric key algorithm.
Latest version supports the above, and additionaly includes TripleDES and Rinjael (i.e AES)
Here's my example of using the base services from VB (and which should transfer OK to VBA): thread222-535644
Depends which release you have access to...
CryptoAPI 1.0, released with W95 and NT4, is the basic provider. It supports number of hashing algorithms such as MD5, symmetric key algorithms such as RC2, RC4, and the Data Encryption Standard (DES), and RSA for an asymmetric key algorithm.
Latest version supports the above, and additionaly includes TripleDES and Rinjael (i.e AES)
Here's my example of using the base services from VB (and which should transfer OK to VBA): thread222-535644
Mike - Being as you already have 5 stars in that thread - please allow me to bestow you with one on this thread - most enlightening
Transfers over to VBA just fine - took me all of 2 minutes to set up a working version - needs no extra code or code chopping
Rgds, Geoff
Never test the depth of water with both feet
Help us to help you by reading FAQ222-2244 before you ask a question
Transfers over to VBA just fine - took me all of 2 minutes to set up a working version - needs no extra code or code chopping
Rgds, Geoff
Never test the depth of water with both feet
Help us to help you by reading FAQ222-2244 before you ask a question
strongm,
Got it up and running no probs - thanks! Gave you a star here, too, as Geoff pointed out you're already starred out on the other thread.
>> What encryption does it employ?
> Depends which release you have access to...
Do you mean that Windows automatically choose the encryption method for you, or just that more/different options are available with newer versions? This may cause problems for encrypting one system and decrypting on another.
Is there a way to specify what type of encryption should be used? In particular, I'd be interested in using text displayable versions for use in email etc in addition to binary versions.
Got it up and running no probs - thanks! Gave you a star here, too, as Geoff pointed out you're already starred out on the other thread.
>> What encryption does it employ?
> Depends which release you have access to...
Do you mean that Windows automatically choose the encryption method for you, or just that more/different options are available with newer versions? This may cause problems for encrypting one system and decrypting on another.
Is there a way to specify what type of encryption should be used? In particular, I'd be interested in using text displayable versions for use in email etc in addition to binary versions.
Well thats an interesting discussion
The code sounds very similar to that used by the British during the Second World War.
It was used a currently as 1975 to my knowledge. It was known in two versions
One Time Figure Pad
One Time Letter Pad
The importance of the name is ONE TIME. A sheet was never used twice
It was referenced by the book title....eg A237/459 and by the page, line numbers and character eg 14/3/7
The message was then written out on the actual page and the encryption done
It was decoded at the other end by a book that had the reverse code and the same process applied.
IF a mistake was made another page was used and the message was re-encrypted....
It is thought to be unbreakable without the books....I dont know I just used it and sure did feel safe.
Cheers
Merry Part and the Brightest of Blessings
With respect
Wicca
-----
IF you think you can
Or if you think you can't
Then you are probably right
-Henry Ford
The code sounds very similar to that used by the British during the Second World War.
It was used a currently as 1975 to my knowledge. It was known in two versions
One Time Figure Pad
One Time Letter Pad
The importance of the name is ONE TIME. A sheet was never used twice
It was referenced by the book title....eg A237/459 and by the page, line numbers and character eg 14/3/7
The message was then written out on the actual page and the encryption done
It was decoded at the other end by a book that had the reverse code and the same process applied.
IF a mistake was made another page was used and the message was re-encrypted....
It is thought to be unbreakable without the books....I dont know I just used it and sure did feel safe.
Cheers
Merry Part and the Brightest of Blessings
With respect
Wicca
-----
IF you think you can
Or if you think you can't
Then you are probably right
-Henry Ford
One-time pads are indeed accepted as unbreakable, given the following:
1) each page in the pad is only used once (as you mention)
2) the 'key' on the pad is truly random
The "choose a sequence of characters from a page page from a book/newspaper/whatever" approach is not equivalent to a one-time pad; as has been discussed, it is an example of a Gronsfeld cypher
1) each page in the pad is only used once (as you mention)
2) the 'key' on the pad is truly random
The "choose a sequence of characters from a page page from a book/newspaper/whatever" approach is not equivalent to a one-time pad; as has been discussed, it is an example of a Gronsfeld cypher
strongm,
Thanks for the input. I wouldn't envy the person that's trying to crack an encrypted sheet with that method - a 50 "digit" key where each digit can be one of a hundred different values is a far cry from the little 5-digit key in the example. Still, I'll concede that it appears to be possible, and computers would ease the task considerably. Have a star for showing it could be done!
I'm interested in incorporating one of the built-in encryption methods into my function. I fiddled around for a few minutes with the code you posted in the other thread, but didn't quite manage to get it working right in a normal VBA module (i.e. not on a form). I'll try again today.
Which of the built-in encryption methods would you recommend that I explore for my application? The two important criteria are that it must return a text-only encrypted string (upper/lowercase letters, numbers, and common punctuation), and that the encrypted string should ideally not be longer than the plain-text string (in case the contents of a cell are near the limits of what that cell can hold).
VBAjedi
Thanks for the input. I wouldn't envy the person that's trying to crack an encrypted sheet with that method - a 50 "digit" key where each digit can be one of a hundred different values is a far cry from the little 5-digit key in the example. Still, I'll concede that it appears to be possible, and computers would ease the task considerably. Have a star for showing it could be done!
I'm interested in incorporating one of the built-in encryption methods into my function. I fiddled around for a few minutes with the code you posted in the other thread, but didn't quite manage to get it working right in a normal VBA module (i.e. not on a form). I'll try again today.
Which of the built-in encryption methods would you recommend that I explore for my application? The two important criteria are that it must return a text-only encrypted string (upper/lowercase letters, numbers, and common punctuation), and that the encrypted string should ideally not be longer than the plain-text string (in case the contents of a cell are near the limits of what that cell can hold).
VBAjedi
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question