Bob's Not My Uncle

Here are Uncle Bob's Test-Driven Developers Practitioners Three Laws.

1 You may not write production code unless you've first written a failing unit test.
2 You may not write more of a unit test than is sufficient to fail.
3 You may not write more production code than is sufficient to make the failing unit test pass.

Robert C Martin Professionalism and Test-Driven Development in IEEE Software Magazine, Vol 24 No 3 May/June 2007.

I wanted to add encryption to a C# application, tested under NUnit. So I wrote

[Test]
public void Encrypt()
{
string output = m_sc.Encrpyt(INPUT_1);
Assert.AreNotEqual(INPUT_1, output );
}

The test failed. On to Step 3, sufficient code to make the test pass.

public string Encrpyt(string input )
{
return "_" + input;
}

Next test. Different strings get different encryptions. Passed first time.

[Test]
public void EncryptDifferent()
{
string output1 = m_sc.Encrpyt(INPUT_1);
string output2 = m_sc.Encrpyt(INPUT_2);
Assert.AreNotEqual(output1, output2 );
}

Now, decryption. A test and just enough code.

[Test]
public void Decrypt()
{
string output = m_sc.Decrypt( m_sc.Encrpyt(INPUT_1) );
Assert.AreEqual(INPUT_1, output );
}

public string Decrypt(string p)
{
return p.Substring(1);
}

That passes.

But what should I do now? How do I write a unit test that shows up the insufficiency of this encryption? And if I only write enough code to get past that test, will I have a decent level of encryption. If I encypt SECRET as ___*S*E*C*R*E*T*___ who am I fooling, other than my test which checked for a limited set of items?

No disrespect to Uncle Bob. I am not worthy to put a semi-colon on the end of his statement. I just need to know when to disobey the laws.