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 g('secret')
if 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 g()
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'))