Tag Info

New answers tagged

1

There are a few pitfalls: File name integrity: signing files one at a time signs the contents of the files. It (typically) does not protect the file names from tampering. This could be disastrous in some situations (e.g. an attacker could change blacklist.txt to whitelist.txt). Set membership integrity: signing individual files does not prevent adding or ...


-1

No pitfalls I can see except that you may run into missing files more than you would if you chose to sign them individually. One negligible drawback is speed: you'd be forced to calculate one hash more for the verification step than if you did it separately. The I biggest is probably compatibility. There is no standard way of hashing multiple files in a ...


1

There is no out of the box tester which can tell you what you need, you need to do research. I'm having the same 'problem'. I'm doing an internship for a company which wants to protect their self-created protocol which works on top of TCP. So to tackle this I've create a plan of approach and defined my research parameters (quite broadly). Now i'm looking ...


1

Encryption & Decryption: It increases the messages secrecy. Sender encrypts the plain text using a secret Key and sends it(cipher text) to receiver. Then the receiver receives the cipher text and decrypt it using the same secret key. The secret key should be shared between the sender and receiver. Hashing: It ensures the integrity of a message (which ...


0

This question is more or less completely answered on one of our favorite sites for information. For algorithm-specific questions (when was it invented, vulnerabilities, etc.), just click on the specific hashing algorithm on that page. "What is it best for" - all hashing algorithms are designed to be a one-way function, and all encryption algorithm are ...


1

The fundamental difference between hash and encryption techniques is that hash is irreversible while encryption is reversible. Hash algorithms generate a digest of fixed length output cipher text for a given input plain text. The output text cannot be converted back to input text. The generated output will always be same for a given input plain text that ...


13

The echo command appends a new line at the end, by default. The -n option omits this character. Compare these two executions: > echo -n "test123" | md5sum cc03e747a6afbbcbf8be7668acfebee5 > echo "test123" | md5sum 4a251a2ef9bbf4ccc35f97aba2c9cbda So the difference between the hash values is simply caused by the new line character.


1

What defining the digest as part of the API does is allow the device to be a completely self-contained cryptographic system. This system can then be tested as a unit -- if you did, say, hashes on the client side, you would have to ensure that the hash implementation was secure for each and every new implementation. By putting everything in one module, you ...


0

It is generally true people choose weak passwords, and it is certainly true there are gigabytes of publicly available rainbow tables chock-full of hashed values representing them. So when somebody creates an account on your service and selects a password to secure their identity, you can typically bet the password they choose will be 1) common, 2) unsecure ...


0

I've got the inkling of a feeling that using the plaintext to derive the next key is not CPA secure. One of the attacks to test a cipher is to have the attacker choose the plaintext. Your scheme will obviously fail this test. OTP is a theoretical construction. As it is hard to derive a truly random key stream (of the same length of the plaintext) we usually ...


4

Not as secure as a one time pad. A key concept with one time pads is that no part of them is ever reused. It is a common pitfall of people attempting to implement cryptography to assume that an obscure relationship is necessarily a secure one: it is not. You are create a chain of SHA hashes that can be observed, and potentially decoded. Therefore what you ...


2

Even in a perfect world (the random oracle model) there's no way to ensure first-preimage and second-preimage resistane of more than $2^n$ and collision resistance of more than $2^{n/2}$. (Wie $n$ bytes as the output size of the hash function.) That's the maximum you will ever be able to archive. Cutting off some bytes of the output of a secure hash ...


4

Collision and preimage resistance does not imply this; suppose we select a collision and preimage resistant function $H$ with a known value $I$ with $H(I) = 1$ (the group identity); this additional assertion does not contradict the assumptions of collision or preimage resistance. Then, given $a$, we can easily output the tuple $(I, a)$; as we have $H(I) ...


0

Correct me if I'm wrong, but to crack a 32-bit password hash would take roughly 2^31 attempts, while the math for matching a 32-bit hash from 4 million hashes should take (2^31)/4M ~ 537 attempts. It would take on average $2^{32}$ attempts to crack a single 32-bit hash. If you've got 4 million unique hashes to test against then then each hash you ...


1

My previous answer was wrong because I misunderstood the exact model Gravatar worked under. This issue can be solved through public key crypto, for example Curve25519. Your gravatar service would have a public key available. Then, when a site wants to serve the gravatar of an user Alice with email alice@test.com they will generate the an URL containing $M$ ...


4

Encrypt the hash using the public key of the avatar server with ECC. This has a space overhead of 32 bytes (43 Base64 characters). A modern CPU should be able to decrypt about 10000 messages per second per core. If a website uses a fixed key for all the avatars both sides can cache the shared key, so they don't have to pay the cost of the key exchange all ...


0

Response to Question 2 : algorithm 1 : change the algorithm into this, it will be easier to explain hash1 = sha512(password + salt1); hash2 = sha512(password + salt2); for (i = 0; i < 1000; i++) { hash1 = sha512(hash1); // <-- Do NOT do this! hash2 = sha512(hash2); // <-- Do NOT do this! } For 2 different inputs hash1 and hash2, if ...


-2

OTP requires 1) random key material as long as the message to be encrypted 2) no reuse of the key material or any part, ever 3) secure transmission of the key material between communicants 4) no key material becomes known to anyone ever. And even then, OTP only guarantees that no other encryption will be harder to break. NOT that a message can't ever be ...


2

Well, the GCM tag can be rearranged as $Tag = (Len(C, A) \times H) \oplus \textit{Other Stuff}$; if the length of your ciphertext (and additional authentication data) is consistent, you could precompute $Len(C, A) \times H$, and xor that in along with everything else in the final step. One note: the (add/multiply) that you do in cycle 6 has the side effect ...


-2

In short Encryption help protect the data confidentiality, while hashing protect the data intigrity


2

It is wanted a partial collision (over $b=32$ bits) between hashes of strings starting in distinct strings 1 and 2. I won't directly answer homework, but my hints outgrew a comment. The solution presented should work, though details allowing to output the colliding strings are left out, and there are inefficiencies. Towards guiding optimization, I suggest ...



Top 50 recent answers are included