J
Jon Skeet [C# MVP]
Bonj said:Right, OK. I see what you're saying.
See also inline.
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?
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.
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 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.
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.