3

Suppose:

A and B are initially configured to possess the same key.

-- the key is only known by the pair
-- no key needs to be public

A has an algorithm, a, that takes a message(plain text), m, mutates it with a key, k, producing an encrypted message(cipher text), c.
B possesses the same key, k, that lets its algorithm, b, take c and k to reproduce m.
a and b are available nowadays; plug in whatever algorithm you like best.
Then A and B are set to be immutable.
Then A and B are pulled apart and must communicate over a vulnerable medium.

A only sends messages to B.
B only listens and gives nothing more than ACKs for any messages it receives.

I know B can get malicious input, but won't the malicious input be decrypted into garbage?
Can A be spoofed if the key and algorithm were initially set before they were separated?
The key and algorithm is pre-established, so nothing revealing is sent across the medium, right? If A and B are immutable, then nothing internally can be changed/compromised.

The only breach that I can see is if A or B are taken whole, and the key is taken along with one of the algorithms.

Is there any other way this method is vulnerable?

ps. I didn't specify a particular algorithm since the concept seemed applicable enough to any algorithm to at least provide some sort of additional confidentiality.

Improve this question
1
  • One fun permutation is repudiability; after someone does copy the key from where it may be, how do you change to a new key? A less fun permutation is the Denial of Service attack, particularly if B decrypts the entire "message" before it checks for validity. – Anti-weakpasswords Feb 24 '14 at 23:05
1

Yes!

Cyphers can take all kinds of forms. By definition a secret is all that is needed.

Doesn't mean it will be secure enough...

http://www.brighthub.com/computing/enterprise-security/articles/65254.aspx

EDIT: If you're proposing to actually implement something like that in production, I would repeat the seasoned advice in other posts. Use already proven algorithms and libraries. That usually means that, in your scenario, A encrypts with B public key, and B decrypts with B private key.

Also, consider once A or B falls, it's complete disaster. Attackers can fake any point in the network, create any message or read any messages that ever passed through the network or ever will.

Improve this answer
8
  • But how do you get the secret other than taking A or B? – user2738698 Feb 24 '14 at 18:05
  • I guess either you guess it or you take advantage on any security vulnerability on a or b. You still have to take in consideration that A or B can fall and your secret will be compromised, though. If B returns to A if the decryption was successful you could brute force for the secret. – Sandokas Feb 24 '14 at 18:16
  • Made some edits to match your answer. Essentially, I was going for a private key known to both initially. And yeah, using proven algorithms and libraries is the way to go. – user2738698 Feb 24 '14 at 19:03
  • Oh, and regarding A or B falling; yeah, that's the only catch that I can see that would break the system. I was looking for any other ways the system could be compromised. – user2738698 Feb 24 '14 at 19:10
  • 1
    Scenario 1: Lets imagine one day A starts by mistake signing empty messages. Inferring the content of the message (empty), the attacker can then brute force the key much more easily. Once he has access to the key he can read all messages that he has been storing. Scenario 2: A sends a message that is a security credential. Attacker doesn't have to add anything to it, just resend the same security token to get authenticated as if he was A. Scenario 3: A few years from now you still have the same key running. Chances are it is brute forced now or A or B might have fallen. Why not change the key? – Sandokas Feb 25 '14 at 11:36
1

Private key encryption is strong enough to protect you given that

  1. You are using a strong enough algorithm
  2. You have enough bits in the key
  3. You are pretty sure your endpoint machines won't get lost or stolen
  4. You don't have to deal with too many disgruntled employees who might steal the key
  5. To deal with #3 & #4, you have some means of rolling the key and distributing new ones in response to security events and also proactively on a regular schedule (frequency depending on the size of the key)
Improve this answer
0

You seem to have some major misconceptions. A salt is not a part of encryption, it is a part of hashing. There is a similar concept in encryption called an IV or initialization vector which is used in a stream cipher to make it so the output of the stream cipher is harder to analyse, but it only provides a benefit if each block of a message is dependent on the previous dependent block for it's output (ie, it is a chaining mode).

The basic premise of encryption is that a message (plain text) is mutated through some secret ( a key) in to a form that is hard to understand without the key (cipher text). There have been many such systems over the years with varying levels of security, from those that can be trivially cracked to those that are very difficult (or even impossible) to crack if properly followed.

The strength of the protection offered depends on the randomness of the key as well as the strength of the algorithm itself to resist analysis, and that is the part that is really, really hard to figure out.

Improve this answer
0
0

There are definitely problems in the protocol, not necessarily in the encryption scheme of the asker.

The protocol allows for replay attacks, i.e. an entity R can capture messages that A sends to B, and then resends the messages without knowing what's in those messages, even though A may not have intended to send those. Then it comes down to what's contained in those messages. For example, let's a A and B are computers and A sends a message to B to reboot, and another entity E captures it. Now, just by replaying the message and observing B's behavior, E can not only cause B to behave the way it wants, it also understands what the message means even though it can't see the contents.

A second type of attack is that another entity M can spoof A and start sending B with a lot of messages. Since B doesn't know whether they are coming from a trusted source, B will attempt to decrypt those messages thus consuming resources. M may no not need as many resources since all M needs to do is create and send random data, but B will start running out of resources, that's a DOS attack.

Another attack involves M capturing the messages that A sends to B and responding with ACK on B's behalf, which it has captured in a previous exchange. B never gets the actual messages and doesn't know that it did not get the message. A never knows that it wasn't B who ACKed the message instead it was E.

There are other more sophisticated attacks that can be constructed in this fashion. The ones I listed here are typically the introductory attacks that are looked at when designing secure protocols.

Security comes with a whole plethora of things, not just encryption. Encryption solves one aspect, albeit the most important one, around security. But in your case, you are also designing a protocol, which is not secure, and thus you might as well use an existing protocol.

That's where security protocols come in which perform appropriate handshakes, authentication (to ensure the other party is the correct one), provide protection against replay attacks etc. Man-in-the-middle attacks could still be a vulnerability (if you don't trust public key infrastructure, that is), although in your case, you can solve that because A and B have a shared secret (In fact, I am assuming that you're starting with shared secret primarily because A and B do not trust anyone else in the world - usually a good reason to have shared secrets.)

Btw, once you have such security protocols, given all the data that they need to send between each other, you will end up with security tokens to ensure that all parties have a mutual understanding of what's contained in it, how it is encoded, etc. (e.g. nonce, keys, encrypted data, digital signature, etc.)

In essence, IMO, you are attempting to create your own security protocol, and as someone already mentioned, you might be better off attempting to start with an existing protocol.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.