Say we're using a shared key between two parties, that has been distributed using public key encryption, is it still necessary to sign any data that's encrypted using the shared key? Or is it enough to assume that because the shared key was distributed using public key crypto , and hopefully only known to the two parties involved, the message doesn't need to be signed to authenticate the sender?
Basically, does symmetric key encryption give any authenticity, and possibly non-repudiation?
Encryption with a secret symmetric key does not prove authenticity unless you use an authenticated encryption mode of operation such as GCM. Authenticated encryption algorithms generate a Message Authentication Code (MAC) in addition to encrypting the message, and if the shared key is properly secured this can be used to prove the authenticity and integrity of the message but not non-repudiation (this is a big "if" - more later).
Regular symmetric key encryption with a shared key does not prove the integrity nor authenticity of the message because nothing prevents an attacker from generating a random message which the receiver will then decrypt and accept. Though the attacker doesn't know what the decrypted message will look like there are many situations in which having the receiver accept a randomly generated message may be advantageous to an attacker.
Only someone with access to the symmetric key can generate a MAC of a message, so using authenticated encryption with a properly secured symmetric key is enough to authenticate the message. MACs do not provide non-repudiation because in symmetric cryptography the receiver also has the same secret key, so there's no way for the receiver to prove that the sender and not the receiver signed the message.
As emphasized previously, using a shared key for authentication requires the shared key to be properly secured. Specifically, if the receiver generates the symmetric key and sends it to the sender asymmetrically encrypted with the receiver's public key (which is the ordinary way to send encryption keys using PKI) then this symmetric key cannot be used to prove the authenticity of messages sent by the sender since nothing in the process proves the identity of the sender. Anyone with access to the receiver's public key (which is after all public) can generate a random symmetric key and encrypt it with the receiver's public key.
A symmetric key can be used to authenticate a message only if the scheme for generating the shared symmetric key includes two way authentication. Schemes which include two way authentication to generate shared keys for signing and encrypting messages are commonly known as a Secure Authenticated Channel or SAC.
Encryption does not protect against malicious alterations. If you encrypt some data with a stream cipher like RC4 or AES-CTR, then an attacker can decide to flip any bit he wants on the ciphertext, and, upon decryption, this flips the corresponding bit in the plaintext. This allows surgical modifications. With block ciphers in CBC mode, things are a bit less surgical, but still contained enough to allow the attacker to do a lot of nifty things (with CBC and a block cipher with 16-byte blocks, if the attacker flips one bit, then this scrambles the corresponding block and flips the corresponding bit in the next block).
So you need checked integrity as well as encryption. Some modes of encryption for block ciphers, such as EAX, combine encryption and an integrity check. Otherwise, a stand-alone MAC can do the trick (but combining encryption and a MAC properly is not a totally obvious task so you are encouraged to use modes where all the hard specification work has been done, i.e. EAX).
Some people use the term "signature" for a MAC; it is an improper but widespread usage. A MAC, and a fortiori mere unprotected encryption, do not provide non-repudiation. Non-repudiation is about having a proof which can be used against the signer; conceivably, something which could convince a third party like a judge. A computation which uses a shared secret between sender and receiver cannot be a convincing proof, because, by definition, both sender and receiver know it (and the dispute is between the sender and the receiver). Non-repudiation is a complex notion with legal ramifications, but, at the very least, the computer part must use true digital signatures computed over the data which is not to be repudiated (and not only over a shared key).
Side-note: for the same reasons, SSL does not provide non-repudiation, even when a client-side certificate is used. If a SSL server records all about a SSL connection from a client, and the client is authenticated with a certificate, then the server may have a proof that a given client really came by, but the server cannot prove anything to a third party about what the client sent in the SSL tunnel. This is actually a legally challenging issue when it comes to online banking.
