Replace the rust-crypto crate to other crates

[somniumism]

The rust-crypto@2.3.6 crate that we are using now is unaudited and has not received a commit since 2016. We are still unknown whether there are any vulnerabilities offhand. But if there are ones, they will never receive fixes. Thus, we think that it is necessary to completely replace the rust-crypto crate to other crypto crates.

I replaced hash in the rust-crypto crate to other crates(sha-1, sha2, sha3, ripemd160 and digest), and blake2 in the rust-crypto crate to blake2 crate. And I'm working on replacing aes and block mode to other crates(block-modes, aes, aes-soft).

I think there are unnecessary and dirty codes, so I need your review to modify them.

[sgkim126]

The first and second commit looks good to be merged.
How about splitting the PR?

[somniumism]

@sgkim126 For the time being, I'm waiting for @HoOngEe's review. And I think it's fine to split the PR. By the way, if there is a special reason for doing it, could you tell me the reason?

[sgkim126]

The 4th commit seems to take more time to be implemented.
If you can implement it before long, I think splitting is not necessary.

[somniumism]

I'll try to complete the 4th commit within today. If I can't finish it by today, I'll split it up.

[HoOngEe]

It looks good to me up to the 3rd commit. I'll review the fourth when you finish it.

[somniumism]

@sgkim126 @HoOngEe I replaced crates related to aes-256-cbc to other crates. I'm waiting for your review. : )

There are still two parts left to be fixed: 1) ctr mode, and 2) error handling.
To solve 1) ctr mode, I used the ctr crate. However, there seems to be no way to make encryption and decoding by dividing them into two functions. This crate is designed to allow decryption only if the object cipher = Aes128Ctr::new(&key, &nonce) is shared. The object can be created in the encryption process, and when divided into two functions, it is difficult to convey the object to the decryption function. Unfortunately, existing crates may still need to be used. How about it?

And I don't know how to solve 2) error handling. To be exact, I don't understand our error handling structure, and roles of ScryptError, ring::error::Unspecified and SymmetricCipherError. So, I need your advice.

If the third and forth commit looks good to be merged too, I'll split it up.

[sgkim126]

It seems that there is no test to check whether the encrypted result has been changed.
Please add tests like

rust-codechain-crypto/src/blake.rs

Line 108 in 0e2cc25

assert_eq!(H128::from("46fb7408d4f285228f4af516ea25851b"), result);

.

[HoOngEe]

I checked the functions in ctr crate. We can implement encryption and decryption using apply_keystream method in SyncStreamCipher trait. However I still cannot understand why ctr does not provide StreamCipher methods. I think it still remains unimplemented.

[somniumism]

@sgkim126 @HoOngEe I replaced crates related to the aes-128-ctr mode to other crates, and I made a commit combined two commits, replacing the 256-cbc mode and replacing the 128-ctr mode. I need your review : )

I'm working on replacing scrypt mode to other crates, and I have a problem. The function scrypt()'s output format is Result<(), InvalidOutputLen>, so it seems it needs error handling. but I don't know how to solve it.

[somniumism]

I replaced all modules in the rust-crypto crate to other crates. I removed completely the rust-crypto crate from Crago.toml. Therefore, from now on, we don't use the rust-crypto crate.

@sgkim126 @HoOngEe Could you review this PR?

[HoOngEe]

LGTM