AES-256 ਬਨਾਮ OFB: ਪੂਰਾ VPN ਸਾਈਫਰ ਢਾਂਚਾ ਚੁਣੋ
ਬਲਾਕ ਸਾਈਫਰ, ਕੁੰਜੀ ਆਕਾਰ ਅਤੇ ਮੋਡ ਵੱਖਰੀਆਂ ਚੋਣਾਂ ਹਨ। ਗੋਪਨੀਯਤਾ ਅਤੇ ਅਖੰਡਤਾ ਦਾ ਇਕੱਠੇ ਮੁਲਾਂਕਣ ਕਰੋ, ਫਿਰ ਸਮਰਥਿਤ ਚੈਨਲ ਨੀਤੀ ਦੀ ਪਾਲਣਾ ਕਰੋ।
AES-256 ਅਤੇ OFB ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਸਾਈਫਰ ਸਮੀਖਿਆ ਇੱਥੇ ਹੀ ਗਲਤ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇਨ੍ਹਾਂ ਨੂੰ ਮੁਕਾਬਲੇ ਵਾਲੇ ਵਿਕਲਪ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਕੁੰਜੀ ਆਕਾਰ ਵਾਲੇ ਬਲਾਕ ਸਾਈਫਰ ਦਾ ਨਾਂ ਦੱਸਦਾ ਹੈ; ਦੂਜਾ ਦੱਸਦਾ ਹੈ ਕਿ ਬਲਾਕ ਸਾਈਫਰ ਲੰਬੇ ਸੁਨੇਹੇ ਲਈ ਧਾਰਾ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਚੁਣਨ ਵਾਲੀ ਪੁਸਤਿਕਾ ਨੂੰ ਪੂਰਾ ਢਾਂਚਾ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਪ੍ਰਾਪਤਕਰਤਾ ਬਦਲਿਆ ਪੈਕਟ ਕਿਵੇਂ ਲੱਭਦਾ ਹੈ।
ਢਾਂਚੇ ਦੇ ਚਾਰ ਹਿੱਸਿਆਂ ਦੇ ਨਾਂ ਦੱਸੋ
ਹਰ ਸਮੀਖਿਆ ਚਾਰ ਸਵਾਲਾਂ ਤੇ ਆਉਂਦੀ ਹੈ: ਕਿਹੜਾ ਆਦਿਮ ਅਤੇ ਕੁੰਜੀ ਆਕਾਰ, ਉਸ ਨਾਲ ਸੁਨੇਹੇ ਕਿਵੇਂ ਪ੍ਰੋਸੈਸ ਹੁੰਦੇ ਹਨ, ਪ੍ਰਾਪਤਕਰਤਾ ਅਣਅਧਿਕਾਰਤ ਬਦਲਾਅ ਨੂੰ ਕਿਵੇਂ ਰੱਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਇਨਪੁਟ, ਕੁੰਜੀਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਉਮਰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ। ਜਾਣੇ-ਪਛਾਣੇ ਨਾਵਾਂ ਦੀ ਸੂਚੀ ਸਿਰਫ਼ ਪਹਿਲੇ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਦੂਜੇ ਅਤੇ ਤੀਜੇ ਵਿੱਚ ਅਸਲ ਫ਼ਰਕ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਚੌਥੇ ਵਿੱਚ ਲਾਗੂਆਂ ਚੁੱਪਚਾਪ ਵੱਖ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੁੱਛੋ ਅਤੇ ਜਵਾਬ ਲਿਖੋ।
OFB NIST ਦੇ ਬਲਾਕ-ਸਾਈਫਰ ਮੋਡ ਪ੍ਰਕਾਸ਼ਨ ਵਿੱਚ ਗੋਪਨੀਯਤਾ ਮੋਡਾਂ ਵਿਚਕਾਰ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਗੋਪਨੀਯਤਾ ਹੀ ਇਹ ਦਿੰਦਾ ਹੈ। ਇਨਕ੍ਰਿਪਸ਼ਨ ਮੋਡ ਨੂੰ ਵੱਖਰੇ MAC ਨਾਲ ਜੋੜਨ ਵਾਲੇ ਪ੍ਰੋਟੋਕੋਲ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਸੰਯੋਜਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਐਲਗੋਰਿਦਮ ਦਾ ਨਾਂ ਉਹ ਸੰਯੋਜਨ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਲਈ ਮੋਡ ਦਾ ਨਾਂ ਇਕੱਲਾ ਤੈਨਾਤੀ ਦਾ ਫ਼ੈਸਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਚੌਥਾ ਸਵਾਲ ਉਹ ਹੈ ਜੋ ਆਪਰੇਟਰ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਤੇ ਸੱਚਮੁੱਚ ਜਾਂਚ ਸਕਦਾ ਹੈ।
ਪ੍ਰਮਾਣਿਤ ਢਾਂਚੇ ਨੂੰ ਤਰਜੀਹ ਦਿਓ
ਪ੍ਰਮਾਣਿਤ ਇਨਕ੍ਰਿਪਸ਼ਨ ਗੋਪਨੀਯਤਾ ਅਤੇ ਅਖੰਡਤਾ ਇਕੱਠੇ ਦਿੰਦਾ ਹੈ, ਅਤੇ AEAD ਢਾਂਚੇ ਸੰਬੰਧਿਤ ਡੇਟਾ ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕੀਤੇ ਬਿਨਾਂ ਬਦਲਾਅ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ। ਇਹ ਪੈਕਟ ਸੁਰੱਖਿਆ ਦਾ ਗੁਣ ਹੈ, ਅਤੇ ਇਸ ਦਾ ਇਸ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ ਕਿ ਕਿਸੇ ਵਿਅਕਤੀ ਨੇ ਸਫਲਤਾਪੂਰਵਕ ਸਾਈਨ ਇਨ ਕੀਤਾ ਜਾਂ ਨਹੀਂ।
Netgate ਦੀ Netgate ਵੱਲੋਂ OpenVPN ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਸੈਟਿੰਗਾਂ ਦੀ ਗਾਈਡ ਡੇਟਾ ਚੈਨਲ ਲਈ AEAD ਵਿਕਲਪਾਂ ਵੱਲ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ AES-GCM ਵੀ ਹੈ, ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਪਾਲਣਾ ਕਰਨ ਯੋਗ ਸਮਰਥਿਤ ਨੀਤੀ ਹੈ। ਸਥਾਪਿਤ ਸੰਸਕਰਣ ਅਤੇ ਪੀਅਰ ਕਲਾਇੰਟ ਜਿਨ੍ਹਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਉਹ ਚੋਣਾਂ ਵਰਤੋ, ਨਵੀਂ ਤੈਨਾਤੀ ਵਿੱਚ ਇਤਿਹਾਸਕ ਮੋਡ ਕ੍ਰਮ ਨਕਲ ਨਾ ਕਰੋ। ਪੁਰਾਣੀ ਅਨੁਕੂਲਤਾ, ਕ੍ਰਿਪਟੋ ਬੈਕਐਂਡ ਅਤੇ ਆਫਲੋਡ ਸਮਰਥਨ ਉਹ ਸੀਮਤ ਕਰਦੇ ਹਨ ਜੋ ਅਸਲ ਵਿੱਚ ਉਪਲਬਧ ਹੈ।
ਸਮਰਥਿਤ ਢਾਂਚਾ ਹਰ ਵਾਰ ਚਤੁਰ ਸੰਯੋਜਨ ਨੂੰ ਹਰਾਉਂਦਾ ਹੈ।
ਪੇਸ਼ਕਸ਼ ਨਹੀਂ, ਤੈਅ ਨਤੀਜਾ ਪੜ੍ਹੋ
ਸਵੀਕਾਰ ਕੀਤੀ ਸੂਚੀ ਵਿੱਚ ਸਾਈਫਰ ਦਿਖਣਾ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। ਕਲਾਇੰਟ ਜਾਂ ਗੇਟਵੇ ਤੋਂ ਤੈਅ ਡੇਟਾ-ਚੈਨਲ ਸੁਰੱਖਿਆ ਪੜ੍ਹੋ, ਫਿਰ ਤੁਸੀਂ ਜੋ ਨੀਤੀ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ ਉਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਪੁਰਾਣੇ ਪੀਅਰ ਲਈ ਅਜੇ ਵੀ ਪੁਰਾਣਾ ਵਿਕਲਪ ਸੂਚੀਬੱਧ ਕਰਨ ਵਾਲਾ ਸੰਰਚਨਾ ਅਨੁਕੂਲਤਾ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਦੇ ਸੈਸ਼ਨ ਬਾਰੇ ਬਿਆਨ ਨਹੀਂ।
openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'
ਗੇਟਵੇ ਤੇ ਸਮਕਕਸ਼ ਆਉਟਪੁਟ ਪਲੇਟਫਾਰਮ ਅਨੁਸਾਰ ਸੁਰੱਖਿਆ ਸੰਘ ਜਾਂ ਕਨੈਕਸ਼ਨ ਦੇ ਕ੍ਰਿਪਟੋ ਵੇਰਵੇ ਹਨ। ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਪੇਸ਼ਕਸ਼ ਅਤੇ ਨਤੀਜਾ ਵੱਖਰੇ ਤੱਥ ਹਨ। ਪੁਰਾਣੇ ਪੀਅਰ ਲਈ ਪੁਰਾਣਾ ਵਿਕਲਪ ਰੱਖਣ ਵਾਲੀ ਸੂਚੀ ਦਾ ਅਰਥ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਸੈਸ਼ਨ ਉਹ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਜੋ ਸੈਸ਼ਨ ਵਰਤਦਾ ਹੈ ਉਹੀ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ।
ਦੋਵੇਂ ਤੱਥ ਇਕੱਠੇ ਦਰਜ ਕਰੋ, ਤਾਰੀਖ ਅਤੇ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਨਾਲ।
ਸਿਰਫ਼ ਜਿਸ ਦੀ ਤੁਲਨਾ ਹੋ ਸਕੇ ਉਹੀ ਮਾਪੋ
ਥ੍ਰੂਪੁਟ ਸਿਰਿਆਂ ਦੇ ਹਾਰਡਵੇਅਰ, ਲਾਗੂਆਂ, ਤੇਜ਼ੀ, ਪੈਕਟ ਆਕਾਰ ਅਤੇ ਚੁਣੀ ਸੰਰਚਨਾ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਕੁੰਜੀ ਦੀ ਲੰਬਾਈ ਜਾਂ OFB ਸ਼ਬਦ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਕਿਹੜੀ ਤੈਨਾਤੀ ਤੇਜ਼ ਹੋਵੇਗੀ। ਇਸ ਲਈ ਕਿਸੇ ਹੋਰ ਸਾਈਟ ਦਾ ਮਾਪ ਸਭ ਤੋਂ ਵੱਧ ਕਿਸੇ ਹੋਰ ਦੇ ਹਾਰਡਵੇਅਰ ਬਾਰੇ ਸੰਕੇਤ ਹੈ। ਤੁਹਾਡੇ ਆਪਣੇ ਅੰਕੜੇ ਤੁਹਾਡੇ ਆਪਣੇ ਸਿਰਿਆਂ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ।
ਅਧਿਕਾਰਤ ਤੁਲਨਾ ਲਈ ਸਿਰੇ, ਕੰਮ ਦਾ ਭਾਰ ਅਤੇ ਲੋੜੀਂਦੀ ਨੀਤੀ ਸਥਿਰ ਰੱਖੋ, ਅਤੇ ਤੈਅ ਸੁਰੱਖਿਆ ਤੇ ਲਾਗੂਆਂ ਦੇ ਸੰਸਕਰਣ ਦਰਜ ਕਰੋ। ਫਿਰ ਨਤੀਜੇ ਦਾ ਮੁਲਾਂਕਣ ਇਸ ਗੱਲ ਤੋਂ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਪੂਰੀ ਹੋਈ, ਕਿੰਨਾ ਗੁਆਇਆ ਅਤੇ ਸਿਰੇ ਕੀ ਕਰ ਰਹੇ ਸਨ, ਇੱਕ ਗਤੀ ਪਰੀਖਿਆ ਤੋਂ ਕ੍ਰਿਪਟੋ ਲਾਗਤ ਕੱਢਣ ਦੀ ਥਾਂ। ਹੋਰ ਹਾਲਾਤਾਂ ਵਿੱਚ ਬਣਿਆ ਅੰਕੜਾ ਕਹਾਣੀ ਹੈ, ਮਾਪ ਨਹੀਂ।
ਜੇ ਪੁਰਾਣਾ ਪੀਅਰ ਨੀਤੀ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਇਹ ਉਸ ਦੇ ਮਾਲਕ ਲਈ ਅਨੁਕੂਲਤਾ ਦਾ ਫ਼ੈਸਲਾ ਹੈ।
ਅਖੰਡਤਾ ਨੂੰ ਸੌਦੇ ਤੋਂ ਬਾਹਰ ਰੱਖੋ
ਅਖੰਡਤਾ ਜਾਂਚ ਬੰਦ ਕਰਨਾ ਜਾਂ ਬਿਨਾਂ ਪੁਸ਼ਟੀ ਵਾਲਾ ਸਰਵਰ ਸਵੀਕਾਰ ਕਰਨਾ ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਨਹੀਂ ਹੈ ਅਤੇ ਅਨੁਕੂਲਤਾ ਦੀ ਮੁਰੰਮਤ ਵੀ ਨਹੀਂ। ਇਹ ਉਹ ਸੁਰੱਖਿਆ ਗੁਣ ਬਦਲਦਾ ਹੈ ਜਿਸ ਲਈ ਢਾਂਚਾ ਚੁਣਿਆ ਗਿਆ ਸੀ। ਇਹੀ ਗੱਲ ਸਵੀਕਾਰ ਕੀਤੀ ਸਾਈਫਰ ਸੂਚੀ ਨੂੰ ਪੁਰਾਣੇ ਪੀਅਰ ਦੇ ਜੁੜਨ ਤੱਕ ਵਧਾਉਣ ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ: ਕਨੈਕਸ਼ਨ ਸਫਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਨੀਤੀ ਰਹਿੰਦੀ ਨਹੀਂ।
ਸਵੀਕਾਰ ਕੀਤਾ ਢਾਂਚਾ ਅਤੇ ਉਸ ਦਾ ਮਾਲਕ ਪੁਸਤਿਕਾ ਵਿੱਚ ਲਿਖੋ, ਤਾਂ ਜੋ ਅਗਲੀ ਤਬਦੀਲੀ ਤਰਜੀਹ ਤੋਂ ਨਹੀਂ, ਫ਼ੈਸਲੇ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇ।
ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਨੀਤੀ ਜੋ ਦੋਵੇਂ ਸਿਰੇ ਲਾਗੂ ਕਰ ਸਕਣ। ਕਿਹੜਾ ਨਾਂ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਹੈ ਦੀ ਬਹਿਸ ਹੋਰ ਗੱਲ ਹੈ, ਅਤੇ ਉਹ ਆਮ ਤੌਰ ਤੇ ਫ਼ੈਸਲੇ ਬਿਨਾਂ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ।