Hello Mark,
> I didn't read your code thoroughly, but I think you're dealing with a
> conceptual error here.
[quoted text clipped - 12 lines]
> If switching keys doesn't do the trick, I have some test bench code
> that might help should you need it.
Ok thanks Mark that helps. I understand that I have been using the keys the
wrong way around.
I think this stems from my desire to only have one key in the public and
to transmit the data over public internet.
I would like to use Public-Private key encryption as I do not want someone
who cracks my program to have the ability to create messages.
To encrypt my end and decrypt at the site of my program (in the wild), I
have to use the public key at my end and allow my program to use the private
key to recieve.
This leaves me in the strange position of having to keep my public key private
and publisize my private key. (very wierd indeed)
My problem with this is that the Key XML that I need to supply my program
with in order to use the private key, also includes the details needed to
Create message, ie the public key
ToXMLString(False) - Gives public key only.
ToXMLString(True) - Gives public and Private key details.
Is there not a way to export only the private key.
I have tried manually eliminating the Exponent and Modulus components of
the XML but the resultant xml is not importable for decryption.
And further ideas?
--
Ror
Mark Assousa - 28 Apr 2008 20:36 GMT
> Hello Mark,
>
[quoted text clipped - 42 lines]
>
> And further ideas?
OK, some thoughts in no particular order that may help.
- One of the problems with .Net applications is that, being that
intermediate byte-code stuff, it is inherently easy to reverse-engineer.
There is no way to absolutely hide an encryption key in a .Net assembly.
You can make it pretty darn hard to find though, rather than shipping
the XML as a data file along with the application, make it an embedded
resource and get a StreamReader like so (sorry about the formatting):
myAssembly = System.Reflection.Assembly.GetExecutingAssembly()
s = New StreamReader(
myAssembly.GetManifestResourceStream(myAssembly.GetName().Name & "." &
ResourceName))
- Most applications I develop that require encryption have a default
encryption setup used only for encrypting and decrypting keys. I then
have a mechanism for loading new encryption keys as needed. So maybe you
could change the encryption keys periodically?
- Use digital signatures. In this case, there's a "magic cookie" inside
the encrypted data file that is itself a product of encryption that's
hard to forge and the application can use to verify the data is from you
and not the Evil Mr. X. Look in the System.Security.Cryptography.DSA
namespace.
- Get "Programming .Net Security" by Adam Freeman & Allen Jones,
available at O'Reilly Press. It tells everything I've forgotten about
encryption and then some.
I think that about sums up my wisdom on the topic unless you need that
test code. Good luck.
Rory Becker - 07 May 2008 11:37 GMT
Hello Mark,
> OK, some thoughts in no particular order that may help.
>
[quoted text clipped - 27 lines]
> I think that about sums up my wisdom on the topic unless you need that
> test code. Good luck.
Thanks very much.
I think I will end up using a combination of encryption and signing to meet
my needs.
Thanks again
--
Rory