I'd first consider sub-classing TextBox.
If there are "many" of these TextBoxes you will create; I'd think about whether they can and will be possibly removed at run-time, as well as added : whether there are some circumstances in which you would ever want to "dis-connect" one or all of the special events from being processed by one or all of these special TextBoxes.
While you could adopt a strategy of overriding the ProcessCmdKeys for the Form (with Form preview key enabled) to handle globally the issue of relevant keystate at the Form level, I wouldn't go there; I would want to isolate it to the special case textbox. The discussion of ProcessCmdKeys here :
May be useful to you.
I'd want to create special class to handle instantiation and management of these special textboxes, and their "endownment" with these special event-raisers : you might want to keep a List<TextBox> of the ones currently being used to "track" them. Or, if you are sub-classing, List<SpecialTextBox>.
... note we're skipping over the whole issue of the possibility of a paste or copy being triggered by a selection from the TextBox default menu : are you enabling that ? Is that important to you ? Do you need to "suppress that menu" ? If you wish to still have that menu, and still "catch" the events : imho you are going to have to sub-class TextBox and define a WndProc and catch events like WM_Paste there. ...
There's a pretty complete example of code for sub-classing a TextBox and handling ProcessCmdKeys and trapping the kinds of events you are interested in here :
But please note I haven't used or tested the above code myself, it was just filed away in my "archive" of snippets, but, at the very least, it will give you a basis for study ... if you have to sub-class.