Re: How good an encryption algorithm is this?
From: Jon Skeet [C# MVP] (skeet_at_pobox.com)
Date: 11/23/04
- Next message: Jon Skeet [C# MVP]: "Re: Finding subclasses"
- Previous message: Dave Rich: "Getting ListView items in C# from SysListView32 using SendMessage"
- In reply to: Bonj: "Re: How good an encryption algorithm is this?"
- Next in thread: Bonj: "Re: How good an encryption algorithm is this?"
- Reply: Bonj: "Re: How good an encryption algorithm is this?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 23 Nov 2004 17:46:14 -0000
Bonj <Bonj@discussions.microsoft.com> wrote:
> Right, OK. I see what you're saying.
> See also inline.
>
> > I'm thinking that you still don't seem to "get" that other people have
> > done the thinking for you. They've designed plenty of crypto algorithms
> > already. Information on how to encrypt is readily available on the web
> > - there are plenty of samples around.
>
> Not plenty of good ones, though. Check how many home-grown "XOR" ones there
> are on planetsourcecode compared to good, robust, CryptoAPI examples...more
> the former than the latter definitely.
But surely there are enough CryptoAPI examples to help you out, aren't
there?
> > We've *given* you the "why" though - the "why" is "because you aren't
> > trained (as far as we know) in encryption
>
> But that's just it - *as far as you know*.
True, but I suspect most people who *were* trained in encryption would
have understood the reasons given for not trying to come up with your
own algorithm to start with.
> You don't know. How did anyone get good at encryption, how did the
> people that do the "training" get good at it? They have ideas, and
> put them into practice.
I suspect the first thing is to have a very strong mathematical
background, actually - a PhD in discreet maths would be a good starting
point, for instance.
They'd then no doubt read several books on cryptology and cryptography,
and study the standard algorithms, including old ones which have been
broken, in order to see where weaknesses have previously been
discovered.
Using "I think I'll design my own crypto algorithm" is a bad starting
point, IMO.
> What's more, how do the crackers get good at their skill? Probably by
> looking up to other crackers, and analysing how they do their stuff... and
> those higher up crackers are probably more into breaking standard algorithms
> than mine...I'm merely citing the old adage that the small child who plays
> chess against a grandmaster, might just win - due to the fact that he plays
> SO badly, none of the grandmaster's standard theories and gameplans work,
> because they're all designed to work against other gameplans (which the young
> child has no concept of), but still.....
That's really not a good argument in favour of creating your own
algorithm. Just because someone hasn't already studied yours in an
attempt to crack it doesn't mean it's more secure than one which many
highly skilled people *have* studied and failed to find significant
problems with. It just means they haven't looked at yours yet.
> > but haven't looked at yours and are
> > unlikely to".
>
> Again, weak as it is, the point comes back - if they're not likely to look
> at it, how do they crack it?
They crack it when it's worth cracking, rather than now. Do you really
want to only find out whether your algorithm is strong enough when it's
already deployed in the field, and is protecting real-world data?
> > The way I see it, the assertion is "Use standard algorithms rather than
> > designing your own" and the reason (which has been posted several
> > times) is simply "Crypto is hard. You're very unlikely to get it right
> > - even very highly skilled people get it wrong, which is why there's
> > peer review. Standard algorithms have the advantage that they've
> > already been through peer review."
>
> The reason for originally posting was that I had tried to get the standard
> algorithm working, *and failed*. I did try several times on that first. I
> knew my design choice wasn't a good one, but I persisted with it because at
> the time it seemed like my *only* choice, and I had thought that I had
> explained the fact that I couldn't get the CryptoAPI working sufficient.
But why did you wait until you'd made what you could see was a bad
choice before posting, rather than just asking for help with the
CryptoAPI in the first place? It's like starting to design your own
string class because you can't get Substring working - you're far more
likely to get help on standard stuff than you are to get genuinely
expert opinions on your own custom algorithms.
> Igor has very kindly addressed that, and at the end of the day that's
> probably what I'll go with, but since I started out on this tack and
> spent all of a whole hour writing the damn thing, I'll finish.
No-one can stop you, of course - but I'd urge you not to make the
mistake of deciding to actually *use* it at any point, just because
you'll then have it.
> > In what way is that simply repeating the assertion?
>
> Well, no - in light of the above paragraph, it possibly just seemed
> like that - but you have explained yourself sufficiently now and I
> thank you for that.
Goodo - I'm glad we understood each other in the end.
-- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
- Next message: Jon Skeet [C# MVP]: "Re: Finding subclasses"
- Previous message: Dave Rich: "Getting ListView items in C# from SysListView32 using SendMessage"
- In reply to: Bonj: "Re: How good an encryption algorithm is this?"
- Next in thread: Bonj: "Re: How good an encryption algorithm is this?"
- Reply: Bonj: "Re: How good an encryption algorithm is this?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
