# Are modified implementations of cryptographic algorithms a good idea?

Are modified implementations of standard cryptographic algorithms better that the standard versions? Since the algorithm is not standard, is it harder to break? Is it safer?

• I'm not getting what you mean by "modified implementations" and "algorithms are not standard" Commented Nov 10, 2014 at 12:50
• "better" is extremely subjective here, "harder to break/safer" is highly dependent on the modification. Commented Nov 10, 2014 at 20:17
• Scarl. I was talking about making subtle modifications to standard algorithms so that they are not standard any more. Commented Nov 10, 2014 at 20:56

No, modified algorithms they are unlikely to be harder to break, unless the changes were explicitly made by a cryptographer to make the algorithm more secure. They are certainly not any safer just because they are different.

• Due to the Kerckhoff principle you should assume that the algorithm is known. So changes in the algorithm in itself does not increase security;
• If there is a trivial change made then all the attacks on the algorithms are still valid;
• If it is a non-trivial change then the algorithm requires a new security description or proof; basically it should be treated as a new algorithm.

Now in the latter case the algorithm could be safer of course, and many parts of the original security proof may hold. There are many algorithms that have been tweaked to a certain extend to make them more safe or more functional, often by their original authors. As example, for SHA-1 the original, untweaked variant called SHA-0 can be found in the wild.

But to change an algorithm without an explicit idea to fix the previous algorithm is not likely to make it more secure. Most of the time the algorithm will be less secure.

Note that even minor changes in the vectors (internal constants) of symmetric algorithms may completely destroy the security of algorithms. Often these tables were specifically created for the purpose of adding security. If you change one constant in there, you may already break security. Other specific constants may be as safe or even slightly more safe (see for example the changes made by the authors to many of the SHA-3 contestants). In other words, small changes may not equate to trivial changes.

If you change for instance the SHA-2 vectors of SHA-256 to a new, secure set, the you may make it harder to use rainbow tables. But if you use SHA-2 correctly then rainbow tables should not be an issue (because of using salt for password based key derivation). In this way, for very specific attack scenarios, using a modified algorithm may bring some localized benefit. But in general it would be wiser to change the key derivation primitive, of course.

• Example: an apparently harmless modification of RC4 (that reportedly was used by a US government agency, most likely unknowingly), turns out to have a serious weakness that's not in the original.
– fgrieu
Commented Nov 10, 2014 at 15:52
• Thanks owlstead. I was not aware that those kinds of changes to the vector tables could be so harmful. Commented Nov 10, 2014 at 21:04
• You're welcome. Be glad that there are standardized building blocks to build your security on. Usually there is no need to change the blocks themselves. Sorry, probably the Lego movie talking :P Commented Nov 10, 2014 at 21:07

Seems to be opinion-based, since there´s a lack of special point (which modification do you want to make?). But similar questions, that asked for specific modifications, get the same answer: in general, by modifying something without knowing specifically what you´re doing, you´ll be making it worst.

Crypto algorithms are designed with specific things in mind, and changing the smallest detail can have bad consequences. For example, the s-boxes used in DES are specifically designed to make them harder. Other combinations made them more suscetible to attacks.

Increasing the number of iterations on hashes (i.e., applying the same hash 1,000 or 5,000 times) seems to increase the security, but not because the algorithm is weak: by making necessary to compute it thousands of times, the brute-force attack would spend more time, just that.

Despite what I'm writing in the next three paragraphs, you should stick to the advice given by owlstead's answer and never make any even small change to a crypto algorithm (like changing the order of steps), even if you are a competent cryptographer (if you are, you probably wouldn't consider modifications except for very good reasons worth a publication).

There are (hopefully rare) cases where changes of the constants in the official standard improve the security of a cryptographic function.

The best known example is the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) that even became an ISO (=international) standard, where the NSA managed to sneak in a backdoor as suspected by Dan Shumow and Niels Ferguson and confirmed by Edward Snowden (for details see the link to the wikipedia).

A second case is the DES where a small change can improve the resistance against linear cryptanalysis considerably (cannot find a reference now). This weakness seems not to be intended and can anyway hardly be used.

Reminder: Anyway stick in your implementation as close to the specification of the standard as possible, and if not possible, get advice on crypto.se.

• 1) The DES link goes to DualEC as well. 2) I wouldn't say that the DualEC backdoor was revealed by snowden, only confirmed. Commented Nov 12, 2014 at 15:17
• @CodesInChaos: Thanks, I adapted my answer accordingly. Unfortunately I misread the paragraph I intended to link to, and I cannot find currently the article about the modification of the DES.
– j.p.
Commented Nov 12, 2014 at 18:33
• fyi, the modification to DES was to simply rearrange the s-boxes in a very specific order (2 4 6 7 3 1 5 8) Commented Nov 14, 2014 at 8:59
• it is behind paywalls, but it was from Eurocrypt 94, "An Improvement of Davies’ Attack on DES", by Eli Biham and Alex Biryukov Commented Dec 3, 2014 at 21:05
• They put the results of the Davies attack paper into a revised version of their earlier paper, cs.technion.ac.il/users/wwwb/cgi-bin/tr-info.cgi?1994/CS/CS0816 Commented Dec 4, 2014 at 10:42