Comment Re:links to NIST (Score 1) 134
Follow this simple rule: don't invent your own crypto. And that goes double for protocols. It's hard. I mean, really, really hard to get it right. If you are not an expert, then there are almost certainly known attacks which will undermine the security of your entire system. If you are an expert, there are still probably subtle attacks (but fewer of them which may not be discovered for years).
I understand most standard modern crypto and protocols quite well. I have studied and worked with it long enough to recognise that using tried and tested methods is almost always the right thing to do. I am not an expert, but I am hopefully a reasonable practitioner.
With that disclaimer out of the way, you need to identify what security you are trying to achieve first, before tacking on cryptographic primitives left right and center. You seem to want message confidentiality and message authentication. For confidentiality with message authentication, use standard constructions. Preferably use an authenticated encryption mode, which has the advantage that they can take less message space than the old style encrypt-then-HMAC constructions, and are usually faster than doing either separately. And you typically only need a single key. If you use the encrypt-then-MAC construction, don't use the same key for encryption as you do for MACing.
Does confidentiality extend to the attacker knowing whether he has seen the same encrypted plaintext before? I.e. should the same plaintext always encrypt to a different ciphertext, or are you happy for the same ciphertext to always be produced for the same plaintext? Do you care about replay attacks? What happens if an attacker replays an old message? Message counters or timestamps can help here. What about non-repudiation? Does it matter whether you can prove which side generated the message or not? For payments, this might be important.
This only scratches the surface. Get proper advice to analyse the true security requirements of your protocol, and use standardised constructions in the implementation. Use BLAKE by all means if it fits the security you need to achieve and performance is a primary requirement. But figure out what security you need first.