By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,760 Members | 1,585 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,760 IT Pros & Developers. It's quick & easy.

Encryption: can't someone use a memory viewing program to see my k

P: n/a
I have been working with encryption. And it seems to me that the IV and Key
are the only things you need to decrypt my data.

I can obfuscate, but my program still needs to 'call' the framework objects
in System.Security.Cryptography. And this call can be searched for. Then
using a program like SoftIce or Heapwalker they can examine the object and
its properties (namely the IV and Key). Having that they can break my
encryption.

Am I missing something?

Even if I slice and dice the key and store it all over the place, it needs
to be assembled before the framework call, right?

Thanks,

Bob
Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
B Maxey wrote:
I have been working with encryption. And it seems to me that the IV and Key
are the only things you need to decrypt my data.

I can obfuscate, but my program still needs to 'call' the framework objects
in System.Security.Cryptography. And this call can be searched for. Then
using a program like SoftIce or Heapwalker they can examine the object and
its properties (namely the IV and Key). Having that they can break my
encryption.

Am I missing something?

Even if I slice and dice the key and store it all over the place, it needs
to be assembled before the framework call, right?

Thanks,

Bob


You don't want to store the key any longer than you have to. Ask the
user for the key (by typing it in, reading a file, or whatever), use it
to encrypt/decrypt the data, then quickly erase it from memory.

It would utterly defeat the purpose of symmetric encryption to store the
key somewhere in the file. You might look into assymetric encryption
for that, but then again, I'm not too sure what you are trying to do.

John
Nov 17 '05 #2

P: n/a
Hi Bob,

Welcome to MSDN newsgroup.
As for the question about encryption info in assembly file you mentioned, I
think you're right. The KEY /IV pair is used for the symmetric encryption
algorithm. If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication. In
addition, in some network tranfering scenario, the key/iv pair for
symmetric entryption are all dynamically generated at runtime and will
expire after a certain period ( such as the SSL ).

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Nov 17 '05 #3

P: n/a
Steven Cheng[MSFT] wrote:
If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.


I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John
Nov 17 '05 #4

P: n/a
I'm trying to think of some way to provide some level of copy protection
without paying $3 per license. My software cost will be more like expensive
shareware and the expensive copy protection is beyond my budget.

I asked becuse I feared the answers you guys are giving me.

So, now I am thinking more of the hashcode approach.

Thanks,

Bob

"John Davison" wrote:
Steven Cheng[MSFT] wrote:
If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.


I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John

Nov 17 '05 #5

P: n/a
B Maxey wrote:
I'm trying to think of some way to provide some level of copy protection
without paying $3 per license. My software cost will be more like expensive
shareware and the expensive copy protection is beyond my budget.

I asked becuse I feared the answers you guys are giving me.

So, now I am thinking more of the hashcode approach.

Thanks,

Bob

"John Davison" wrote:

Steven Cheng[MSFT] wrote:

If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.


I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John


Bob,

There is no such thing as true copy protection.

John
Nov 17 '05 #6

P: n/a
And I thought the news about Santa Clause was the last traumatic event of my
life!!

"John Davison" wrote:
B Maxey wrote:
I'm trying to think of some way to provide some level of copy protection
without paying $3 per license. My software cost will be more like expensive
shareware and the expensive copy protection is beyond my budget.

I asked becuse I feared the answers you guys are giving me.

So, now I am thinking more of the hashcode approach.

Thanks,

Bob

"John Davison" wrote:

Steven Cheng[MSFT] wrote:
If both of them are stored in your application's executable file
or assemly only, it is surely possible that some cracker will decrypte your
key info from your assembly or executable. So generally we'll separate the
keyinfo from our encryption program , for example, store in registry key or
database which can be protected by Access control or authentication.

I'm not sure what the point of this would be. The program will still
need to read the key, be it from the assembly, registry or database. If
credentials are required without user intervention, those credentials
will still need to be stored somewhere, which defeats the purpose. If
user intervention is required, then why not just ask for the password to
decrypt the key?

If the point of the encryption is to prevent the user of the software
from accessing files distributed with the application, then the original
poster needs to say so and realize the futility of it.

John


Bob,

There is no such thing as true copy protection.

John

Nov 17 '05 #7

P: n/a
Hi Bob,

Thanks for the followup.
Don't be too worry, since there is actually no 100% secured
system/application, what we need to do is just providing security
protection as much as possible. If anyone keep interesting in your program,
there is no perfect means to prevent them as long as our application is
deployed at clientside. How do you think so?

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.