Home brewed cryptography is strongly discouraged because it is so easy to get it wrong.
Even if we leverage a known good hash function, one example, sha256, here by referred to as
g() and use it in conjunction with a home-brew function
b(), we can reduce our security because we have reduced our entropy; example:
g(b('secret')) will be less secure than just
b() is collision prone.
Proving (I am not using prove in the strictest mathematical sense) a hash function is more secure than another is a herculean task that requires a lot of time from cryptography experts, and is beyond the scope of this question.
However, let's say no crypto-hash function that suits my needs currently implemented on my platform so I want to home-brew. If I am okay with worse performance, ect, and simply want to ensure it is not less secure than a known good function
g() it leverages extensively.
For example, if we define
b() to be
g(g(g(g(g(g(g(g(g('secret'))))))))) we know that
b() is not less secure than
Are there a set of quick set of guidelines that can be leveraged to ensure a derivative home-brew function is not less secure than the function it uses?
One example function
b() might look something like this where it mainly uses a propriety logic as salt for
g() (please do not think that this is intended as a replacement for random salt!!):
b() is defined as
g('secret' + b1('secret'))