Re: How good an encryption algorithm is this?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Bonj (Bonj_at_discussions.microsoft.com)
Date: 11/25/04 

Date: Thu, 25 Nov 2004 07:49:02 -0800

That's a good explanation, thanks.

"Ian Griffiths [C# MVP]" wrote:

> Igor wrote:
> >> No encryption algorithm worth its salt would consistently encrypt
> >> the same byte to the same value.
>
> "Bonj" replied:
> >
> > Do you reckon that, albeit not the be all and end all, but that if I
> > achieve that, then it's a big step forward in the right direction?
>
> Only marginally. It's a bare minimum requirement, but it's very easy to
> demonstrate algorithms that meet this requirement and yet are still
> completely unsecure. So having this property is unfortunately not really a
> strong indicator of the quality of the algorithm.
>
> With respect to your particular algorithm, you seem to want actual concrete
> proof that it's of no use, so here goes... There's problem with your
> algorithm that is related to the problem above.
>
> Even if a given input byte doesn't necessarily produce the same output byte
> every time, it's also bad if a given input byte in a given input position
> always encrypts to the same output byte. (Indeed these are effectively just
> the same problem on different scales.) With a robust encryption system,
> changes in one byte position in the input tend to have a much more
> widespread effect in the output. Without this property, then all sorts of
> attacks become quite simple - you can do the same kind of statistical
> analysis that has already been discussed for each byte offset. Obviously
> this takes longer than with a simple one byte substitution, but it's still a
> major weakness, which is why you'll never see a serious encryption algorithm
> that has this problem.
>
> And I'm afraid your code suffers from this problem.
>
> To illustrate why, let me point out something about your approach. You've
> actually made your algorithm look a lot more complex than it really is.
> Your Encrypt routine really does nothing more than XOR with the same
> repeating 256 byte pattern every time. You'll find that if you call your
> Encrypt function like this:
>
> BYTE cheat[256];
> BYTE zero[256];
> ZeroMemory(zero, 256);
> Encrypt((_TCHAR*)zero, 256, cheat);
>
> the 'cheat' array will now contain the 256 byte repeating pattern that you
> XOR all your input with. You can now just use a much simpler routine:
>
> for (int i = 0; i < dataByteCount; ++i)
> {
> data[i] ^= cheat[i % 256];
> }
>
> This is effectively equivalent to both your Encrypt and Decrypt routine. I
> was able to take the byte buffer generated by your Encrypt routine and
> recover the original string data this way. And looking at this code it's
> very obvious what's being done to the data.
>
> Your code makes it look like you're doing something more complex than you
> really are, because you are using a roundabout way of choosing the repeating
> 256 byte pattern that you XOR the data with - you're deriving it from the
> input keys rather than using them directly. But this roundabout derivation
> doesn't add any security - cryptanalysis techniques that can be brought to
> bear on repeating XOR patterns will work just fine regardless of how the bit
> pattern was generated - it's the fact that it repeats that is important.
> (Indeed your code might even be less secure than simply XORing against one
> of the 256 byte input keys - it is possible that your munging introduces
> patterns or statistical artifacts into the bit patterns that could be
> exploited to make the attack more efficient.) Data encrypted this way can
> be analyzed using exactly the same statistical techniques as can be used
> with single byte substitution. It will take a little longer to do, but this
> is ultimately a very unsecure encryption system. You would be a whole lot
> better off with any of the encryption algorithms offered by the Crypto API.
>
> (Also, a chosen plaintext attack would allow the attacker to get enough
> information to decrypt *everything* in just one go. For example, my code
> above to generate the 'cheat' block was a chosen plaintext attack, where my
> chosen plaintext is all zeroes. But it happens to work for any 256 byte
> chosen plaintext. And since you're talking about encrypting people's
> passwords, then presumably I get to choose the plaintext - it's my password.
> All I need to do is enter a 256 byte password, look at what you encrypt that
> to, XOR it with my original password, and I've now got the 256 byte pattern
> you're XORing everything with. I can now decrypt any password you encrypt.)
>
> I'm by no means a crypto expert by the way, but it only takes the most basic
> understanding of cryptanalysis to know that a simple repeating 256 byte XOR
> is easily attacked. I'm afraid I have to agree with everyone who has been
> telling you that encryption systems devised by people who don't know
> anything about encryption tend to be utterly unsecure. Possibly you don't
> believe this yet, because you think that if you keep working at it you'll
> get there eventually. And maybe you will, but I'm not sure you'll get there
> without learning a lot more about crytpanalysis - pretty much every
> successful encryption algorithm has learned from the attacks made on older
> algorithms. And if you do this learning, you'll discover just how many
> people have tried before you to roll their own brand new systems, only to
> fail to come up with anything useful. And you'll also learn why it is that
> so many people have told you not to bother trying to roll your own
> encryption algorithm...
>
> Of course there may well be utterly novel new ways of doing encryption as
> yet undiscovered. But historically, it looks like the odds are against you.
> And I still think it's insane to try and invent your own in the hope that
> you'll hit upon a new technique rather than relying on tried and tested
> techniques.
>
>
> --
> Ian Griffiths - http://www.interact-sw.co.uk/iangblog/
> DevelopMentor - http://www.develop.com/
>
>
>

Relevant Pages

  • Re: dm-crypt, new IV and standards
    ... > Please focus your recommendations on security, ... This will slow down the encryption process ... The hash algorithm: Hash ... If an attack requires 1 day to iterate though all 8 alphanumeric passwords, ...
    (Linux-Kernel)
  • Re: New Encryption Idea
    ... performing the 5 reads necessary in the example algorithm results in a delay ... Panama at 400MB/sec, or RC4 at about 90MB/sec, or AES in CTR mode at ... and the speed failings of your design become very clear. ... > Manansala Encryption and Authentication System ...
    (sci.crypt)
  • Meganets "unbreakable" cryptography? Im skeptical.
    ... Meganet makes such grandiose claims that I can't help but ... There's plenty of coverage on secret encryption algorithms ... encryption algorithm that was granted U.S. Patent ... Labor has bought into this "snake oil" and without a doubt ...
    (sci.crypt)
  • Re: How good an encryption algorithm is this?
    ... strong indicator of the quality of the algorithm. ... With a robust encryption system, ... repeating 256 byte pattern every time. ... a chosen plaintext attack would allow the attacker to get enough ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How good an encryption algorithm is this?
    ... strong indicator of the quality of the algorithm. ... With a robust encryption system, ... repeating 256 byte pattern every time. ... a chosen plaintext attack would allow the attacker to get enough ...
    (microsoft.public.vc.language)