This is one reason why polymorphic solutions are typically preferred to C-style structs. If FILE were polymorphic, all you'd have to do is derive your EncryptedFile class from it and it could be a drop in replacement without going back and modifying any existing code.
With C .... you don't really have that option. The only way I can think of to get around this is to macro the functions to redefine them. Example:
#define fread encryptedRead
But that, of course, has it's own problems. For one you have to make sure those macros are defined in any source file that is using your encrypted files. For another, it makes the original fread completely inaccessible in files where that macro is defined. So you wouldn't be able to read encrypted and non-encrypted files in the same source file (at least not without undef-ing and redefining the macro multiple times)
So yeah... long story short... this situation sucks. There's no good way to do what you want. With C, you pretty much have to rename your function (which means going back and changing all your fread calls to encryptread).
er wait... so your EncryptedFile is a class? And fread is a member of that class?
If that's the case, you're boned. Not even a macro will work.
Actually... this might work:
#define fread(a,b,c,d) a.read(b,c,d)
But if the function is named 'fread' you're asking for trouble. Well you're asking for trouble anyway when doing macro substitution on a function name... but whatever.
I just want to reiterate that I really do not like the macro solution. It's a really bad idea. I only mention it because it literally is your only option apart from going back and refactoring your code (and in fact... I would even recommend you do that over this macro crap).