ਸਟੈਟਿਕ ਕੁੰਜੀ ਫਾਈਲ ਵਿੱਚ ਬਿਟ ਗਿਣਤੀ OpenVPN ਸਾਈਫਰ ਦੀ ਤਾਕਤ ਨਹੀਂ ਹੈ

ਸਕੈਨਰ ਜਾਂ ਸਹਿਕਰਮੀ OpenVPN ਸਟੈਟਿਕ ਕੁੰਜੀ ਫਾਈਲ ਦੇ ਅੰਦਰ ਛਪੀ ਬਿਟ ਗਿਣਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਪੁੱਛਦਾ ਹੈ ਕਿ ਟਨਲ ਉਸ ਆਕਾਰ ਦਾ ਸਾਈਫਰ ਕਿਉਂ ਨਹੀਂ ਵਰਤ ਰਹੀ। ਸਵਾਲ ਵਾਜਬ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਕੋਈ ਸੰਖਿਆ ਨਹੀਂ: ਬੈਨਰ ਸੰਗ੍ਰਹਿਤ ਕੁੰਜੀ ਸਮੱਗਰੀ ਗਿਣਦਾ ਹੈ, ਜਦਕਿ ਸਾਈਫਰ ਸਿਰਫ਼ ਉਹ ਹਿੱਸਾ ਖਪਦਾ ਹੈ ਜੋ ਉਸਦੇ ਕੁੰਜੀ ਆਕਾਰ ਨੂੰ ਚਾਹੀਦਾ ਹੈ। ਉਸ ਕੁੱਲ ਨੂੰ ਤਾਕਤ ਦੀ ਸੈਟਿੰਗ ਮੰਨਣ ਨਾਲ ਅਜਿਹੀਆਂ ਸੋਧਾਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਕੁਝ ਨਹੀਂ ਬਦਲਦੀਆਂ। ਇਹ ਫਾਰਮੈਟ ਕਿਸੇ ਵੀ ਇੱਕਲੇ ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਨਾਲੋਂ ਵੱਧ ਸਮੱਗਰੀ ਰੱਖਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।

ਇੱਥੇ ਦੋ ਸਵਾਲ ਮਿਲ ਜਾਂਦੇ ਹਨ: ਫਾਈਲ ਕਿੰਨੀ ਕੁੰਜੀ ਸਮੱਗਰੀ ਸੰਗ੍ਰਹਿਤ ਕਰਦੀ ਹੈ, ਅਤੇ ਸਹਿਮਤ ਸਾਈਫਰ ਕਿੰਨਾ ਮਜ਼ਬੂਤ ਹੈ। ਟਨਲ ਦਾ ਵਰਣਨ ਸਿਰਫ਼ ਦੂਜਾ ਕਰਦਾ ਹੈ।

ਬੈਨਰ ਦੀ ਸੰਖਿਆ ਅਸਲ ਵਿੱਚ ਕੀ ਗਿਣਦੀ ਹੈ

ਕੰਟੇਨਰ ਸਾਈਫਰ ਸਮੱਗਰੀ ਅਤੇ HMAC ਸਮੱਗਰੀ ਨੂੰ ਵੱਖਰੀਆਂ ਬਣਤਰਾਂ ਵਜੋਂ ਤਰਤੀਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਦੁਇ-ਦਿਸ਼ਾ ਰੂਪ ਅਜਿਹੇ ਦੋ ਸੈੱਟ ਰੱਖਦਾ ਹੈ ਤਾਂ ਜੋ ਹਰ ਦਿਸ਼ਾ ਆਪਣੀਆਂ ਕੁੰਜੀਆਂ ਲੈ ਜਾ ਸਕੇ। ਲਿਖਣ ਵਾਲਾ ਕੋਡ ਛਪੀ ਸੰਖਿਆ ਨੂੰ ਤਰਤੀਬ ਕੀਤੀਆਂ ਬਣਤਰਾਂ ਦੀ ਗਿਣਤੀ, ਉਨ੍ਹਾਂ ਦੇ ਆਕਾਰ ਅਤੇ ਪ੍ਰਤੀ ਬਾਈਟ ਅੱਠ ਬਿੱਟਾਂ ਤੋਂ ਕੱਢਦਾ ਹੈ। ਇਹ ਸੰਗ੍ਰਹਿ ਉੱਤੇ ਅੰਕਗਣਿਤ ਹੈ, ਇਹ ਦਾਅਵਾ ਨਹੀਂ ਕਿ ਇੱਕ ਸਾਈਫਰ ਹਰ ਸੰਗ੍ਰਹਿਤ ਬਾਈਟ ਖਪਦਾ ਹੈ। ਹੈਡਰ ਵੱਧ ਤੋਂ ਵੱਧ ਸਾਈਫਰ ਸਮੱਗਰੀ ਵੰਡ ਵੀ ਤੈਅ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਲਾਇਬ੍ਰੇਰੀ ਬਦਲਾਅ ਫਾਰਮੈਟ ਦੇ ਮਾਪ ਚੁੱਪਚਾਪ ਨਾ ਬਦਲ ਸਕੇ।

ਇਸਦੀ ਤੁਲਨਾ ਸਰਟੀਫਿਕੇਟ ਕੁੰਜੀ ਨਾਲ ਕਰੋ, ਜਿੱਥੇ ਬਿਟ ਗਿਣਤੀ ਸੱਚਮੁੱਚ ਇੱਕ ਵਸਤੂ ਦਾ ਆਕਾਰ ਦੱਸਦੀ ਹੈ। 4,096 ਬਿੱਟ ਦੀ RSA ਕੁੰਜੀ ਅਤੇ ਜਿਸਦਾ ਬੈਨਰ 4,096 ਬਿੱਟ ਪੜ੍ਹਦਾ ਹੈ ਅਜਿਹੀ ਕੁੰਜੀ ਫਾਈਲ ਵੱਖਰੇ ਕੰਮਾਂ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕੋ ਡਾਇਲ ਦੀਆਂ ਦੋ ਸੈਟਿੰਗਾਂ ਵਜੋਂ ਰੱਖਣ ਨਾਲ ਖਰਾਬ ਸਿੱਟੇ ਨਿਕਲਦੇ ਹਨ।

ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਦੋ ਕੁੰਜੀ ਸੈੱਟ

ਫਾਈਲ ਦਾ ਹਰ ਅੱਧਾ ਹਿੱਸਾ ਇਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਸਮੱਗਰੀ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੁੰਜੀ ਮੋਡ ਉਨ੍ਹਾਂ ਵੱਖਰੇ ਟੁਕੜਿਆਂ ਨਾਲ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪੈਕਟ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ। ਸਰਗਰਮ ਸਾਈਫਰ ਸਿਰਫ਼ ਉਹ ਬਾਈਟ ਵਰਤਦਾ ਹੈ ਜੋ ਉਸਦੇ ਕੁੰਜੀ ਆਕਾਰ ਨੂੰ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਡਾਈਜੈਸਟ ਆਪਣਾ ਆਉਟਪੁੱਟ ਆਕਾਰ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਵਰਤਣਯੋਗ ਤਾਕਤ ਫਾਈਲ ਦੀ ਲੰਬਾਈ ਤੋਂ ਨਹੀਂ, ਵਿਕਲਪਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ। ਹੈਕਸਾਡੈਸੀਮਲ ਬਲੌਬ ਲੰਮਾ ਕਰਨ ਨਾਲ ਸੰਰਚਿਤ ਐਲਗੋਰਿਦਮ ਨੂੰ ਇਸ ਵਿੱਚੋਂ ਵੱਧ ਖਪਣ ਲਈ ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ। ਟਿੱਪਣੀ ਨੂੰ ਵੱਡੀ ਸੰਖਿਆ ਨਾਲ ਸੋਧਣ ਨਾਲ ਹੋਰ ਵੀ ਘੱਟ ਬਦਲਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਲੰਮੀ ਕੁੰਜੀ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਬਦਲਣ ਵਾਲੀ ਸੈਟਿੰਗ ਸਾਈਫਰ ਜਾਂ ਡਾਈਜੈਸਟ ਹੈ, ਅਤੇ ਜਨਰੇਟਰ ਉਹ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਚੁਣੇ ਐਲਗੋਰਿਦਮਾਂ ਨੂੰ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰੋਫਾਈਲ ਪੜ੍ਹਨ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜਾ ਮੋਡ ਹੈ

ਇੱਕੋ ਫਾਈਲ ਫਾਰਮੈਟ ਦੋ ਬਿਲਕੁਲ ਵੱਖਰੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਤੁਹਾਡੇ ਕੋਲ ਹੈ ਇਹ ਸਿਰਫ਼ ਪ੍ਰੋਫਾਈਲ ਦੱਸਦਾ ਹੈ। ਪੁਰਾਣੀ secret ਲਾਈਨ ਫਾਈਲ ਨੂੰ ਟਨਲ ਦੀ ਇੱਕੋ-ਇੱਕ ਕੁੰਜੀ ਸਮੱਗਰੀ ਬਣਾ ਦਿੰਦੀ ਹੈ, ਜਦਕਿ tls-auth ਜਾਂ tls-crypt ਇਸਨੂੰ ਸਰਟੀਫਿਕੇਟਾਂ ਦੇ ਨਾਲ ਕੰਟਰੋਲ-ਚੈਨਲ ਸੁਰੱਖਿਆ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਵਰਤੋਂ ਬਲਾਕ ਕਿੰਨਾ ਵੀ ਸਮਾਨ ਦਿਸੇ, ਇਸਨੂੰ ਕਲਾਇੰਟ ਦੇ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਬਦਲ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਵਿਕਲਪ ਅਤੇ ਸੰਸਕਰਣ ਪਛਾਣੋ, ਅਤੇ ਅੱਖਰ ਜੋੜਨ ਦੀ ਥਾਂ ਦਸਤਾਵੇਜ਼ੀ ਜਨਰੇਟਰ ਵਰਤੋ।

ਇਹ ਫ਼ਰਕ ਖੁਲਾਸੇ ਪ੍ਰਤੀ ਪ੍ਰਤੀਕਿਰਿਆ ਵੀ ਤੈਅ ਕਰਦਾ ਹੈ। ਲੀਕ ਹੋਈ tls-auth ਕੁੰਜੀ ਸੈਸ਼ਨ ਕੁੰਜੀਆਂ ਜ਼ਾਹਰ ਨਹੀਂ ਕਰਦੀ, ਪਰ ਹਮਲਾਵਰ ਨੂੰ ਕੰਟਰੋਲ-ਚੈਨਲ ਟ੍ਰੈਫਿਕ ਅੰਦਰ ਪਾਉਣ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਫਿਰ ਵੀ ਬਦਲਨਾ ਪੈਂਦਾ ਹੈ। ਲੀਕ ਹੋਈ secret ਕੁੰਜੀ ਵਧੇਰੇ ਖਰਾਬ ਹੈ, ਕਿਉਂਕਿ ਉਹੀ ਉਹ ਸਮੱਗਰੀ ਸੀ ਜੋ ਖੁਦ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਸੀ।

ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਵਿੱਚ ਕੀ ਦਰਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

ਤਿੰਨ ਚੀਜ਼ਾਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦਰਜ ਕਰੋ: ਸਹਿਮਤ ਡੇਟਾ-ਚੈਨਲ ਸੁਰੱਖਿਆ, ਕੰਟਰੋਲ-ਚੈਨਲ ਸੁਰੱਖਿਆ, ਅਤੇ ਸਾਥੀ ਇੱਕ ਦੂਜੇ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਿਵੇਂ ਕਰਦੇ ਹਨ। data-ciphers AES-256-GCM ਵਰਗੀ ਲਾਈਨ ਸਿਰਫ਼ ਪਹਿਲੇ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਉੱਥੇ ਰੁਕਣ ਵਾਲੀ ਰਿਪੋਰਟ ਇਹ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦੀ ਕਿ ਕੰਟਰੋਲ-ਚੈਨਲ ਬਿਲਕੁਲ ਸੁਰੱਖਿਅਤ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਟੈਟਿਕ ਕੁੰਜੀ ਫਾਈਲ tls-auth ਜਾਂ tls-crypt ਨਾਲ ਵਰਤੇ ਜਾਣ 'ਤੇ ਦੂਜੀ ਸ਼੍ਰੇਣੀ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਨਾ ਵਰਤੇ ਜਾਣ 'ਤੇ ਕਿਸੇ ਵਿੱਚ ਨਹੀਂ। ਸ਼੍ਰੇਣੀਆਂ ਮਿਲਾਉਣ ਵਾਲੇ ਸਮੀਖਿਅਕ ਵੱਧ ਮਜ਼ਬੂਤ ਸਾਈਫਰ ਚਾਹੁੰਦਿਆਂ ਵੱਡੀ ਕੁੰਜੀ ਫਾਈਲ ਮੰਗਦੇ ਹਨ।

ਜੇ ਫਾਈਲ ਜ਼ਾਹਰ ਹੋ ਗਈ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਘੁਮਾਓ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਚੈਨਲ ਰਾਹੀਂ ਦੁਬਾਰਾ ਵੰਡੋ। ਸਮਝੌਤਾ-ਗ੍ਰਸਤ ਭੇਦ ਵਿੱਚ ਅੱਖਰ ਜੋੜਨਾ ਘੁਮਾਉਣਾ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਜ਼ਾਹਰ ਹੋਈ ਸਮੱਗਰੀ ਨੂੰ ਵੈਧ ਰਹਿਣ ਦਿੰਦਾ ਹੈ।

ਘੁਮਾਉਣ ਦਾ ਰਿਕਾਰਡ ਉਸੇ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਰੱਖੋ ਜਿਸਦਾ ਉਹ ਹੈ। ਅਗਲੀ ਸਮੀਖਿਆ ਪੁੱਛੇਗੀ ਕਿਹੜੀ ਕੁੰਜੀ ਨੇ ਕਿਹੜੀ ਮਿਆਦ ਦੀ ਰੱਖਿਆ ਕੀਤੀ, ਅਤੇ ਬੈਨਰ ਇਸਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇਵੇਗਾ।