Encryption for continuous, real-time data over an unreliable connection I have a continuous stream of real-time data. It must be consumed immediately or discarded, so I'm using UDP for transmission without ACK or retransmission (the connection is unreliable).

The packets I'm sending are of the same length, and one packet is sent per transmission (each next packet invalidates the previous one).

Is it insecure to use AES for encryption, reinitializing the AES context with the same key for each packet?

The AES key is pre-shared over a known wired secure channel.
On AES per packet: Generally it depends, but if you write there so few details, then I would bet you would implement it insecurely (no offense). There are several reasons:


You need to use a specific mode of operation, but you don't mention any. The mode of operation can have substantial impact on security.
You don't mention initialization vectors / nonces. Wrong handling of them (e.g., using a constant IV) can have bad impact on security, but the exact impact depends on mode of operation.
You don't mention any authentication. Not having any authentication can result in messages modified by attacker – for example, some modes of operation reflect bitflips in ciphertext to plaintext. Also, some other modes of operation can leak some data if used without authentication (see POODLE).
You don't mention any replay attack prevention. Without that, attacker can replay or reorder the messages.


I suggest not to implement it yourself and rather use something existing. DLTS seems to be designed for such case.

There are also some additional concerns that probably need to be handled per application:


In some realtime systems, you might want to have a special handling for delayed packets – some might be pretty outdated at the time of arrival and it might be bad to process them.
In some realtime systems, you might want to add a special reaction to situation when you receive no fresh data for some time, regardless it is accidental or due to an attack.