𝗖𝗕𝗖 ਬਿੱਟ ਫਲਿੱਪਿੰਗ ਦੀ ਵਿਆਖਿਆ
ਐਨਕ੍ਰਿਪਸ਼ਨ (Encryption) ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਤਬਦੀਲੀ (tampering) ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ।
ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਇਹ ਗਲਤੀ ਕਰਦੇ ਹਨ। ਉਹ ਸੋਚਦੇ ਹਨ ਕਿ ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਬਦਲ ਵੀ ਨਹੀਂ ਸਕਦਾ। ਇਹ ਗਲਤ ਹੈ। ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ (Cryptography) ਗੁਪਤਤਾ (secrecy) ਅਤੇ ਅਖੰਡਤਾ (integrity) ਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ ਕੰਮਾਂ ਵਜੋਂ ਮੰਨਦੀ ਹੈ।
CBC ਬਿੱਟ ਫਲਿੱਪਿੰਗ ਹਮਲਾ ਇਸ ਗੱਲ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਇੱਕ ਹਮਲਾਵਰ ਤੁਹਾਡੀ ਗੁਪਤ ਚਾਬੀ (secret key) ਨੂੰ ਜਾਣੇ ਬਿਨਾਂ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।
ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:
AES ਡੇਟਾ ਨੂੰ ਇੱਕ ਵੱਡੇ ਟੁਕੜੇ ਵਿੱਚ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਡੇਟਾ ਨੂੰ 16-ਬਾਈਟ ਦੇ ਬਲਾਕਾਂ ਵਿੱਚ ਤੋੜ ਦਿੰਦਾ ਹੈ। CBC ਮੋਡ ਵਿੱਚ, ਇਹ ਬਲਾਕ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਪਹਿਲੇ ਬਲਾਕ ਦਾ ਐਨਕ੍ਰਿਪਟਡ ਆਉਟਪੁੱਟ ਦੂਜੇ ਬਲਾਕ ਦੇ ਪਲੇਨਟੈਕਸਟ (plaintext) ਵਿੱਚ ਮਿਲ ਜਾਂਦਾ ਹੈ।
ਇਹ ਚੇਨ ਡੀਕ੍ਰਿਪਸ਼ਨ (decryption) ਦੌਰਾਨ ਇੱਕ ਕਮਜ਼ੋਰੀ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਬਲਾਕ 2 ਦੇ ਅਸਲ ਟੈਕਸਟ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਸਰਵਰ ਇਸਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਬਲਾਕ 1 ਦੇ ਸਾਈਫਰਟੈਕਸਟ (ciphertext) ਨਾਲ ਜੋੜਦਾ ਹੈ।
ਇੱਕ ਹਮਲਾਵਰ ਇਸਦਾ ਫਾਇਦਾ ਉਠਾ ਸਕਦਾ ਹੈ:
- ਹਮਲਾਵਰ ਤੁਹਾਡੇ ਐਨਕ੍ਰਿਪਟਡ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੰਟਰਸੈਪਟ (intercept) ਕਰਦਾ ਹੈ।
- ਉਹ ਚਾਬੀ (key) ਨਹੀਂ ਜਾਣਦੇ, ਇਸ ਲਈ ਡੇਟਾ ਬੇਤੁਕਾ (gibberish) ਲੱਗਦਾ ਹੈ।
- ਉਹ ਬਲਾਕ 1 ਦੇ ਸਾਈਫਰਟੈਕਸਟ ਵਿੱਚ ਖਾਸ ਬਿੱਟਸ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ।
- ਉਹ ਇਹ ਬਦਲਿਆ ਹੋਇਆ ਡੇਟਾ ਤੁਹਾਡੇ ਸਰਵਰ ਨੂੰ ਭੇਜਦੇ ਹਨ।
- ਜਦੋਂ ਸਰਵਰ ਇਸਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, ਤਾਂ ਬਲਾਕ 1 ਵਿੱਚ ਬਦਲਾਅ ਬਲਾਕ 2 ਲਈ ਗਣਿਤ (math) ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਹਮਲਾਵਰ ਨੂੰ ਸੁਨੇਹਾ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਉਹ ਸਿਰਫ ਅੰਤਿਮ ਨਤੀਜੇ ਨੂੰ ਬਦਲਣ ਲਈ ਬਿੱਟਸ ਨੂੰ ਫਲਿੱਪ (flip) ਕਰਦੇ ਹਨ।
ਇੱਕ ਪੁਰਾਣੇ ਵੈੱਬ ਐਪ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜੋ ਸੈਸ਼ਨਾਂ ਲਈ ਐਨਕ੍ਰਿਪਟਡ ਕੁਕੀਜ਼ (cookies) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਕ ਕੁਕੀ ਵਿੱਚ ਇਹ ਹੋ ਸਕਦਾ ਹੈ:
userid=994;role=user;
ਇੱਕ ਹਮਲਾਵਰ ਇਸ ਕੁਕੀ ਨੂੰ ਰੋਕ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸਾਈਫਰਟੈਕਸਟ ਵਿੱਚ ਬਿੱਟਸ ਨੂੰ ਫਲਿੱਪ ਕਰਦਾ ਹੈ। ਉਹ ਕਈ ਬੇਨਤੀਆਂ (requests) ਭੇਜਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਸਰਵਰ ਇੱਕ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਲੈਂਦਾ। ਕਿਉਂਕਿ ਸਰਵਰ ਸਿਰਫ ਇਹ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਡੇਟਾ ਡੀਕ੍ਰਿਪਟ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਸੋਧੇ ਹੋਏ ਟੈਕਸਟ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ। ਅਚਾਨਕ, ਡੀਕ੍ਰਿਪਟ ਕੀਤੀ ਗਈ ਸਟ੍ਰਿੰਗ ਇਹ ਪੜ੍ਹਦੀ ਹੈ:
userid=994;role=admi;
ਹਮਲਾਵਰ ਕੋਲ ਹੁਣ ਐਡਮਿਨ (admin) ਐਕਸੈਸ ਹੈ। ਉਹਨਾਂ ਨੇ ਕਦੇ ਵੀ ਚਾਬੀ ਜਾਂ ਅਸਲ ਕੁਕੀ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹਿਆ।
ਗਲਤੀ ਇਹ ਮੰਨਣਾ ਹੈ ਕਿ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਖੰਡਤਾ (integrity) ਦੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
- ਗੁਪਤਤਾ (Confidentiality) ਲੋਕਾਂ ਨੂੰ ਡੇਟਾ ਪੜ੍ਹਨ ਤੋਂ ਰੋਕਦੀ ਹੈ।
- ਅਖੰਡਤਾ (Integrity) ਲੋਕਾਂ ਨੂੰ ਡੇਟਾ ਬਦਲਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, AES-GCM ਵਰਗੀ Authenticated Encryption ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਟੈਗ ਬਣਾਉਂਦੀ ਹੈ। ਇਹ ਟੈਗ ਇੱਕ ਮੋਹਰ (seal) ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ ਇੱਕ ਬਿੱਟ ਵੀ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਮੋਹਰ ਟੁੱਟ ਜਾਂਦੀ ਹੈ। ਸਰਵਰ ਤੁਰੰਤ ਡੇਟਾ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ।
ਜੇਕਰ ਤੁਹਾਨੂੰ CBC ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੀ ਪੈਂਦੀ ਹੈ, ਤਾਂ Encrypt-then-MAC ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਸਾਈਫਰਟੈਕਸਟ ਲਈ ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਕੋਡ (authentication code) ਬਣਾਓ ਅਤੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਗੁਪਤ ਡੇਟਾ ਹਮੇਸ਼ਾ ਭਰੋਸੇਯੋਗ ਡੇਟਾ ਨਹੀਂ ਹੁੰਦਾ। ਫੈਸਲੇ ਲੈਣ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਮੇਸ਼ਾ ਸਾਬਤ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ ਹੈ।
CBC ਬਿਟ-ਫਲਿੱਪਿੰਗ ਦੀ ਵਿਆਖਿਆ: ਕਿਉਂ ਸਿਰਫ਼ ਐਨਕ੍ਰਿਪਸ਼ਨ ਇੰਟੈਗ੍ਰਿਟੀ (integrity) ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ
ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਜੇਕਰ ਡਾਟਾ ਐਨਕ੍ਰਿਪਟਡ ਹੈ, ਤਾਂ ਉਹ ਸੁਰੱਖਿਅਤ ਹੈ। ਪਰ ਸੁਰੱਖਿਆ ਦੇ ਦੋ ਮਹੱਤਵਪੂਰਨ ਪਹਿਲੂ ਹਨ: ਗੁਪਤਤਾ (Confidentiality) ਅਤੇ ਅਖੰਡਤਾ (Integrity)।
ਐਨਕ੍ਰਿਪਸ਼ਨ ਗੁਪਤਤਾ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ—ਯਾਨੀ ਕਿ ਕੋਈ ਵੀ ਅਣਅਧਿਕਾਰਤ ਵਿਅਕਤੀ ਡਾਟਾ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ। ਪਰ ਇਹ ਇੰਟੈਗ੍ਰਿਟੀ ਯਕੀਨੀ ਨਹੀਂ ਬਣਾਉਂਦਾ—ਯਾਨੀ ਕਿ ਇਹ ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ ਡਾਟਾ ਨਾਲ ਛੇੜਛਾੜ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ।
CBC (Cipher Block Chaining) ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ ਹਮਲਾਵਰ ਡਾਟਾ ਨੂੰ ਪੜ੍ਹੇ ਬਿਨਾਂ ਹੀ ਉਸ ਵਿੱਚ ਬਦਲਾਅ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ CBC ਬਿਟ-ਫਲਿੱਪਿੰਗ ਹਮਲਾ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
CBC ਮੋਡ ਕੀ ਹੈ?
CBC ਮੋਡ ਵਿੱਚ, ਹਰੇਕ ਪਲੇਨਟੈਕਸਟ (plaintext) ਬਲਾਕ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਿਛਲੇ ਸਾਈਫਰਟੈਕਸਟ (ciphertext) ਬਲਾਕ ਨਾਲ XOR ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪਹਿਲੇ ਬਲਾਕ ਲਈ, ਅਸੀਂ ਇੱਕ Initialization Vector (IV) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।
ਇਸਦੀ ਗਣਿਤਕ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਹੈ: $C_i = E_k(P_i \oplus C_{i-1})$
ਜਿੱਥੇ:
- $C_i$ ਮੌਜੂਦਾ ਸਾਈਫਰਟੈਕਸਟ ਬਲਾਕ ਹੈ।
- $P_i$ ਮੌਜੂਦਾ ਪਲੇਨਟੈਕਸਟ ਬਲਾਕ ਹੈ।
- $C_{i-1}$ ਪਿਛਲਾ ਸਾਈਫਰਟੈਕਸਟ ਬਲਾਕ ਹੈ (ਜਾਂ ਪਹਿਲੇ ਬਲਾਕ ਲਈ IV)।
- $E_k$ ਐਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ ਹੈ।
ਡੀਕ੍ਰਿਪਸ਼ਨ ਦੇ ਸਮੇਂ, ਪ੍ਰਕਿਰਿਆ ਉਲਟ ਹੁੰਦੀ ਹੈ: $P_i = D_k(C_i) \oplus C_{i-1}$
ਕਮਜ਼ੋਰੀ (The Vulnerability)
ਉੱਪਰ ਦਿੱਤੇ ਡੀਕ੍ਰਿਪਸ਼ਨ ਫਾਰਮੂਲੇ ਨੂੰ ਦੇਖੋ: $P_i = D_k(C_i) \oplus C_{i-1}$।
ਇੱਥੇ ਇੱਕ ਬਹੁਤ ਵੱਡੀ ਕਮਜ਼ੋਰੀ ਹੈ: ਪਲੇਨਟੈਕਸਟ ਬਲਾਕ $P_i$ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਪਿਛਲੇ ਸਾਈਫਰਟੈਕਸਟ ਬਲਾਕ $C_{i-1}$ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਹਮਲਾਵਰ $C_{i-1}$ ਵਿੱਚ ਕਿਸੇ ਬਿਟ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਸਦਾ ਸਿੱਧਾ ਅਸਰ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਪਲੇਨਟੈਕਸਟ $P_i$ 'ਤੇ ਪਵੇਗਾ।
ਜੇਕਰ ਹਮਲਾਵਰ $C_{i-1}$ ਨੂੰ $C'_{i-1}$ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਨਵਾਂ ਪਲੇਨਟੈਕਸਟ $P'_i$ ਇਸ ਤਰ੍ਹਾਂ ਹੋਵੇਗਾ: $P'_i = P_i \oplus \Delta$
ਜਿੱਥੇ $\Delta$ ਉਹ ਬਦਲਾਅ ਹੈ ਜੋ ਹਮਲਾਵਰ ਨੇ ਸਾਈਫਰਟੈਕਸਟ ਵਿੱਚ ਕੀਤਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਮਲਾਵਰ ਬਿਨਾਂ ਚਾਬੀ (key) ਜਾਣੇ, ਪਲੇਨਟੈਕਸਟ ਵਿੱਚ ਆਪਣੀ ਮਰਜ਼ੀ ਅਨੁਸਾਰ ਬਦਲਾਅ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਵਿਹਾਰਕ ਉਦਾਹਰਨ
ਮੰਨ ਲਓ ਇੱਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਕੂਕੀ (cookie) ਭੇਜਦੀ ਹੈ ਜੋ ਐਨਕ੍ਰਿਪਟਡ ਹੈ:
user_id=123;role=guest
ਜੇਕਰ ਇਹ ਡਾਟਾ CBC ਮੋਡ ਵਿੱਚ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਹਮਲਾਵਰ ਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਅਸਲ ਡਾਟਾ ਕੀ ਹੈ, ਪਰ ਉਹ ਜਾਣਦਾ ਹੈ ਕਿ role=guest ਕਿੱਥੇ ਸਥਿਤ ਹੋ ਸਕਦਾ ਹੈ।
- ਹਮਲਾਵਰ ਸਾਈਫਰਟੈਕਸਟ ਦੇ ਉਸ ਹਿੱਸੇ ਨੂੰ ਲੱਭਦਾ ਹੈ ਜੋ
guestਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। - ਉਹ ਉਸ ਬਲਾਕ ਵਿੱਚ ਬਿਟਸ ਨੂੰ ਬਦਲਦਾ ਹੈ (flip ਕਰਦਾ ਹੈ) ਤਾਂ ਜੋ ਡੀਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਬਾਅਦ
guestਦੀ ਜਗ੍ਹਾadminਬਣ ਜਾਵੇ। - ਹਾਲਾਂਕਿ ਇਸ ਨਾਲ ਪਿਛਲਾ ਬਲਾਕ ਖਰਾਬ ਹੋ ਜਾਵੇਗਾ (corrupt ਹੋ ਜਾਵੇਗਾ), ਪਰ ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਸਿਰਫ਼
roleਵਾਲੇ ਹਿੱਸੇ ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ, ਤਾਂ ਹਮਲਾ ਸਫਲ ਹੋ ਜਾਵੇਗਾ।
ਨਤੀਜਾ: ਹਮਲਾਵਰ ਹੁਣ role=admin ਦੇ ਰੂਪ ਵਿੱਚ ਸਿਸਟਮ ਵਿੱਚ ਦਾਖਲ ਹੋ ਸਕਦਾ ਹੈ।
ਇਸ ਤੋਂ ਕਿਵੇਂ ਬਚਿਆ ਜਾਵੇ?
ਸਿਰਫ਼ ਐਨਕ੍ਰਿਪਸ਼ਨ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਡਾਟਾ ਨਾਲ ਛੇੜਛਾੜ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ। ਇਸਦੇ ਦੋ ਮੁੱਖ ਤਰੀਕੇ ਹਨ:
- Authenticated Encryption (AEAD): ਅਜਿਹੇ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਇੱਕੋ ਸਮੇਂ ਗੁਪਤਤਾ ਅਤੇ ਇੰਟੈਗ੍ਰਿਟੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ AES-GCM। ਇਹ ਹਮਲੇ ਨੂੰ ਆਪਣੇ ਆਪ ਫੜ ਲੈਂਦੇ ਹਨ।
- HMAC (Hash-based Message Authentication Code): ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਡਾਟਾ ਦੇ ਉੱਪਰ ਇੱਕ HMAC ਲਗਾਓ। ਡੀਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ, HMAC ਦੀ ਜਾਂਚ ਕਰੋ। ਜੇਕਰ ਸਾਈਫਰਟੈਕਸਟ ਵਿੱਚ ਇੱਕ ਬਿਟ ਵੀ ਬਦਲਿਆ ਗਿਆ ਹੈ, ਤਾਂ HMAC ਮਿਲੇਗਾ ਨਹੀਂ ਅਤੇ ਡਾਟਾ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ।
ਸਿੱਖਿਆ: ਹਮੇਸ਼ਾ ਯਾਦ ਰੱਖੋ—Encryption $\neq$ Integrity। ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਲਈ ਦੋਵਾਂ ਦੀ ਲੋੜ ਹੈ।