a 1024-bit private key is generated using the openssl genrsa privateKey.pem 1024 command.
we extract the public key from the private key using the command
openSSl rsa -in privatekey.pem -pubout -out publickey.pem
I want to know the size of my private key and my public key?
I want to know the maximum size of a file that I want to encrypt with my public key?
and the maximum size that I want to decrypt with my private key?
First of all, a 1024-bit RSA key is much too small for comfort. Current recommendations for RSA are a debate between 3072 or 4096 (better security margin) vs. 2048 (better performance). See:
I want to know the maximum size of a file that I want to encrypt with my public key? and the maximum size that I want to decrypt with my private key?
The limit here really comes down not to RSA itself, because practical public-key cryptography is almost always hybrid cryptography where RSA is used to encapsulate symmetric encryption keys (usually for some AES-based algorithm) and the actual data is encrypted with those. So what in practice limits the size of the file you can encrypt is the design of the file or message format. For example with AES-GCM you cannot encrypt individual messages bigger than 64 GiB, and you should not encrypt more than 232 messages with one key, but that really means that to encrypt a larger volume of data the software should split it into smaller chunks and encrypt each one as a separate message, rotating keys after some number of chunks is exceeded.
(Side note: even for smaller files it's best to encrypt them in modest-sized chunks so that the software can reject forgeries without having to decrypt the whole file before producing any output. For example, one of the causes of the EFail vulnerability is that GnuPG outputs the decryptions of forged files before it performs an optional anti-forgery check.)
This is just one example; the general answer is that your question cannot be answered concretely with just the information that you give, and concrete answers require looking at your specific cryptographic software to see how it's designed and implemented. For example, the documentation for GnuPG tells you for some of its symmetric algorithms you should not encrypt files bigger than 4 GiB:
Due to its 1970s-era 64-bit block size, [3DES] should not be used to encrypt more than about 4Gb of data. Beyond that, though, it is solid as a rock, and very few GnuPG users will ever notice a problem with it. Provided you’re not encrypting more than 4Gb of data you may use 3DES with confidence.
I could not quickly find what's the failure mode if you violate this rule, and I cannot warrant whether it gives you an error saying you did something bad (as it should) or just silently produces a potentially insecure output file (which would be terrible). Caveat emptor.
The 1024 bit number on the key describes the modulus used as part of encryption and decryption of a message (see https://security.stackexchange.com/a/8914/29905), which is paired with a public exponent for the public key and a private exponent for the private key - effectively, the message is first taken to the power of the public exponent e or the private exponent d, then the modulus of that number and the 1024-bit N is found. The most significant bit of the 1024 bit N is always 1, so any block of 1023 bits can be encrypted as N will always be a larger number - if the plaintext is 1024 bits with the most significant bit set to 1, one would need to check that its numeric value is less than N. The basic answer to your question then is that RSA can encrypt and decrypt a message of up to (key length - 1) bits. However, a message can be broken up into blocks of a small enough size to allow for padding (to make each block a unified length and add non-determinism) and each block encrypted individually with RSA.
You also asked about the size of your key. I mentioned earlier that the key is actually a composite of two numbers, N and either e or d. e and d are related by being modular multiplicative inverses of each other mod λ(N), i.e. (e * d) mod λ(N) = 1. Their lengths aren't exactly related to the bit-length of N, but the smaller one is, the larger the other must be since e * d > N (noting e,d > 1). So, the size of your composite keys are the bit length of N plus the length of e or d, where e is generally a small prime. However, in practical implementations, the large d isn't stored and instead certain factors of it are stored that can do the decryption step faster and with a smaller memory footprint during calculation, so the length of the full private key is much smaller.
