What will be appropriate AES padding characters?

I pad my input data String with blank white spaces to fit it in multiples of my cipher blocksize. So "Hello world" becomes "Helo world "

But is it the right way ?

Generally we want to be able to encrypt multiple messages of any size. We can do this by using a mode of operation like ECB, CBC, CTR or GCM mode. Some of these modes, notably ECB and CBC require padding. Other modes like CTR or GCM mode don't require padding (or the padding mode is basically integrated in the scheme).

In the case of ECB or CBC we generally want to make sure that we can encrypt messages with any content. With your schemes any message that ends with spaces is in serious jeopardy as it will have it's white space stripped off at the right hand side. This may not be a problem for your particular plaintext messages but it is not a welcome property of a generic cipher.

So if you decide to go with CBC (as ECB is inherently insecure) then you want a padding scheme that always pads, and which has a padding scheme that can be deterministically removed without damaging the message itself. Most of the security industry has been using PCKS#7 compatible padding for that.

Alternatively you can use an authenticated scheme like AES-GCM which provides integrity protection and authenticates the messages (in the sense that anybody who created the messages must have had access to the secret key). In that case the problem is immediately solved as you don't need to pad. This is because AES is used in counter mode (i.e. CTR mode) within the authenticated GCM mode, and CTR mode turns AES into a stream cipher; those do not require padding.

Can some body crack my key, by sending empty Strings?

No, AES - the block cipher - will protect your key. However, an attacker may use a padding oracle attack or plaintext oracle attack if you don't use an authenticated mode or add a MAC authentication tag over your message. These attacks will expose all the plaintext data of the message if applicable - basically rendering the encryption and thus the key useless.

Beware that sending empty Strings seems to imply that you want to use AES for transport security. Transport security is notoriously hard to get right, so please make sure you use a transport protocol such as TLS 1.3 for any data of any importance.

But is it the right way?

There are various padding styles for this. The padding must be removed correctly and uniquely. For example, the all-zero padding may remove your actual information. If the message end with zero, there is no unique way to remove the padding (the right part is the padding) without length information.

.....0 00 

the result after padding is .....000 or .....00 or .....0? So this is not proper padding. Even the same exist the meesages that end with 1.

.....1 00 

Is it .....100 or .....10 or .....1? Some of the real padding schemes;

• append 1 then all zeros
• ciphertext stealing padding.
• PKCS#7 padding defined in rfc 2898

For such algorithms, the method shall be to pad the input at the trailing end with k - (l mod k) octets all having value k - (l mod k), where l is the length of the input.

for example;

  ......01
  ....0202
  ..030303

The right way, indeed using a mode like CTR so that you will not need padding. The paddings have security issues like padding oracle attacks in CBC mode.

Can somebody crack my key, by sending empty Strings?

What is an empty string, all-zero? Why do you need to send all-zero? What is the Mode of operation? There are lots of questions about this. That really depends on your application. For example, it may reveal that you send it again if you are using ECB mode - don't use it. If you use a semantically secure mode you can be fine, however, keep in mind that each mode has its own problems. For example; in CBC mode the nonce must be unpredictable, In GCM, CTR the IV must be unique.

Use modern encryption modes like Authenticated Encryption (AE). AE will provide you Confidentiality, Integrity, and Authentication. AE examples are AES-GCM and ChaCha20-Poly1305 which are in TLS 1.3. AES-GCM internally uses CTR mode that no need a padding scheme.