Re: Decompiler.NET reverse engineers your CLS compliant code

From: Robert Jordan (robertj_at_gmx.net)
Date: 10/01/04 

Date: Fri, 01 Oct 2004 02:48:23 +0200

Hi Richard,

> If you could send the assembly to MSFT to get signed with their private key then only the public key woul dneed to ship with the CLR. I thought thats what you suggested with hte Microsoft Remoting encrytping service.

Supposing the MSFT public key is really "public",
then everybody would be able to unencrypt the assembly, isn't it?
I thought we wanted to prevent that.

bye
Rob

>
> Regards
>
> Richard Blewett - DevelopMentor
> http://staff.develop.com/richardb/weblog
>
> nntp://news.microsoft.com/microsoft.public.dotnet.framework/>
>
> Hi Richard,
>
> > if it used an asymetric algorithm (encryption key <> decryption key) then the CLR would only need the decryption key so it wouldn't be a problem as that is how PPK encryption works now (or one flavour of it) everyone has the decryption key only one party can encrypt. However, with this prize a cherry on offer it would be brute forced very quickly I would assume (you could get loads of samples to base your brute force on my submitting loads of assemblies to be signed)
>
> I *thought* about asymetric encryption but did't wrote it ;-)
>
> - the assembly gets encrypted with my private key and with MS public key
> - my public key gets attached to the assembly
> - the CLR unencrypts the assembly using my public key and
> the MS private key, which has to be deployed with every
> CLR, right?
>
> I was talking about that MS private key. No way to secure it.
>
> thanks
>
> bye
> Rob
>
> >
> > Regards
> >
> > Richard Blewett - DevelopMentor
> > http://staff.develop.com/richardb/weblog
> >
> > nntp://news.microsoft.com/microsoft.public.dotnet.framework/>
> >
> > Hi William,
> >
> > > Just a random thought...
> > > Forget about obfuscators for one minute. What are some other ideas on
> > > protecting code that would work with the CLR (or not) to protect your code
> > > so it could not be decompiled? I had thought at one time that some kind of
> > > encryption may work with the clr the only thing that could unencrypt it.
> >
> > This shouldn't be a big problem, but since all assemblies will be
> > encrypted with the same key(s) (otherwise the CLR wouldn't be able
> > to unencrypt them), I bet the key(s) will be cracked within days.
> >
> > Even when those assemblies were encrypted by MS (using some
> > fancy Remoting Crypting Service(TM) ;-), the CLR or the OS must
> > contain the decryption keys somewhere.
> >
> > It's not worthwhile.
> >
> > bye
> > Rob
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004
> >
> >
> >
> > [microsoft.public.dotnet.framework]
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.770 / Virus Database: 517 - Release Date: 27/09/2004
>
>
>
> [microsoft.public.dotnet.framework]

Relevant Pages