23 ਮਈ 2025·8 ਮਿੰਟ
Whitfield Diffie ਦੀ ਪਬਲਿਕ-ਕੀ ਖੋਜ: ਵੈੱਬ ਅਤੇ ਡਿਜ਼ੀਟਲ ਪਛਾਣ ਲਈ
ਕਿਵੇਂ Whitfield Diffie ਦੀ ਪਬਲਿਕ-ਕੀ ਖੋਜ ਨੇ HTTPS, ਸੁਰੱਖਿਅਤ ਮੈਸੇਜਿੰਗ ਅਤੇ ਡਿਜ਼ੀਟਲ ਪਛਾਣ ਨੂੰ ਸੰਭਵ ਬਣਾਇਆ — ਮੁੱਖ ਵਿਚਾਰਾਂ ਅਤੇ ਅਸਲ-ਜੀਵਨ ਵਰਤੋਂਆਂ ਨਾਲ ਸਮਝਾਇਆ ਗਿਆ।
ਕਿਵੇਂ Whitfield Diffie ਦੀ ਪਬਲਿਕ-ਕੀ ਖੋਜ ਨੇ HTTPS, ਸੁਰੱਖਿਅਤ ਮੈਸੇਜਿੰਗ ਅਤੇ ਡਿਜ਼ੀਟਲ ਪਛਾਣ ਨੂੰ ਸੰਭਵ ਬਣਾਇਆ — ਮੁੱਖ ਵਿਚਾਰਾਂ ਅਤੇ ਅਸਲ-ਜੀਵਨ ਵਰਤੋਂਆਂ ਨਾਲ ਸਮਝਾਇਆ ਗਿਆ।
ਜਦੋਂ ਵੀ ਤੁਸੀਂ ਆਪਣੇ ਬੈਂਕ ਵਿੱਚ ਲੌਗਇਨ ਕਰਦੇ ਹੋ, ਔਨਲਾਈਨ ਕੁਝ ਖਰੀਦਦੇ ਹੋ, ਜਾਂ ਨਿੱਜੀ ਸੁਨੇਹਾ ਭੇਜਦੇ ਹੋ, ਤੁਸੀਂ ਇਕ ਸਧਾਰਣ ਵਿਚਾਰ 'ਤੇ ਨਿਰਭਰ ਹੋ: ਤੁਸੀਂ ਇਕ ਐਸੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਜਾਣਕਾਰੀ ਸਾਂਝੀ ਕਰ ਸਕਦੇ ਹੋ ਜਿਸਨੂੰ ਹੋਰ ਲੋਕ ਵੇਖ ਸਕਦੇ ਹਨ, ਫਿਰ ਵੀ ਅਹਮ ਹਿੱਸਿਆਂ ਨੂੰ ਗੋਪਨੀਯਤ ਰੱਖ ਸਕਦੇ ਹੋ।
ਹੁਣ ਇਹ ਸਪੱਸ਼ਟ ਲੱਗਦਾ ਹੈ, ਪਰ ਪਹਿਲਾਂ ਇਹ ਵਰਤੋਂ ਵਿੱਚ ਇੱਕ ਪਰੇਸ਼ਾਨੀ ਵਾਲਾ ਮਸਲਾ ਸੀ। ਜੇ ਦੋ ਲੋਕ ਇਨਕ੍ਰਿਪਸ਼ਨ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਸਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਇਕ ਸਾਂਝਾ ਰਾਜ਼ੀ-ਕੀ ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਪੈਂਦਾ ਸੀ। ਇਸਦਾ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਅਕਸਰ ਇਕ ਭਰੋਸੇਯੋਗ ਕੋਰਿਅਰ, ਪਹਿਲ ਤੋਂ ਕੀਤਾ ਗਿਆ ਮਿਲਾਪ, ਜਾਂ ਕੋਈ ਸੇਕਿਊਰ ਕੰਪਨੀ ਨੈੱਟਵਰਕ ਲੋੜੀਂਦਾ ਸੀ—ਜੋ ਖੁੱਲ੍ਹੇ ਇੰਟਰਨੈੱਟ 'ਤੇ ਮਿਲਿਅਨਾਂ ਅਜਾਣਿਆਂ ਲਈ ਸਕੇਲ ਨਹੀਂ ਹੁੰਦਾ।
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਨੇ ਇਹ ਨਿਯਮ ਬਦਲ ਦਿੱਤਾ। ਇਸਨੇ ਇਕ ਤਰੀਕਾ ਦਰਜ ਕੀਤਾ ਜਿਸ ਵਿੱਚ ਇੱਕ ਕੀ ਖੁੱਲ੍ਹਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ (public key) ਤੇ ਦੂਜੀ ਕੀ ਗੁਪਤ ਰੱਖੀ ਜਾ ਸਕਦੀ ਹੈ (private key). ਇਸ ਵੰਡ ਨਾਲ, ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਸਾਂਝਾ ਰਾਜ਼ ਬਿਨਾਂ ਹੀ ਇਕ ਸੁਰੱਖਿਅਤ ਰਿਸ਼ਤਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹੋ। Whitfield Diffie ਇਸ ਬ੍ਰੇਕਥਰੂ ਨੂੰ ਆਮ ਕਰਨ ਅਤੇ ਇਸਦੀ ਮਹੱਤਤਾ ਦਿਖਾਉਣ ਵਿੱਚ ਕੇਂਦਰੀ ਕਿਰਦਾਰ ਸੀ।
ਅਸੀਂ ਮੁੱਢਲੇ ਵਿਚਾਰਾਂ ਨੂੰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਨਾਲ ਜੋੜਾਂਗੇ ਜੋ ਤੁਸੀਂ ਅਸਲ ਜ਼ਿੰਦਗੀ ਵਿੱਚ ਵਰਤਦੇ ਹੋ:
ਤੁਹਾਨੂੰ ਆਮ-ਫਹਿਮੀ ਵਿੱਚ ਸਮਝਾਉਣਾ ਮਿਲੇਗਾ, ਸਿਰਫ਼ ਕਾਫ਼ੀ ਗਣਿਤੀ ਅੰਦਾਜ਼ ਦਿੱਤਾ ਜਾਵੇਗਾ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਮਝ ਸਕੋ ਕਿਉਂ ਇਹ ਤਰਕੀਬਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ—ਬਿਨਾਂ ਇਸਨੂੰ ਟੈਕਸਟਬੁੱਕ ਬਣਾਉਣ ਦੇ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋ ਜਾਦੂ ਵਾਂਗ ਨਾ ਲੱਗੇ, ਬਲਕਿ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਸੰਦ ਵਾਂਗ ਅਨੁਭਵ ਹੋਵੇ ਜੋ ਰੋਜ਼ਾਨਾ ਜ਼ਿੰਦਗੀ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ।
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਤੋਂ ਪਹਿਲਾਂ, ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ ਅਕਸਰ symmetric encryption ਦਾ ਮਤਲਬ ਸੀ: ਦੋਵਾਂ ਪਾਸਿਆਂ ਕੋਲ ਇੱਕੋ ਹੀ ਰਾਜ਼ੀ-ਕੀ ਹੁੰਦੀ ਹੈ ਜੋ ਪੈغام ਤਾਲਾ ਲਗਾਉਣ ਅਤੇ ਖੋਲ੍ਹਣ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।
ਇਸਨੂੰ ਸੋਚੋ ਜਿਵੇਂ ਇੱਕ ਪੈਡਲਾਕ ਅਤੇ ਇੱਕ ਸਾਂਝੀ ਚਾਬੀ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਅਤੇ ਮੇਰੇ ਕੋਲ ਇੱਕੋ ਹੀ ਚਾਬੀ ਦੀ ਨਕਲ ਹੈ, ਮੈਂ ਇਕ ਡੱਬਾ ਤਾਲਾ ਲਗਾਕੇ ਤੁਹਾਨੂੰ ਭੇਜ ਸਕਦਾ ਹਾਂ ਅਤੇ ਤੁਸੀਂ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ। ਤਾਲਾ ਲਗਾਉਣਾ ਅਤੇ ਖੋਲ੍ਹਣਾ ਸਿੱਧਾ ਹੈ—ਜਦ ਤੱਕ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਉਹ ਚਾਬੀ ਰੱਖਦੇ ਹਾਂ।
ਮੁੱਦੇ ਸਪੱਸ਼ਟ ਹਨ: ਅਸੀਂ ਆਖ਼ਿਰਕਾਰ ਉਹ ਕੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰੀਏ? ਜੇ ਮੈਂ ਈਮੇਲ ਕਰਾਂ ਤਾਂ ਕੋਈ ਚੋਰੀ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਮੈਂ ਟੈਕਸਟ ਕਰਾਂ ਤਾਂ ਵੀ। ਜੇ ਮੈਂ ਉਸਨੂੰ ਸੀਲ ਕੀਤਾ ਲਿਫਾਫ਼ਾ ਭੇਜਾਂ, ਉਹ ਇੱਕ-ਦਫ਼ਾ ਲਈ ਚੰਗਾ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਇਹ ਹੌਲੀ, ਮਹਿੰਗਾ ਅਤੇ ਹਰ ਵੇਲੇ ਭਰੋਸੇਯੋਗ ਨਹੀਂ।
ਇਸ ਨਾਲ ਇੱਕ ਚਿਕਨ-ਅਤੇ-ਅੰਡਾ ਸਮੱਸਿਆ ਬਣਦੀ ਹੈ:
ਸਿਮੈਟ੍ਰਿਕ ਇਨਕ੍ਰਿਪਸ਼ਨ ਓਹਲੇ ਹੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਜਦੋਂ ਲੋਕ ਗਿਣਤੀ ਵਿੱਚ ਘੱਟ ਹੋਣ ਅਤੇ ਕੀ ਪਹਿਲਾਂ ਵੇਂਡਣ ਲਈ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੋਵੇ। ਪਰ ਖੁੱਲ੍ਹੇ ਇੰਟਰਨੈੱਟ 'ਤੇ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਟੁੱਟ ਜਾਂਦੀ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਇਕ ਵੈੱਬਸਾਈਟ ਨੂੰ ਲੱਖਾਂ ਵਿਜ਼ਟਰਾਂ ਨਾਲ ਨਿੱਜੀ ਜੁੜਾਵਾਂ ਦੀ ਲੋੜ ਹੈ। ਸਿਰਫ਼ ਸਿਮੈਟ੍ਰਿਕ ਕੀ-ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਲ, ਸਾਈਟ ਨੂੰ ਹਰ ਵਿਜ਼ਟਰ ਲਈ ਵੱਖ-ਵੱਖ ਸਾਂਝਾ ਕੀ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਮੁਹੱਈਆ ਕਰਨ ਦਾ ਸੁਰੱਖਿਅਤ ਤਰੀਕਾ ਲੱਭਣਾ ਹੋਵੇਗਾ। ਕੀ-ਸੰਖਿਆ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਸੰਭਾਲ (ਬਣਾਉਣਾ, ਸਟੋਰ ਕਰਨਾ, ਰੋਟੇਟ ਕਰਨਾ, ਰੱਦ ਕਰਨਾ) ਇੱਕ ਵੱਡਾ ਓਪਰੇਸ਼ਨਲ ਭਾਰ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਸਿਮੈਟ੍ਰਿਕ ਇਨਕ੍ਰਿਪਸ਼ਨ “ਬੁਰਾ” ਹੈ। ਇਹ ਉਹ ਕੰਮ ਬਹੁਤ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕਰਦਾ ਹੈ: ਵੱਡੀ ਮਾਤਰਾ ਦਾ ਤੇਜ਼ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਇਨਕ੍ਰਿਪਸ਼ਨ (ਜਿਵੇਂ HTTPS 'ਤੇ ਭੇਜਿਆ ਜਾਣ ਵਾਲਾ ਡਾਟਾ)। ਡਿਫੀ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਦਾ ਗਤੀ ਨਹੀਂ ਸੀ—ਮੁੱਦਾ ਇਹ ਸੀ ਕਿ ਅਜਿਹੇ ਅਣਜਾਣਿਆਂ ਲਈ ਸਾਂਝਾ ਕੀ ਪੂਰੇ ਤਰੀਕੇ ਨਾਲ ਸਥਾਪਤ ਕਰਨ ਦਾ ਪ੍ਰਯੋਗਕਾਰੀ ਤਰੀਕਾ ਨਹੀਂ ਸੀ।
1970 ਦੇ ਸ਼ੁਰੂਆਂ ਵਿੱਚ, ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ ਦਾ ਮਤਲਬ ਅਕਸਰ ਸਾਂਝੇ ਰਾਜ਼ ਹੀ ਸੀ। ਜੇ ਦੋ ਲੋਕ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸਨ, ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਰਾਜ਼ੀ-ਕੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ—ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਉਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਵੰਡਣਾ ਪੈਂਦਾ ਸੀ। ਇਹ ਧਾਰਣਾ ਛੋਟੇ, ਨਿਯੰਤਰਿਤ ਵਾਤਾਵਰਣਾਂ ਲਈ ਠੀਕ ਸੀ, ਪਰ ਅਜਿਹੇ ਦੁਨੀਆ ਲਈ ਜਿੱਥੇ ਅਣਜਾਣੇ ਲੋਕ ਸੁਰੱਖਿਅਤ ਸੰਚਾਰ ਕਰਨ ਚਾਹੁੰਦੇ ਹਨ, ਇਹ ਸਕੇਲ ਨਹੀਂ ਹੁੰਦੀ।
Whitfield Diffie ਇੱਕ ਨੌਜਵਾਨ ਖੋਜੀ ਸੀ ਜੋ ਨਿੱਜੀਪਣ ਅਤੇ ਉਸ ਸਮੇਂ ਦੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੀ ਹਦੀਅਤਾਂ ਤੋਂ ਰੁਚੀ ਰੱਖਦਾ ਸੀ। ਉਸਨੇ Stanford ਦੇ Martin Hellman ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਕੰਮ 'ਤੇ ਕੰਪਿਊਟਰ ਸੁਰੱਖਿਆ ਅਤੇ ਨੈੱਟਵਰਕਿੰਗ ਵਿੱਚ ਬਢ਼ ਰਹੀ ਅਕਾਦਮਿਕ ਦਿਲਚਸਪੀ ਨੇ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ—ਉਹ ਖੇਤਰ ਜੋ ਅਲੱਗ-ਅਲੱਗ ਪ੍ਰਣਾਲੀਆਂ ਤੋਂ ਜੁੜਦੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਵੱਲ ਬਦਲ ਰਹੇ ਸਨ।
ਇਹ ਕੋਈ ਇੱਕਲੌਤਾ-ਜੀਨੀਅਸ ਕਹਾਣੀ ਨਹੀਂ ਸੀ; ਇਹ ਠੀਕ ਸੋਚ ਦੇ ਮਿਲਣ ਦਾ ਸਮਾਂ ਸੀ: ਖੋਜੀ ਨੋਟਸ ਸਾਂਝੇ ਕਰ ਰਹੇ ਸਨ, ਵਿਚਾਰ-ਪਰਿਕਲਪਨ ਕਰ ਰਹੇ ਸਨ, ਅਤੇ ਉਹ “ਸਪੱਸ਼ਟ” ਰੋਕਾਂ ਨੂੰ ਚੁਣੌਤੀ ਦੇ ਰਹੇ ਸਨ ਜੋ ਕਈ ਦਸ਼ਕਾਂ ਤੋਂ ਸਵੀਕਾਰ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ।
Diffie ਅਤੇ Hellman ਦੀ ਖੋਜ ਇਹ ਸੀ ਕਿ ਇਨਕ੍ਰਿਪਸ਼ਨ ਇੱਕ ਸਾਂਝੇ ਰਾਜ਼ ਦੀ ਥਾਂ ਦੋ ਸਬੰਧਤ ਕੁੰਜੀਆਂ ਵਰਤ ਸਕਦਾ ਹੈ:
ਇਸਦੀ ਤਾਕਤ ਇਹ ਨਹੀਂ ਕਿ ਕੇਵਲ ਦੋ ਕੁੰਜੀਆਂ ਹਨ—ਇਸਦੇ ਵਿੱਚ ਇਹ ਹੈ ਕਿ ਓਹਨਾਂ ਦੇ ਵੱਖਰੇ ਕੰਮ ਹਨ। ਪਬਲਿਕ ਕੀ ਸੁਰੱਖਿਅਤ ਵੰਡ ਲਈ ਬਣੀ ਹੈ, ਜਦਕਿ ਪ੍ਰਾਈਵੇਟ ਕੀ ਨਿਆਂਤਨ ਅਤੇ ਖਾਸ ਹੋਣ ਲਈ।
ਇਸਨੇ ਕੀ-ਵੰਡਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਨਵਾਂ ਰੂਪ ਦਿੱਤਾ। ਇਕ ਰਾਜ਼ੀ-ਮੀਟਿੰਗ (ਜਾਂ ਭਰੋਸੇਯੋਗ ਕੋਰਿਅਰ) ਦੇ ਬਦਲੇ, ਤੁਸੀਂ ਆਪਣੀ ਪਬਲਿਕ ਕੀ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਵੀ ਸੁਰੱਖਿਆ ਬਣੀ ਰਹੇਗੀ।
ਇਹ ਬਦਲਾਅ—"ਸਾਨੂੰ ਪਹਿਲਾਂ ਮਿਲਣਾ ਹੀ ਚਾਹੀਦਾ ਹੈ" ਤੋਂ "ਅਸੀਂ ਖੁੱਲ੍ਹੀ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਵੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਾਂ"—ਉਹ ਨਿਯਮਾਤਮਿਕ ਬੁਨਿਆਦ ਹੈ ਜਿਸਨੇ ਬਾਅਦ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਵੈੱਬ ਬਰਾਉਜ਼ਿੰਗ, ਇਨਕ੍ਰਿਪਟਡ ਮੈਸੇਜਿੰਗ ਅਤੇ ਆਧੁਨਿਕ ਡਿਜ਼ੀਟਲ ਪਛਾਣ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਯਥਾਰਥ ਬਣਾਇਆ।
Diffie–Hellman (DH) ਇਕ ਚਾਲਾਕ ਤਰੀਕਾ ਹੈ ਜੋ ਦੋ ਲੋਕਾਂ ਨੂੰ ਇੱਕੋ ਹੀ ਸਾਂਝਾ ਰਾਜ਼ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ ਭਾਵੇਂ ਉਹਨਾਂ ਦੇ ਸੁਨੇਹੇ ਸਭ ਨੂੰ ਦਿਖ ਰਹੇ ਹੋਣ। ਉਸ ਸਾਂਝੇ ਰਾਜ਼ ਨੂੰ ਫਿਰ ਇੱਕ ਆਮ symmetric ਕੀ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ (ਉਹ "ਇੱਕ ਕੀ" ਵਾਲੀ ਕਿਸਮ) ਤਾਂ ਜੋ ਗੱਲਬਾਤ ਇਨਕ੍ਰਿਪਟ ਕੀਤੀ ਜਾਵੇ।
DH ਨੂੰ ਇੱਕ ਐਸੇ ਮਿਸ਼ਰਣ ਵਾਂਗ ਸੋਚੋ ਜੋ ਅੱਗੇ ਵੱਲ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਪਰ "ਅਨਮੀਸ਼" ਕਰਨਾ ਬਹੁਤ ਔਖਾ। ਰੇਸਪੀਸੀ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਇਕ ਐਵੇਸਡਰ ਸਾਰੀਆਂ ਪਬਲਿਕ ਪੈਰਾਮੀਟਰ ਅਤੇ ਦੋ ਐਕਸਚੇਂਜ਼ ਕੀਮਤਾਂ ਵੇਖ ਸਕਦਾ ਹੈ। ਜੋ ਉਹ ਕਰ ਨਹੀਂ ਸਕਦਾ ਉਹ ਇਹ ਹੈ ਕਿ ਉਹ ਕਿਸੇ ਵੀ ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਵੈਲਯੂ ਨੂੰ ਵਸਤੀ ਤੌਰ 'ਤੇ ਬਾਹਰ ਕੱਢ ਸਕੇ—ਜਾਂ ਸਿਰਫ ਉਨ੍ਹਾਂ ਪਬਲਿਕ ਟੁਕੜਿਆਂ ਤੋਂ ਹੀ ਸਾਂਝਾ ਰਾਜ਼ ਨਿਕਾਲ ਸਕੇ। ਚੰਗੇ ਪੈਰਾਮੀਟਰ ਹੋਣ ਤੇ ਇਸਨੂੰ ਉਲਟਣਾ ਅਸੰਭਵ ਜਿਹਾ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ।
DH ਖੁਦ ਪੈغام ਇਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ—ਇਹ ਉਹ ਸਾਂਝਾ ਕੀ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਤੇਜ਼, ਰੋਜ਼ਾਨਾ ਇਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ।
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਕੁਝ ਗਣਿਤੀ ਕਾਰਜ asymmetric ਹੁੰਦੇ ਹਨ: ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਕਰਨਾ ਆਸਾਨ ਹੈ, ਪਰ ਬਿਨਾਂ ਇੱਕ ਖ਼ਾਸ ਜਾਣਕਾਰੀ ਦੇ ਉਲਟ ਕਰਨਾ ਬਹੁਤ ਮুশਕਿਲ।
ਇੱਕ ਮਦਦਗਾਰ ਮਨੋ-Model "ਇੱਕ-ਤਰੀਕਾ ਫੰਕਸ਼ਨ" ਹੈ। ਇੱਕ ਮਸ਼ੀਨ ਸੋਚੋ ਜੋ ਇੱਕ ਇਨਪੁੱਟ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇਕ ਆਉਟਪੁੱਟ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਕੋਈ ਵੀ ਉਸਨੂੰ ਚਲਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਆਉਟਪੁੱਟ ਦੇ ਆਧਾਰ 'ਤੇ ਮੂਲ ਇਨਪੁੱਟ ਲੱਭਣਾ ਹਕੀਕਤ ਵਿੱਚ ਅਸੰਭਵ ਹੋ ਸਕਦਾ ਹੈ।
ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਵਿੱਚ ਅਸੀਂ ਮਸ਼ੀਨ ਦੀ ਗੁਪਤਤਾ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦੇ; ਅਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਾਂ ਕਿ ਇਸਨੂੰ ਉਲਟਣ ਲਈ ਇੱਕ ਕਠਨ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨੀ ਪਵੇਗੀ—ਇੱਕ ਐਸਾ ਕੰਮ ਜੋ ਵੱਡੇ ਹਿਸਾਬ ਨਾਲ ਹੀ ਸੰਭਵ ਹੈ।
“ਕਠਨ” ਦਾ ਮਤਲਬ ਸਦਾ ਲਈ ਅਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ:
ਇਸ ਲਈ ਸੁਰੱਖਿਆ ਅਨੁਮਾਨਾਂ (ਜੋ ਗਣਿਤਾਜ्ञ ਅਤੇ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਰ ਮੰਨਦੇ ਹਨ) ਅਤੇ ਅਸਲ ਦੁਨੀਆ ਦੀ ਪ੍ਰੈਕਟਿਸ (ਕੀ-ਸਾਈਜ਼, ਸੁਰੱਖਿਅਤ ਇਮਪਲੀਮੇਂਟੇਸ਼ਨ, ਅਪ-ਟੂ-ਡੇਟ ਸਟੈਂਡਰਡ) 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀ ਹੈ।
ਕਈ ਪਬਲਿਕ-ਕੀ ਗਣਿਤ "ਮੋਡੀਯੂਲੋ" ਨੰਬਰਾਂ 'ਤੇ ਹੁੰਦੀ ਹੈ—ਇਸਨੂੰ ਘੜੀ ਵਾਂਗ ਸੋਚੋ।
12-ਘੰਟੇ ਦੀ ਘੜੀ 'ਤੇ, ਜੇ 10 ਵਜੇ ਹਨ ਅਤੇ ਤੁਸੀਂ 5 ਘੰਟੇ ਜੋੜਦੇ ਹੋ, ਤਾਂ 15 ਨਹੀਂ ਹੋਵੇਗਾ; ਤੁਸੀਂ 3 'ਤੇ ਆ ਜਾਓਗੇ। ਉਹੀ wrap-around ਵਿਹਾਰ ਮੋਡੀਊਲਰ ਅੰਕਗਣਿਤ ਹੈ।
ਵੱਡੇ ਨੰਬਰਾਂ ਨਾਲ, ਦੁਹਰਾਏ ਹੋਏ "wrap-around" ਅਭਿਆਸ ਉਹ ਆਉਟਪੁੱਟ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਬਹੁਤ scrambled ਦਿੱਸਦਾ ਹੈ। ਅੱਗੇ ਕਰਨ (ਗਣਿਤ ਕਰਨ) ਤੇਜ਼ ਹੈ। ਉਲਟਣਾ (ਕੀ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਸੀ) ਬਿਨਾਂ ਗੁਪਤ ਸ਼ਾਰਟਕਟ—ਜਿਵੇਂ ਪ੍ਰਾਈਵੇਟ ਕੀ—ਬਹੁਤ धीਮਾ ਹੋ ਸਕਦਾ ਹੈ।
ਇਹ ਆਸਾਨ-ਅੱਗੇ, ਔਖਾ-ਪੀਛੇ ਦਾ ਗੈਪ ਕੀ ਐਕਸਚੇਂਜ ਅਤੇ ਡਿਜ਼ੀਟਲ ਸਾਈਨਚਰਾਂ ਦੇ ਇੰਜਣ ਦੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਲੱਕ ਆਈਕਨ ਵੇਖਦੇ ਹੋ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ HTTPS ਵਰਤ ਰਹੇ ਹੋ: ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਅਤੇ ਵੈੱਬਸਾਈਟ ਵਿਚਕਾਰ ਇਨਕ੍ਰਿਪਟਡ ਕੁਨੈਕਸ਼ਨ। ਜੇ ਹਰ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਹਰ ਸਰਵਰ ਨਾਲ ਪਹਿਲਾਂ ਤੋਂ ਸਾਂਝਾ ਕੀ ਰੱਖਣੀ ਪੈਂਦੀ, ਤਾਂ ਵੈੱਬ ਕਦੇ ਵੀ ਇਸ ਪੱਧਰ 'ਤੇ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ।
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ "ਪਹਿਲੀ ਮੁਲਾਕਾਤ" ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ ਹੈ: ਇਹ ਤੁਹਾਡੇ ਬ੍ਰਾਉਜ਼ਰ ਨੂੰ ਇੱਕ ਸਰਵਰ ਨਾਲ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਾਂਝਾ ਰਾਜ਼ ਸਥਾਪਿਤ ਕਰਨ ਦਿੰਦਾ ਜਿਸਨੂੰ ਉਹ ਪਹਿਲਾਂ ਨਹੀਂ ਮਿਲਿਆ।
ਆਧੁਨਿਕ TLS ਹੈਂਡਸ਼ੇਕ ਇੱਕ ਤੇਜ਼ ਮਾਲ-ਬਾਹੀ ਵਰਤਾਰਾ ਹੈ ਜੋ ਪ੍ਰਾਈਵੇਸੀ ਅਤੇ ਭਰੋਸਾ ਸੈਟ ਕਰਦਾ ਹੈ:
ਪਬਲਿਕ-ਕੀ ਕਾਰਜ ਥੋੜੇ ਸੁਸਤ ਹੁੰਦੇ ਹਨ ਤੇ ਉਹ ਐਗਰੀਮੈਂਟ ਅਤੇ ਪਰਮਾਣੀਕਰਨ ਲਈ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਨਾ ਕਿ ਵੱਡੀ ਮਾਤਰਾ ਦੇ ਡਾਟੇ ਲਈ। ਜਦੋਂ TLS ਸੈਸ਼ਨ ਕੀ ਸਥਾਪਿਤ ਕਰ ਲੈਂਦਾ ਹੈ, ਇਹ ਤੇਜ਼ ਸਿਮੈਟ੍ਰਿਕ ਇਨਕ੍ਰਿਪਸ਼ਨ (ਜਿਵੇਂ AES ਜਾਂ ChaCha20) 'ਤੇ ਬਦਲ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਭੇਜ ਰਿਹਾ ਸਾਰਾ ਡਾਟਾ ਰੱਖਿਆ ਜਾ ਸਕੇ—ਪੇਜ਼ ਰਿਕਵੈਸਟ, ਪਾਸਵਰਡ, ਕੂਕੀਜ਼ ਆਦਿ।
ਜੇ ਤੁਸੀਂ HTTP ਅਤੇ HTTPS ਦੇ ਬਰਾਬਰੀ ਵਿਚਾਰ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਵੇਖੋ /blog/https-vs-http.
ਇੱਕ ਡਿਜ਼ੀਟਲ ਦਸਤਖ਼ਤ ਉਹ ਪਬਲਿਕ-ਕੀ ਟੂਲ ਹੈ ਜੋ ਇਕ ਪੈغام ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਆਪਣੀ ਪ੍ਰਾਈਵੇਟ ਕੀ ਨਾਲ ਫ਼ਾਈਲ ਜਾਂ ਪੈغام 'ਤੇ ਸਾਈਨ ਕਰਦਾ ਹੈ, ਹਰ ਕੋਈ ਮਿਲੀ-ਜੁਲੀ ਪਬਲਿਕ ਕੀ ਵਰਤ ਕੇ ਉਸ ਸਾਈਨ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਵੈਧ ਸਾਈਨ ਦੋ ਗੱਲਾਂ ਸਾਬਤ ਕਰਦਾ ਹੈ:
ਇਹ ਦੋ ਆਈਡੀਆਅਕਸ ਅਕਸਰ ਮਿਲਦੇ-ਜੁਲਦੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਪਰ ਫਰਕ ਹੈ:
ਤੁਸੀਂ ਇੱਕ ਨੂੰ ਬਿਨਾਂ ਦੂਜੇ ਦੇ ਵੀ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਣ ਲਈ, ਇਕ ਪਬਲਿਕ ਘੋਸ਼ਣਾ ਸਾਈਨ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ (ਤਾਂ ਜੋ ਲੋਕ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਣ) ਪਰ ਇਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕੀਤੀ ਜਾਏ (ਕਿਉਂਕਿ ਇਹ ਸਭ ਨੂੰ ਪੜ੍ਹਨੀ ਹੈ)।
ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਈ ਰਾਜ਼ ਸਾਂਝਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਸਾਇਨਰ ਪ੍ਰਾਈਵੇਟ ਕੀ ਨਿੱਜੀ ਰੱਖਦਾ ਹੈ, ਜਦਕਿ ਪਬਲਿਕ ਕੀ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਵੰਡ—ਸਾਈਨ ਕਰਨ ਲਈ ਪ੍ਰਾਈਵੇਟ, ਵੈਰੀਫਾਈ ਕਰਨ ਲਈ ਪਬਲਿਕ—ਅਣਜਾਣਿਆਂ ਨੂੰ ਸਕੇਲ 'ਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਤਸਦੀਕ ਕਰਨ ਦਿੰਦੀ ਹੈ ਬਿਨਾਂ ਕਿਸੇ ਪਹਿਲਾਂ ਤੋਂ ਤੈਅ ਕੀਤੇ ਗਏ ਪਾਸਵਰਡ ਜਾਂ ਰਾਜ਼ ਦੇ।
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ "ਅਸੀਂ ਰਾਜ਼ ਕਿਵੇਂ ਸਾਂਝੇ ਕਰੀਏ" ਦਾ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦੀ ਹੈ, ਪਰ ਇਕ ਹੋਰ ਸਵਾਲ ਛੱਡਦੀ ਹੈ: ਇਹ ਕੀ ਕਿਸਦੀ ਹੈ, ਅਸਲ ਵਿੱਚ? ਇਕ ਪਬਲਿਕ ਕੀ ਖੁਦ ਇਕ ਲੰਬਾ ਨੰਬਰ ਹੀ ਹੈ। ਤੁਹਾਨੂੰ ਇਸ ਕੀ ਨੂੰ ਕਿਸੇ ਅਸਲੀ-ਦੁਨੀਆ ਦੀ ਪਛਾਣ ਨਾਲ ਜੋੜਨ ਦਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ—ਜਿਵੇਂ "ਮੇਰਾ ਬੈਂਕ" ਜਾਂ "ਇਸ ਕੰਪਨੀ ਦਾ ਈਮੇਲ ਸਰਵਰ"।
ਇੱਕ ਡਿਜ਼ੀਟਲ ਸਰਟੀਫਿਕੇਟ ਇਕ ਸਾਈਨ ਕੀਤੀ ਦਸਤਾਵੇਜ਼ ਹੈ ਜੋ ਅਰਥਾਤ ਕਹਿੰਦੀ ਹੈ: "ਇਹ ਪਬਲਿਕ ਕੀ ਇਸ ਪਛਾਣ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ"। ਇਸ ਵਿੱਚ ਸਾਈਟ ਜਾਂ ਸੰਸਥਾ ਦਾ ਨਾਂ (ਅਤੇ ਹੋਰ ਵੇਰਵੇ), ਪਬਲਿਕ ਕੀ, ਅਤੇ ਮੁਦਤ-ਅੰਤੁ ਸ਼ਾਮਿਲ ਹੁੰਦੇ ਹਨ। ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਸਾਈਨ ਹੈ: ਇਕ ਭਰੋਸੇਯੋਗ ਪਾਰਟੀ ਸਰਟੀਫਿਕੇਟ 'ਤੇ ਦਸਤਖ਼ਤ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਜਾਂਚ ਸਕੇ ਕਿ ਇਸਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ।
ਉਹ ਭਰੋਸੇਯੋਗ ਪਾਰਟੀ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ Certificate Authority (CA) ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡਾ ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਭਰੋਸੇਯੋਗ CA ਰੂਟਸ ਦੀ ਇੰਸਟਾਲ ਕੀਤੀ ਸੂਚੀ ਨਾਲ ਆਉਂਦੇ ਹਨ। ਜਦ ਤੁਸੀਂ ਕਿਸੇ ਸਾਈਟ 'ਤੇ ਜਾਂਦੇ ਹੋ, ਸਾਈਟ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਮੱਧ-ਸਰਟੀਫਿਕੇਟ (intermediates) ਪੇਸ਼ ਕਰਦੀ ਹੈ, ਜੋ ਇੱਕ ਟ੍ਰਸਟ ਚੇਨ ਬਣਾਉਂਦੇ ਹਨ ਜਿਹੜਾ ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਵੱਲੋਂ ਪਹਿਲਾਂ ਤੋਂ ਟਰੱਸਟਡ ਰੂਟ CA ਤੱਕ ਪੈਂਦਾ ਹੈ।
ਜਦ ਤੁਸੀਂ ਆਪਣੇ ਬੈਂਕ ਦਾ URL ਟਾਈਪ ਕਰਦੇ ਹੋ ਅਤੇ ਲੱਕ ਆਈਕਨ ਵੇਖਦੇ ਹੋ, ਤੁਹਾਡੇ ਬ੍ਰਾਉਜ਼ਰ ਨੇ ਇਹ ਜਾਂਚ ਕੀਤਾ:
ਜੇ ਇਹ ਚੈੱਕ ਪਾਸ ਹੋ ਜਾਂਦੇ ਹਨ, TLS ਬਿਨਾਂ ਡਰ ਦੇ ਉਸ ਪਬਲਿਕ ਕੀ ਨੂੰ ਪਰਮਾਣਿਕਰਨ ਅਤੇ ਇਨਕ੍ਰਿਪਸ਼ਨ ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਵਰਤ ਸਕਦਾ ਹੈ।
PKI ਪੂਰਾ ਤੌਰ 'ਤੇ ਸੰਪੂਰਨ ਨਹੀਂ ਹੈ। CAs ਗਲਤੀਆਂ ਕਰ ਸਕਦੇ ਹਨ ਜਾਂ ਸਮਝੌਤਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਗਲਤ-ਜਾਰੀ (mis-issuance) ਹੁੰਦੀ ਹੈ (ਗਲਤ ਪਾਰਟੀ ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਹੋਣਾ). ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਮਿਆਦ ਹੈ, ਜੋ ਸੁਰੱਖਿਆ ਲਈ ਚੰਗੀ ਗੱਲ ਹੈ ਪਰ ਜੇ ਨਵੀਨੀਕਰਨ ਨਾ ਹੋਵੇ ਤਾਂ ਪਹੁੰਚ ਟੁੱਟ ਸਕਦੀ ਹੈ। ਰਿਵੋਕੇਸ਼ਨ (ਦੁਨੀਆ ਨੂੰ ਦੱਸਣਾ ਕਿ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਹੁਣ ਭਰੋਸੇਯੋਗ ਨਹੀਂ) ਵੀ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਜটਿਲ ਹੈ, ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ ਹਮੇਸ਼ਾਂ ਰਿਵੋਕੇਸ਼ਨ ਨੂੰ ਇੱਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਨਹੀਂ ਕਰਦੇ।
End-to-end encrypted (E2EE) ਮੈਸੇਜਿੰਗ ਇੱਕ ਸਧਾਰਣ ਵਾਅਦਾ ਕਰਦੀ ਹੈ: ਗੱਲਬਾਤ ਵਿੱਚ ਕੇਵਲ ਉਹੀ ਲੋਕ ਸੁਨੇਹੇ ਪੜ੍ਹ ਸਕਣ ਜੋ ਉਸ ਵਿਚ ਹਨ। ਨਾ ਐਪ ਪ੍ਰਦਾਤਾ, ਨਾ ਤੁਹਾਡਾ ਮੋਬਾਈਲ ਕੈਰੀਅਰ, ਨਾ ਕੋਈ ਨੈੱਟਵਰਕ ਵੇਖਣ ਵਾਲਾ।
ਜਿਆਦਾਤਰ ਆਧੁਨਿਕ ਚੈਟ ਐਪ ਤਿੰਨ ਮਕਸਦਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀਆਂ ਹਨ:
ਇਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਕੁੰਜੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਪਰ ਦੋ ਅਣਜਾਣੇ ਲੋਕਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਸਾਂਝਾ ਰਾਜ਼ੀ-ਕੀ ਸਾਂਝੀ ਨਾ ਕਰਨੀ ਪਵੇ—ਨਹੀਂ ਤਾਂ ਅਸੀਂ ਮੁੜ ਉਸੇ ਕੀ-ਵੰਡਣ ਸਮੱਸਿਆ ਵਿੱਚ ਆ ਜਾਂਦੇ ਹਾਂ।
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਸੈਟਅਪ ਕਦਮ ਹੱਲ ਕਰਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੇ E2EE ਸਿਸਟਮਾਂ ਵਿੱਚ, ਕਲਾਇੰਟ ਪਬਲਿਕ-ਕੀ ਅਧਾਰਿਤ ਐਕਸਚੇਂਜ (Diffie–Hellman ਦੀ ਰੂਹ ਵਿੱਚ) ਵਰਤਦੇ ਹਨ ਤਾਂ ਜੋ ਬਿਨਾਂ ਭਰੋਸੇਯੋਗ ਨੈੱਟਵਰਕ ਦੇ ਸਾਂਝੇ ਰਾਜ਼ ਬਣਾਏ ਜਾ ਸਕਣ। ਉਹ ਰਾਜ਼ ਫਿਰ ਤੇਜ਼ ਸਿਮੈਟ੍ਰਿਕ ਇਨਕ੍ਰਿਪਸ਼ਨ ਲਈ ਫੀਡ ਹੁੰਦੇ ਹਨ।
ਫਾਰਵਰਡ ਸਿਕ੍ਰੈਸੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਐਪ ਇਕ ਹੀ ਲੰਬੇ ਸਮੇਂ ਵਾਲੀ ਕੁੰਜੀ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਰਹਿੰਦੀ। ਇਸਦੀ ਥਾਂ, ਇਹ ਕੁੰਜੀਆਂ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਤਾਜ਼ਾ ਕਰਦਾ ਹੈ—ਅਕਸਰ ਸੈਸ਼ਨ-ਵਾਰ ਜਾਂ ਹਰ-ਸੁਨੇਹੇ-ਵਾਰ—ਤਾਂ ਜੋ ਇੱਕ ਕੁੰਜੀ ਦੀ ਚੋਰੀ ਸਾਰੇ ਇਤਿਹਾਸ ਨੂੰ ਖੋਲ੍ਹ ਨਾ ਸਕੇ।
ਇਸ ਲਈ “ਅੱਜ ਫੋਨ ਚੋਰੀ ਹੋ ਜਾਵੇ, ਕੱਲ੍ਹ ਸਾਲਾਂ ਦੀਆਂ ਗੱਲਾਂ ਡਿਕ੍ਰਿਪਟ ਹੋ ਜਾਣ” ਜਿਵੇਂ ਹਾਲਤਾਂ ਜ਼ਿਆਦਾ ਮੁਸ਼ਕਿਲ ਬਣ ਜਾਂਦੀਆਂ ਹਨ ਜੇ ਫਾਰਵਰਡ ਸਿਕ੍ਰੈਸੀ ਠੀਕ ਤਰ੍ਹਾਂ ਕੀਤੀ ਗਈ ਹੋਵੇ।
ਮਜ਼ਬੂਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੇ ਬਾਵਜੂਦ, ਹਕੀਕਤ ਵਿੱਛ ਰੁਕਾਵਟ ਹਨ:
ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਸੁਰੱਖਿਅਤ ਮੈਸੇਜਿੰਗ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਕੀ ਐਕਸਚੇਂਜ ਅਤੇ ਕੀ ਪ੍ਰਬੰਧਨ ਦੀ ਕਹਾਣੀ ਹੈ—ਕਿਉਂਕਿ ਇਹ ਹੀ ਉਹ ਗੱਲ ਹੈ ਜੋ "ਇਨਕ੍ਰਿਪਟਡ" ਨੂੰ "ਨਿੱਜੀ, ਭਾਲ ਉਪਰੋਂ ਬਿਨਾਂ" ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਡਿਜ਼ੀਟਲ ਪਛਾਣ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਇੱਕ ਸੇਵਾ ਵਰਤਦਿਆਂ ਪੇਸ਼ ਕਰਦੇ ਹੋ: ਤੁਹਾਡਾ ਖਾਤਾ, ਲੌਗਿਨ, ਅਤੇ संकेत ਜੋ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਇਹ ਵਾਸਤਵ ਵਿੱਚ ਤੁਸੀਂ ਹੋ (ਨਹੀਂ ਕੋਈ ਜਿਸਨੇ ਪਾਸਵਰਡ ਚੁਰੀ ਕੀਤਾ)। ਸਾਲਾਂ ਤੱਕ, ਬਹੁਤ ਸਿਸਟਮ ਪਾਸਵਰਡ ਨੂੰ ਇਸ ਪ੍ਰਮਾਣ ਲਈ ਵਰਤਦੇ ਰਹੇ—ਸਰਲ, ਪਰ ਪਿਛੋਂ ਫਿਸ਼ਿੰਗ, ਰੀਉਜ਼, ਲੀਕ ਜਾਂ ਬ੍ਰੂਟ-ਫੋਰਸ ਲਈ ਅਸਾਨ।
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਇੱਕ ਹੋਰ ਤਰੀਕ ਬੰਦੋਬਸਤ ਪੇਸ਼ ਕਰਦੀ ਹੈ: ਪਾਸਵਰਡ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇਹ ਸਾਬਤ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਇਕ ਪ੍ਰਾਈਵੇਟ ਕੀ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ। ਸੇਵਾ ਤੁਹਾਡੀ ਪਬਲਿਕ ਕੀ ਸਟੋਰ ਕਰ ਸਕਦੀ ਹੈ, ਜਦਕਿ ਪ੍ਰਾਈਵੇਟ ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਰਹਿੰਦੀ ਹੈ।
ਕੀ-ਅਧਾਰਤ ਲੌਗਿਨ ਵਿੱਚ, ਸਰਵਿਸ ਇੱਕ ਚੈਲੰਜ ਭੇਜਦੀ ਹੈ (ਇੱਕ ਰੈਂਡਮ ਡੇਟਾ). ਤੁਹਾਡੀ ਡਿਵਾਈਸ ਉਸਨੂੰ ਆਪਣੀ ਪ੍ਰਾਈਵੇਟ ਕੀ ਨਾਲ ਸਾਈਨ ਕਰਦੀ ਹੈ। ਸੇਵਾ ਸਾਈਨ ਦੀ ਪੁਸ਼ਟੀ ਤੁਹਾਡੀ ਪਬਲਿਕ ਕੀ ਨਾਲ ਕਰਦੀ ਹੈ। ਕੋਈ ਪਾਸਵਰਡ ਨੈੱਟਵਰਕ 'ਤੇ ਨਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ, ਅਤੇ ਲੌਗਿਨ ਫਾਰਮ ਤੋਂ ਚੋਰੀ ਕਰਨ ਲਈ ਕੁਝ ਵੀ ਮੁੜ ਵਰਤਣ-ਯੋਗ ਨਹੀਂ ਹੁੰਦਾ।
ਇਹ ਵਿਚਾਰ ਆਧੁਨਿਕ "passwordless" UX ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ:
ਪਬਲਿਕ-ਕੀ ਪਛਾਣ ਮਸ਼ੀਨਾਂ ਲਈ ਵੀ ਕੰਮ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਣ ਲਈ, ਇੱਕ API ਲਾਈਨ ਕਸਟਮਰ ਆਪਣੀ ਪ੍ਰਾਈਵੇਟ ਕੀ ਨਾਲ ਬੇਨਤੀ 'ਤੇ ਸਾਈਨ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਉਹਨੂੰ ਪਬਲਿਕ ਕੀ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰਦਾ ਹੈ—ਜਦ ਸਮੇਂ ਸੇਵਾ-ਟੂ-ਸੇਵਾ ਪ੍ਰਮਾਣਿਕਰਨ ਲਈ ਬਹੁਤ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਸਾਂਝੇ API ਸੀਕ੍ਰੇਟਸ ਘੁਮਾਉਣਾ ਔਖਾ ਅਤੇ ਲੀਕ ਹੋਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਅਸਲ ਦੀ ਤਰਫ ਇੱਕ ਡੀਪ ਡਾਈਵ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਵੇਖੋ /blog/passwordless-authentication.
ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਤਾਕਤਵਰ ਹੈ, ਪਰ ਇਹ ਜਾਦੂ ਨਹੀਂ। ਬਹੁਤ ਸਾਰੇ ਅਸਲ-ਦੁਨੀਆ ਫੇਲ ਮੇਥਮੈਟਿਕਸ ਦੇ ਟੁੱਟਣ ਕਾਰਨ ਨਹੀਂ ਹੁੰਦੇ, ਬਲਕਿ ਇਨ੍ਹਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣੀ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਕਾਰਨ ਹੁੰਦੇ ਹਨ।
ਕਮਜ਼ੋਰ ਰੈਂਡਮਨੈਸ ਸਭ ਕੁਝ ਖ਼ਤਮ ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਇਕ ਡਿਵਾਈਸ ਅਣਪੇਸ਼ੀਹ ਨੋਨਸ ਜਾਂ ਕੁੰਜੀਆਂ ਜਨਰੇਟ ਕਰਦਾ ਹੈ (ਖਾਸ ਕਰ ਕੇ ਬੂਟ ਦੇ ਸ਼ੁਰੂ 'ਤੇ, ਵਿਯਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਵਿੱਚ, ਜਾਂ ਸੀਮਤ IoT ਹਾਰਡਵੇਅਰ), ਹਮਲਾਵਰ ਰਹੱਸ ਸਹੀ ਤੌਰ 'ਤੇ ਠੀਕ ਕਰ ਸਕਦਾ ਹੈ।
ਖਰਾਬ ਇਮਪਲੀਮੇਂਟੇਸ਼ਨ ਵੀ ਵਾਰ-ਵਾਰ ਕਾਰਨ ਬਣਦੀ ਹੈ: ਪੁਰਾਣੇ ਅਲਗੋਰਿਦਮ ਵਰਤਣਾ, ਸਰਟੀਫਿਕੇਟ ਵੈਰੀਫਿਕੇਸ਼ਨ ਛੱਡ ਦੇਣਾ, ਕਮਜ਼ੋਰ ਪੈਰਾਮੀਟਰ ਮਨਜ਼ੂਰ ਕਰਨਾ, ਜਾਂ ਐਰਰਸ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕਰਨਾ। ਛੋਟੀ "ਆਸਤੀ" ਛੂਟ—ਜਿਵੇਂ ਡੀਬੱਗ ਕਰਨ ਲਈ TLS ਚੈਕ ਬੰਦ ਕਰਨਾ—ਅਕਸਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚਲ ਪੈਂਦੀ ਹੈ।
ਫਿਸ਼ਿੰਗ ਅਤੇ ਸੋਸ਼ਲ ਇੰਜਨੀਅਰਿੰਗ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰ ਦਿੰਦੇ ਹਨ। ਜੇ ਯੂਜ਼ਰ ਨੂੰ ਇਸਤੇਮਾਲ ਕਰਨ ਲਈ ਯਕੀਨ ਹੀ ਕਰਾਇਆ ਗਿਆ ਕਿ ਉਹ ਲੌਗਿਨ ਮਨਜ਼ੂਰ ਕਰੇ, ਰਿਕਵਰੀ ਕੋਡ ਦਿੰਦੇ, ਜਾਂ ਮਾਲਵੇਅਰ ਇੰਸਟਾਲ ਕਰਦੇ ਹਨ, ਤਗੜੀਆਂ ਕੁੰਜੀਆਂ ਵੀ ਫਾਇਦਾ ਨਹੀਂ ਕਰਦੀਆਂ।
ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀਆਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਉਹ ਆਸਾਨੀ ਨਾਲ ਨਕਲ ਨਾ ਹੋ ਸਕਣ (ਆਦਰਸ਼ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹਾਰਡਵੇਅਰ ਵਿੱਚ), ਅਤੇ ਰੇਸਟ 'ਤੇ ਇਨਕ੍ਰਿਪਟ ਕੀਤੀਆਂ ਜਾਣ। ਟੀਮਾਂ ਨੂੰ ਬੈਕਅਪ, ਰੋਟੇਸ਼ਨ, ਅਤੇ ਰਿਵੋਕੇਸ਼ਨ ਲਈ ਯੋਜਨਾ ਬਣਾਉਣੀ ਚਾਹੀਦੀ ਹੈ—ਕਿਉਂਕਿ ਕੁੰਜੀਆਂ ਖੋ ਜਾਦੀਆਂ ਹਨ, ਡਿਵਾਈਸ ਚੋਰੀ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਲੋਕ ਕੰਪਨੀਆਂ ਛੱਡ ਕੇ ਜਾਂਦੇ ਹਨ।
ਜੇ ਸੁਰੱਖਿਅਤ ਪ੍ਰਵਾਹ ਗੁੰਝਲਦਾਰ ਹਨ, ਤਾਂ ਲੋਕ ਉਨ੍ਹਾਂ ਤੋਂ ਬਚਣ ਲਈ ਰਾਹ ਲੱਭਣਗੇ: ਖਾਤੇ ਸਾਂਝੇ ਕਰਨਾ, ਡਿਵਾਈਸ ਦੁਹਰਾਉਣਾ, ਚੇਤਾਵਨੀ ਅਨਦੇਖੀ ਕਰਨਾ, ਜਾਂ ਰਿਕਵਰੀ ਕੋਡ ਅਣਸੁਰੱਖਿਅਤ ਥਾਂ 'ਤੇ ਰੱਖਣਾ। ਚੰਗਾ ਸੁਰੱਖਿਆ ਡਿਜ਼ਾਇਨ "ਸੁਰੱਖਿਅਤ ਕਾਰਵਾਈ" ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਸੋਫਟਵੇਅਰ ਬਣਾ ਅਤੇ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸਭ ਤੋਂ ਵੱਡਾ ਖਤਰਾ ਅਕਸਰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਨਹੀਂ—ਇਹ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਅਸਮਾਨ ਕਨਫਿਗਰੇਸ਼ਨ ਹੁੰਦੇ ਹਨ। Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੇਜ਼ੀ ਨਾਲ ਡਿਲਿਵਰੀ ਵਿੱਚ ਸਹਾਇਕ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹੀ ਪਬਲਿਕ-ਕੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦੇ ਹਨ:
ਸਾਰ: ਤੇਜ਼ ਤਿਆਰ ਕਰਨ ਨਾਲ ਨਿਯਮ ਨਹੀਂ ਬਦਲਦੇ—Diffie ਦੇ ਵਿਚਾਰ ਹਨੋ ਹੀ ਉਹ ਬੁਨਿਆਦ ਜੋ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਪਹਿਲੀ ਵਾਰੀ ਇੱਕ ਯੂਜ਼ਰ ਨਾਲ ਭਰੋਸਾ ਕਮਾਉਣ ਦਿੰਦੇ ਹਨ।
Diffie ਦੀ ਖੋਜ ਸਿਰਫ਼ ਇਕ ਨਵਾਂ ਸੰਦ ਨਹੀਂ ਸੀ—ਇਸਨੇ ਸੁਰੱਖਿਆ ਦੀ ਮੁੱਲ-ਧਾਰਣਾ ਬਦਲੀ: "ਸanu ਪਹਿਲਾਂ ਮਿਲਣਾ ਜਰੂਰੀ ਹੈ" ਤੋਂ "ਅਸੀਂ ਖੁੱਲ੍ਹੇ ਨੈੱਟਵਰਕ 'ਤੇ ਵੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਾਂ"। ਇਹ ਇੱਕੋ ਬਦਲਾਅ ਨੇ Milliarden ਡਿਵਾਇਸਾਂ ਅਤੇ ਅਣਜਾਣਿਆਂ ਲਈ ਰਾਜ਼ ਬਣਾਉਣਾ, ਪਛਾਣ ਸਾਬਤ ਕਰਨਾ ਅਤੇ ਇੰਟਰਨੈੱਟ ਪੱਧਰ 'ਤੇ ਭਰੋਸਾ ਬਣਾਉਣਾ ਸੰਭਵ ਕੀਤਾ।
ਅਸਲ Diffie–Hellman ਅਜੇ ਵੀ ਬੁਨਿਆਦ ਹੈ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਮੌਜੂਦਾ ਸਿਸਟਮ ਅਪਡੇਟ ਕੀਤੇ ਸੰਸਕਰਨ ਵਰਤਦੇ ਹਨ।
Elliptic-curve Diffie–Hellman (ECDH) ਉਹੀ "ਜਨਤਾ ਵਿੱਚ ਸਾਂਝਾ ਰਾਜ਼" ਨਿਰਧਾਰਨ ਕਰਨ ਦਾ ਲਕੜੀ ਰੱਖਦਾ ਹੈ ਪਰ ਛੋਟੀ ਕੁੰਜੀਆਂ ਅਤੇ ਤੇਜ਼ ਕਾਰਵਾਈ ਵਰਤਦਾ ਹੈ। RSA, ਜੋ Diffie ਦੇ ਕੰਮ ਤੋਂ ਕੁਝ ਸਮੇਂ ਬਾਅਦ ਵਿਕਸਿਤ ਹੋਇਆ, ਸ਼ੁਰੂ ਵਿੱਚ ਇਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਸਾਈਨਿੰਗ ਦੋਵਾਂ ਲਈ ਪ੍ਰਸਿੱਧ ਹੋਇਆ; ਅੱਜ ਇਹ ਹੋਰ ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ elliptic-curve ਸਾਈਨਚਰਾਂ ਅਤੇ ECDH ਆਮ ਹਨ।
ਅਕਸਰ ਹਰ ਅਸਲੀ-ਦੁਨੀਆ ਡਿਪਲੋਇਮੈਂਟ ਇੱਕ ਹਾਈਬ੍ਰਿਡ ਸਕੀਮ ਹੈ: ਪਬਲਿਕ-ਕੀ ਵਿਧੀਆਂ ਹੈਂਡਸ਼ੇਕ (ਪਰਮਾਣੀਕਰਨ ਅਤੇ ਕੀ-ਸਹਿਮਤੀ) ਲਈ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਤੇਜ਼ ਸਿਮੈਟ੍ਰਿਕ ਇਨਕ੍ਰਿਪਸ਼ਨ ਵੱਧ ਡਾਟਾ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ। ਇਹ ਨਮੂਨਾ HTTPS ਨੂੰ ਸੁਰੱਖਿਅਤ ਅਤੇ ਤੇਜ਼ ਦੋਹਾਂ ਬਣਾਉਂਦਾ ਹੈ।
ਭਵਿੱਖ ਦੇ quantum ਕੰਪਿਊਟਰ ਅੱਜ-ਵਰਤੋਂ ਵਾਲੀਆਂ ਪਬਲਿਕ-ਕੀ ਤਕਨੀਕਾਂ (ਖਾਸ ਕਰਕੇ ਫੈਕਟੋਰਿੰਗ ਅਤੇ ਡਿਸਕ੍ਰਿਟ ਲਾਗਸ 'ਤੇ ਆਧਾਰਤ) ਨੂੰ ਕਮਜ਼ੋਰ ਕਰ ਸਕਦੇ ਹਨ। ਪ੍ਰਯੋਗਕਾਰੀ ਦਿਸ਼ਾ ਇਹ ਹੈ: "ਨਵੇਂ ਵਿਕਲਪ ਸ਼ਾਮਿਲ ਕਰੋ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਮਾਈਗਰੇਟ ਕਰੋ," ਨ ਕੀ ਤੁਰੰਤ ਤਬਦੀਲੀ। ਬਹੁਤ ਸਿਸਟਮ ਪੋਸਟ-ਕਵਾਂਟਮ ਕੀ-ਐਕਸਚੇਂਜ ਅਤੇ ਸਾਈਨਚਰਾਂ ਦਾ ਟੈਸਟ ਕਰ ਰਹੇ ਹਨ ਅਤੇ ਹਾਈਬ੍ਰਿਡ ਡਿਜ਼ਾਇਨ ਰੱਖਦੇ ਹਨ ਤਾਂ ਜੋ ਨਵੇਂ ਸੁਰੱਖਿਆ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਜਾ ਸਕਣ ਬਿਨਾਂ ਸਾਰੇ ਕੁਝ ਇਕ ਅਲਗੋਰਿਦਮ 'ਤੇ ਨਿਰਭਰ ਕੀਤੇ।
ਚਾਹੇ ਅਲਗੋਰਿਦਮ ਬਦਲਣ, ਮੁੱਖ ਸਮੱਸਿਆ ਏਕੋ ਹੀ ਰਹੇਗੀ: ਉਹਨਾਂ ਪਾਰਟੀਆਂ ਵਿੱਚ ਰਾਜ਼ ਅਤੇ ਭਰੋਸਾ ਦਾ ਲੈਣ-ਦੇਣ ਜਿਹੜੀਆਂ ਪਹਿਲਾਂ ਕਦੇ ਮਿਲੀਆਂ ਹੀ ਨਹੀਂ—ਤੇਜ਼, ਵਿਸ਼ਵ-ਪੱਧਰ 'ਤੇ, ਅਤੇ ਘੱਟਤਮ ਉਪਭੋਗੀ ਰੁਕਾਵਟਾਂ ਨਾਲ।
ਸਾਰ: ਪਬਲਿਕ-ਕੀ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਪਹਿਲੀ ਮੁਲਾਕਾਤ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀ ਹੈ; ਹਾਈਬ੍ਰਿਡ ਇਸਨੂੰ ਸਕੇਲ 'ਤੇ ਲਿਆਉਂਦੇ ਹਨ; ਅਗਲਾ ਯੁੱਗ ਧੀਰੇ-ਧੀਰੇ ਵਿਕਾਸ ਹੈ।
ਅਗਲੇ ਪੜ੍ਹਨ ਲਈ: /blog/diffie-hellman-explained, /blog/tls-https-basics, /blog/pki-certificates, /blog/post-quantum-crypto-primer
Symmetric encryption uses one shared secret key to encrypt and decrypt. It’s fast and great for bulk data, but it has a setup problem: you need a safe way to share that key first.
Public-key cryptography splits roles into a public key (shareable) and a private key (kept secret), which makes “secure first contact” possible without a pre-shared secret.
It solved the key-distribution problem: two strangers can start secure communication over an observable network without meeting to exchange a secret key.
That shift is what makes internet-scale security practical for:
Diffie–Hellman (DH) is a method to create a shared secret over a public channel.
In practice:
DH itself doesn’t encrypt your messages; it helps you agree on the key that will.
Not by itself. Plain DH provides key agreement, but it doesn’t prove who you’re talking to.
To prevent man-in-the-middle attacks, DH is typically paired with authentication, such as:
TLS uses public-key cryptography mainly for authentication and key agreement during the handshake, then switches to symmetric keys for the actual data.
A simplified view:
A digital signature lets someone prove they authored something and that it wasn’t changed.
Typical uses include:
You verify with a public key; only the holder of the private key can create a valid signature.
A certificate binds a public key to an identity (like a website name) via a signature from a trusted issuer.
Browsers trust certificates because they can build a chain from the site certificate through intermediates up to a trusted root CA installed in the OS/browser.
Operationally, this is why certificate renewal, correct hostname configuration, and proper validation are critical for HTTPS to work reliably.
End-to-end encrypted apps still need a way to establish shared keys between devices that haven’t exchanged secrets before.
They commonly use DH-style exchanges (often with elliptic curves) to:
Passkeys (FIDO2/WebAuthn) replace shared-password login with a challenge–response signature.
In practice:
This reduces phishing and credential reuse risk because there’s no reusable secret typed into a website form.
Most failures are around implementation and operations, not the core math.
Common pitfalls:
Practical rule: use vetted libraries and defaults, and treat key management as a first-class system requirement.