Tag Info

New answers tagged

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 ...


-2

You see a lot of tools for breaking specific protocols, but are there generic tools for hand crafted encodings? In which case, this might be an adequate method for the general public.


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 ...


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 ...


0

You have intentionally set up an impossible situation: People distrust each other enough that we have to defend against lying-cheating-stealing People are even worried that the subconscious of the other person might betray them. People seek cryptographic grade guarantees All solutions are explicitly forbidden by your examples: People are uninterested in ...


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 ...


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.


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 ...


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 ...


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 ...


0

ISAKMP isn't a protocol as much as a framework for key exchanges (I know it has protocol in the name). Implementations of the framework include the Internet Key Exchange (IKE) and Kerberized Internet Negotiation of Keys (KINK). If you read the ISAKMP RFC (RFC2408) it has a nice diagram for where ISAKMP sits in the network stack. RFC2408 Section 2.2 ...


1

According to this and Wikipedia, the OSI Session Layer is responsible for setting up any kind of conversation/dialogue. As ISAKMP runs on top of UDP (port 500) and it sets up a secure and authenticated channel for communication, i would say that it is part of OSI Session Layer.


1

The answer is no, and it's explained why in the Thomas Pornin answer to another question. From any system that doesn't require a trusted third party, there's no way to escape, since you can force them to reveal the secret at the same time. So, no matter if you encrypt it, sign it, say it louder, everybody types at the same time in a chat, reveal some hash ...



Top 50 recent answers are included