Tag Info

Hot answers tagged

48

Is Git crowdsourcing the production of SHA-1 preimages? Not to any meaningful degree. Github doesn't say how many commits it's tracking, but it's probably not more than a few billion. For comparison, there are 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 possible SHA-1 hashes, so the odds of finding a plaintext matching an arbitrary ...


12

You could probably compute your own SHA1 hashes quicker from small arbitrary texts than that you harvest the hashes that someone else computed. But there's a lot of possible SHA1 digests, like a few for each atom in the universe and still some left. That illustrates the challenge if you want to keep a list of all known digests and search that list.


9

What you have defined is not security. SSL can give you security. So...your question is easy to answer: Yes - SSL is up to 100% more secure than encoding. While elements of your 2nd paragraph have some basis in fact (there are malicious MITM attacks etc) they can be protected against, whereas your solution has no protection, and is easily decoded by ...


8

The amount of human effort which has gone into computing each of those SHA-1 hashes found in Git is significant. And that means the number of hashes computed that way is fairly limited. If you want to find collisions, you need zero human effort per hash and very little computer time spend on each hash. Bitcoin might be the only system with enough computing ...


2

I'm not sure who this is intended to stop -- the encoding scheme described is barely strong enough to defeat a "clueless eavesdropper"-class threat, and is incapable of stopping or even significantly slowing a "nosy little brother"-class attacker. Someone with the technical capabilities to perform a successful SSL "man-in-the-middle" attack as described in ...


2

You are in the situation, that your client and server alreay share a secret (your algorithm adding 42 to each byte). While this is a very unsecure implementation, it would be possible to encrypt the content with a strong key and your message would be safe. The problem is, that as soon as somebody gets the secret (however he does it), he can read your ...


2

As listed in the OpenSSL docs, the following TLS 1.0 suites support PFS via Diffie-Hellman Ephemeral: TLS_DHE_DSS_WITH_DES_CBC_SHA DHE-DSS-CBC-SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE-DSS-DES-CBC3-SHA TLS_DHE_RSA_WITH_DES_CBC_SHA DHE-RSA-DES-CBC-SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE-RSA-DES-CBC3-SHA ...


1

What you have implemented is something very similar to the "Caesar cipher" which has already has been used in the 8th century. It is easily breakable with pen and paper. See this article for more information: http://en.wikipedia.org/wiki/Caesar_cipher#Breaking_the_cipher So basically, no your algorithm does not compare to current TLS implementations. Also ...


1

Add a basic system monitor and check for dropped packets vs resends: a hacker will have multiple resent packets (0x06) a person being lagged by outside forces will have congested packets (0x08) Here's another concept: A person eating lag will get targeted by a hacker with lagger/dropper tools, standard hacker tools indeed. A hacker sending out lag will ...


1

Yes, password credentials can still be stolen through a man-in-the-middle method with SSHv2. The victim profile will depend on the type of man-in-the-middle method used. For your example of arp poisoning from a client workstation, arp poisoning would maximally really grant middling between clients on the nearby local network, or all clients if the server ...



Only top voted, non community-wiki answers of a minimum length are eligible