Some of the BouncyCastle methods take a Digest as input. According to http://en.wikipedia.org/wiki/Cryptographic_hash_function#Hash_functions_based_on_block_ciphers and http://www.mindrot.org/projects/jBCrypt/ it should be possible to use a block cipher as a hash function.
So does that mean that it should be possible to use any of the JCE ciphers (such as Blowfish) as a Digest?
You cannot use a block cipher as a hash function; you can, if you are a cryptographer, design a hash function out of a block cipher, which means that the block cipher will be an important element within the hash function -- important, but not alone. You need more.
(Analogy: a car can be powered by an engine -- and often is. However, there is more to a car than an engine, and there are a lot of ways to build a car around an engine. Many such ways are bad, too, and won't result in a safe, efficient or beautiful car.)
Related
I'm trying to optimize my signature and verification scheme for an embedded device and I'm finding race conditions at just 0.5s/verification. Instead of making the device compute the SHA-256 hash of the data, could I just use an AES encryption and sign that with PSS to accelerate the process, or does it need to be a hashing algorithm?
If you’re asking if the concept could work: sure. You could pigeon hole the tag as a 128-bit hash output and, provided you’re calling API that accepts the pre-computed hash everything would work (provided you told the PSS operations they were using a 128 but hash algorithm).
But no one else would be able to verify your signature, because that’s not a predefined way of doing RSASSA-PSS. And you’d have a “public only” verification problem… the only way someone can know if the tag matched the data was to also have the encryption key, so you would have to embed the key and nonce in the signature parameters (a really bad idea) or just be a private/application protocol.
So, it could be done, but it won’t interoperate, and it’s almost guaranteed never to be a standard because it can’t be used by implementations that don’t accept pre-computed hashes (without forcing the scheme to plaintext transport the content encryption key).
In general, RSA-PSS requires a hash algorithm for the mask generation function and other operations, so it's doubtful that you could actually make RSA-PSS work in any functional way with something that is not a hash algorithm.
The idea you're proposing is also likely insecure, so even if you could get it to work, it wouldn't be effective as a signature scheme, since it could probably be forged. That's because AES, unlike a hash function, allows users to invert the operation (that is, decrypt), so an attacker who knows the key (which, if you hard-code it, they do) can likely create arbitrary messages to sign.
For a secure digital signature, you really need a secure hash algorithm, which means that you need something like SHA-2, SHA-3, or similar (MD5 and SHA-1 are not secure and should not be used). If possible, I would investigate a possibly more performant SHA-256 implementation here. You could also try the hash algorithm BLAKE2s, which is both cryptographically secure and much faster in software than SHA-256, and may meet your needs better.
I'm taking cryptography course on cousera.
When I'm reading the lecture slides, it says
Encryption algorithm is publicly known
• Never use a proprietary cipher
What does "Never use a proprietary cipher" mean?
Thanks
Never use a proprietary cipher
It means - Never use a proprietary cipher!
The idea behind is - until a cipher is adopted as a standard, the cipher goes through mathematical elaboration, proofs, validation, ... and then a lot of smart people say it's ok to use the cipher to some extends or expected lifetime.
Almost all current battle-proven ciphers went this way (AES, RC4, DES, 3DES, ...). We know (or we think we know) their real strength and their weaknesses.
When creating a proprietary cipher - everybody could create a cipher which himself won't be able to break. However - are you able to validate, if the cipher is resistant to modern cryptoanalytical methods or side-channel attacks?
Using a cipher which is "proprietary", where the algorithm is not know, most probably the cipher can be broken and the cipher is not to be considered as secure. Stick to the industrial standards.
Proprietary ciphers go through much less rigorous testing than public ciphers do
As there have been significant advances in the cryptoanalysis of SHA1 it's supposed to be phased out in favor of SHA2 (wikipedia).
For use as underlying hash function in PBKDF2, however, it's basically used as a PRNG. As such it should be still secure to use SHA1 as hash for PBKDF2, right?
None of the currently known weaknesses on SHA-1 has any impact on its security when used in HMAC, a fortiori when used in PBKDF2. For that matter, MD5 would be fine too (but not MD4).
However, SHA-1 is not good for public relations: if, in 2011, you use SHA-1, then you must prepare yourself to have to justify that choice. On the other hand, SHA-256 is a fine "default function" and nobody will question it.
There is no performance issue in PBKDF2 (PBKDF2 includes an "iteration count" meant to make it exactly as slow as needed) so there is very little reason to prefer SHA-1 over SHA-256 here. However, if you have an existing, deployed system which uses PBKDF2-with-SHA-1, then there is no immediate need to "fix" it.
Sure. SHA-256, or larger, might be more efficient if you want to generate more key material.
But PBKDF2-HMAC-SHA1 is fine. Also standard HMAC use has not been compromised, but again, longer hashes are in principle more secure in that scenario.
The attacks on SHA1 which caused a lot of public turmoil make it possible to construct a message which has the same hash as a different message. This is of course always possible (in principle) for every hash function, since a hash function has fewer output bits than input bits. However, it is normally not likely to happen by accident, and doing it on purpose should be computationally not feasible.
From a "ensure message integrity" point of view, this can be seen as a disaster.
On the other hand, for the purpose of generating random numbers, this has absolutely no bearing.
For a homework assignment, I am asked to determine the algorithm used to generate a given cipher text. The key is also given. Currently, I am working down a list of simple encryption algorithms and semi-blindly testing different decryption arrangements in an attempt at retrieving the given plain text.
Is there a better way to go about this process? I've read pages of Google results on the topic and haven't come across anything that explained a better process than what I'm already doing. Thus far I've run multiple levels of linguistical analysis upon the cipher text and am trying to plug in logical values into the encrypted message to decrypt it.
This is built around basic cryptographic systems, nothing at the level of public key encryption or DES.
Even if I can get the original message, how will that show the encryption scheme that was used?
My answer would be there is nothing wrong with trying various different algorithms out and seeing what works.
Cryptanalysis is like solving a puzzle, not a step by step process. You try things, you see what works, what you think gets you closer. It is absolutely trial and error based on knowledge of the potential algorithms, patterns and techniques and the reasons for them. Differential cryptanalysis, a modern technique, basically amounts to trying various combinations of keys and plaintexts within an algorithm and looking at the differences to see if you can find patterns.
From your comments, I think you're facing a vigenere cipher or some similar variant thereof. In this case, the key is important because essentially a vigenere cipher is a set of caesar ciphers and the length of the key determines the number of these ciphers. Now, the rules of the scheme in question will tell you exactly what cipher it is, but that's the basis of it.
The Skein hash proposed for SHA-3 boasts some impressive speed results, which I suspect would be applicable for the Threefish block cipher at its heart - but, if Skein is approved for SHA-3, would this imply that Threefish is considered secure as well? That is, would any vulnerability in Threefish imply a vulnerability in SHA-3? (and thus, a lack of known issues and a general trust in SHA-3 imply the same for Threefish)
Nope. The security of Skein does not imply the security of Threefish. Putting it positively, if someone finds a weakness in Threefish then this does not imply that Skein is also insecure.
The question however, is quite intersting an applies to other hash functions too.
Skein uses a Davis-Meyer construction with some modification. MD5, SHA1 and many other hash functions are also using this Davis-Meyer construction and hence they are in principle based on a block cipher. Just in case of MD5 or SHA1 that block cipher does not have a name and I'm not aware of much research on how suitable these constructs are.
The requirements for a good block cipher and for a good hash function are different. Somewhat simplified, if E is a block cipher and it is not feasible to find two keys K, K' and two messages M, M' such that EK(M) xor M = EK'(M') xor M' then E is suitable for constructing a hash function using Davis-Meyer. But to be secure as a block cipher E would need other properties. E would have to resist chosen-ciphertext attacks, chosen-plaintext attacks etc.
Furthermore, if E is a good block cipher then that does also not mean it gives a good hash function. Microsoft had to learn this the hard way with the hash they used in the XBOX. This hash was based on the block cipher TEA that had a weakness that was insignificant for a block cipher, but proved fatal when used for a hash function.
To be fair, there are some relations between being a good block cipher and being suitable for a hash function. E.g., in both cases differential attacks need to be avoided. Hence some design methods used for construction good block ciphers can be used to construct good hash functions.
Let me also add that some of the proposals for SHA-3 are based on AES. So far, I haven't seen much support for favoring AES based hash functions, just because AES is already a standard. These hash functions are analyzed just like any other SHA-3 proposal.
Disregard my previous answer. I misunderstood the relationship between Skein and Threefish. I still don't think Skein being approved absolutely proves Threefish is generally secure (it's possible Threefish is only secure when used in a particular manner), but it would be an indication.