# Tag Info

PHP 5+, two hash(sha256, $key)? If you try this: \$key = \$String1.\$String2.\$String3.\$String4.\$NumFloat."1234"."456"."Test".\$StringA.\$StringB; echo \$key; \$key = "\$String1\$String2\$String3\$String4\$NumFloat"."1234"."456"."Test".\$StringA.\$StringB; echo \$key; everything ... 0 You should not send salt to the front end. Send only the hash. After the "game" completed, e.g. after the front end has done 20 attempts you named, you should present the right answer and the salt. Thus every participant can check that the hash you presented at the beginning really matches the message and the salt. And the cryptographic properties ... 0 Digging the RFC 8017 9.2. EMSA-PKCS1-v1_5 For the nine hash functions mentioned in Appendix B.1, the DER encoding T of the DigestInfo value is equal to the following: and A.2.4. RSASSA-PKCS-v1_5 The object identifier for RSASSA-PKCS1-v1_5 SHALL be one of the following. Both combined below; Hash algorithm OID the DER encoding ... 3 Using SHA-256 or SHA-512 as a substitute for a proper purposefully-slow password-hash is broken for shortish (10-12 character) passwords. Try it with the SHA-256 of test123456 encoded per UTF-8. Even Google finds it! Rainbow tables allow a relatively compact yet efficiently searchable storage of the precomputations. That way of using a hash is just a bad use ... 5 SHA-256 and SHA-512 were designed to be very fast. Their primary goal ist to verify the integrity of long messages or files. Long means not 10-12 bytes but some megabytes and greater. It is not a good idea, to use hash function that is fast by design for password hashing. Instead, for password hashing should be used functions that need essentially more ... 4 When we state that "SHA-256/SHA-512" hasn't been broken, what we mean is that the three security properties of hash functions haven't been violated. Those properties are: Preimage resistance; given a hash, value, it is hard to find a string that hashes to that value. Second preimage resistance; given a message, it is hard to find a second ... 1 If the only change you make is removing the hashing step, things certainly fall apart. Using the description from Wikipedia you used in your question, this would mean to replace the first step with$e := m$and then continue with the rest of the steps unchanged. The second step would then define$z$as the$L_n$leftmost bits of$m$. Thus, any messages that ... 2 The truthful answer here is that I don't know. I am pretty sure actually that the better answer is that this is unknown. The assumption that the hash is only required for collision resistance is blatantly false, since typically one needs a random oracle for such schemes. In ECDSA specifically, we don't have actually have proof of security even with a random ... 1 I will first address the issues of the diagram; Encryption part Although the encryption is mentioned as optional there is no mention of how the AES key is generated. The common method is the Diffie-Hellman Key Exchange and the Elliptic Curve version of it is preferred ECDH. there is no mention of the mode of operation. CBC, CTR, GCM,... etc. There is no ... 0 Or will anything go wrong with the scheme I describe above? Is the AES key public? If it is, then it is easy to generate two messages that have the same tag (and hence would act like a collision). If the AES key secret to both the signer and the verifier? If it is, well, why bother with ECDSA at all; if you have a shared secret key, you can use a Message ... 1 Analysis of the C code is off-topic. It outputs a string of SALTSIZE=32 characters each obtained by indexing a string of 64 base-characters encoded in ASCII as a single byte. The indexes are obtained according to the low-order$4\times6$bits of what seems to a pseudo-random 32-bit value produced by arc4random(). Thus the output is a 32-byte bytestring (not ... 2 The question as initially asked essentially considers a 64-bit symmetric Feistel cipher with 16 rounds, a large (128-bit) key, a near-ideal round function, but the same function and key at each round. A slide attack allows at least a distinguisher, I think with in the order of$2^{31}$queries to an encryption oracle. With some more, it might be possible to ... 0 Mining ASIC's is not suitable for SHA256 brute-force/rainbow tables, they fixed by initial silicon design only for bitcoin double-sha256 mining. They drop 10^9 non-suitable hashes internally (even dropping not finished rounds), just to provide 1 per fix matching criteria hash should start from 0x0000000000xxx the only suitable solution for final block ... 1 (1) Yes, it would be a concern. Once upon a time, Dropbox did this. When synchronizing the files, it checked the hashes before uploading. Thus, if the file was already in their servers, they just linked it and the transfer was instantaneous. Then people started using it for sharing content. By having the hash of e.g. a movie, they could "claim" to ... 1 It's indeed a genuine concern. How to fight this? Well, once client had provided the SHA256 hash of the file (to quickly index the file on the server), your server then provide a random one-time key and ask the client to hash the file again with HMAC and the key. Since the key is one-time and random, adversaries have little chance at guessing the key and ... 3 The other answers did not mention the Length-Extension attacks on the Merkle–Damgård construction. Length extension is given a hash value$h$; $$h = \operatorname{SHA-256}(\text{IV},\text{secret_key}\mathbin\|\text{known_data}\mathbin\|pad1)$$ the attackers can produce an extension as;$\$\operatorname{SHA-256}(\text{IV},\text{secret_key}\mathbin\|\text{...