ਲੀਨਕਸ: ਲੌਕ ਪੂਲ /dev/random ਨੂੰ ਹਟਾਉਣਾ

/dev/random, ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸੂਡੋ-ਰੈਂਡਮ ਨੰਬਰ ਜਨਰੇਟਰ (CSPRNG), ਨੂੰ ਇੱਕ ਤੰਗ ਕਰਨ ਵਾਲੀ ਸਮੱਸਿਆ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ: ਬਲਾਕਿੰਗ। ਇਹ ਲੇਖ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰ ਸਕਦੇ ਹੋ।

ਪਿਛਲੇ ਕੁਝ ਮਹੀਨਿਆਂ ਵਿੱਚ, ਕਰਨਲ ਵਿੱਚ ਬੇਤਰਤੀਬ ਸੰਖਿਆ ਬਣਾਉਣ ਦੀਆਂ ਸਹੂਲਤਾਂ ਨੂੰ ਥੋੜ੍ਹਾ ਜਿਹਾ ਦੁਬਾਰਾ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਪਰ ਇਸ ਸਬ-ਸਿਸਟਮ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਮਾ ਸੀਮਾ. ਸਭ ਆਖਰੀ ਤਬਦੀਲੀਆਂ ਸਿਸਟਮ ਬੂਟ ਹੋਣ 'ਤੇ getrandom() ਸਿਸਟਮ ਕਾਲ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਬਲੌਕ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਪਰ ਇਸਦਾ ਮੂਲ ਕਾਰਨ ਬੇਤਰਤੀਬ ਪੂਲ ਦਾ ਬਲਾਕਿੰਗ ਵਿਵਹਾਰ ਸੀ। ਇੱਕ ਤਾਜ਼ਾ ਪੈਚ ਨੇ ਇਸ ਪੂਲ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਹੋਵੇਗਾ ਅਤੇ ਇਸਦੇ ਮੁੱਖ ਕੋਰ ਵੱਲ ਜਾਣ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਵੇਗੀ।

ਐਂਡੀ ਲੂਟੋਮੀਰਸਕੀ ਨੇ ਦਸੰਬਰ ਦੇ ਅੰਤ ਵਿੱਚ ਪੈਚ ਦਾ ਤੀਜਾ ਸੰਸਕਰਣ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ। ਉਹ ਯੋਗਦਾਨ ਪਾਉਂਦਾ ਹੈ "ਬੇਤਰਤੀਬ ਲੀਨਕਸ API ਵਿੱਚ ਦੋ ਮੁੱਖ ਅਰਥ ਤਬਦੀਲੀਆਂ". ਪੈਚ getrandom() ਸਿਸਟਮ ਕਾਲ ਵਿੱਚ ਇੱਕ ਨਵਾਂ GRND_INSECURE ਫਲੈਗ ਜੋੜਦਾ ਹੈ (ਹਾਲਾਂਕਿ ਲੂਟੋਮੀਰਸਕੀ ਇਸ ਨੂੰ getentropy() ਵਜੋਂ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ ਫਿਕਸਡ ਫਲੈਗਾਂ ਦੇ ਨਾਲ getrandom() ਦੀ ਵਰਤੋਂ ਕਰਕੇ glibc ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ); ਇਹ ਫਲੈਗ ਕਾਲ ਨੂੰ ਹਮੇਸ਼ਾਂ ਬੇਨਤੀ ਕੀਤੇ ਡੇਟਾ ਦੀ ਮਾਤਰਾ ਵਾਪਸ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ, ਪਰ ਇਹ ਗਰੰਟੀ ਦਿੱਤੇ ਬਿਨਾਂ ਕਿ ਡੇਟਾ ਬੇਤਰਤੀਬ ਹੈ। ਕਰਨਲ ਦਿੱਤੇ ਗਏ ਸਮੇਂ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਬੇਤਰਤੀਬ ਡੇਟਾ ਤਿਆਰ ਕਰਨ ਲਈ ਆਪਣੀ ਪੂਰੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ। "ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਵਧੀਆ ਚੀਜ਼ ਇਸ ਨੂੰ 'ਅਸੁਰੱਖਿਅਤ' ਕਹਿਣਾ ਹੈ (ਅਸੁਰੱਖਿਅਤ) ਇਸ API ਨੂੰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਵਰਤੇ ਜਾਣ ਤੋਂ ਰੋਕਣ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੁਰੱਖਿਆ ਦੀ ਜ਼ਰੂਰਤ ਹੈ।"

ਪੈਚ ਬਲਾਕਿੰਗ ਪੂਲ ਨੂੰ ਵੀ ਹਟਾਉਂਦੇ ਹਨ. ਕਰਨਲ ਵਰਤਮਾਨ ਵਿੱਚ ਦੋ ਬੇਤਰਤੀਬ ਡਾਟਾ ਪੂਲ ਰੱਖਦਾ ਹੈ, ਇੱਕ /dev/random ਅਤੇ ਦੂਜਾ /dev/urandom ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਸ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ। ਲੇਖ 2015। ਬਲਾਕਿੰਗ ਪੂਲ /dev/random ਲਈ ਪੂਲ ਹੈ; ਉਸ ਡਿਵਾਈਸ ਲਈ ਰੀਡਜ਼ (ਇਸਦਾ ਨਾਮ ਦਾ ਮਤਲਬ) ਉਦੋਂ ਤੱਕ ਬਲੌਕ ਕਰ ਦੇਵੇਗਾ ਜਦੋਂ ਤੱਕ ਬੇਨਤੀ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਸਿਸਟਮ ਤੋਂ "ਕਾਫ਼ੀ" ਐਂਟਰੌਪੀ ਇਕੱਠੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਜੇਕਰ ਪੂਲ ਵਿੱਚ ਲੋੜੀਂਦੀ ਐਂਟਰੌਪੀ ਨਹੀਂ ਹੈ ਤਾਂ ਇਸ ਫਾਈਲ ਤੋਂ ਹੋਰ ਪੜ੍ਹੇ ਜਾਣ ਨੂੰ ਵੀ ਬਲੌਕ ਕੀਤਾ ਜਾਵੇਗਾ।

ਲੌਕ ਪੂਲ ਨੂੰ ਹਟਾਉਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ /dev/random ਤੋਂ ਰੀਡਿੰਗ ਜ਼ੀਰੋ 'ਤੇ ਸੈੱਟ ਕੀਤੇ ਫਲੈਗਾਂ ਦੇ ਨਾਲ getrandom() ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ (ਅਤੇ GRND_RANDOM ਫਲੈਗ ਨੂੰ ਨੂਪ ਵਿੱਚ ਬਦਲਦਾ ਹੈ)। ਇੱਕ ਵਾਰ ਜਦੋਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਬੇਤਰਤੀਬ ਨੰਬਰ ਜਨਰੇਟਰ (CRNG) ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ, /dev/random ਤੋਂ ਪੜ੍ਹਨਾ ਅਤੇ getrandom(...,0) ਨੂੰ ਕਾਲ ਕਰਨਾ ਬਲੌਕ ਨਹੀਂ ਹੋਵੇਗਾ ਅਤੇ ਬੇਤਰਤੀਬ ਡੇਟਾ ਦੀ ਬੇਨਤੀ ਕੀਤੀ ਰਕਮ ਵਾਪਸ ਕਰੇਗਾ।

Lutomirsky ਕਹਿੰਦਾ ਹੈ: “ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਲੀਨਕਸ ਬਲਾਕਿੰਗ ਪੂਲ ਪੁਰਾਣਾ ਹੋ ਗਿਆ ਹੈ। CRNG ਲੀਨਕਸ ਆਉਟਪੁੱਟ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਕਿ ਕੁੰਜੀ ਬਣਾਉਣ ਲਈ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਬਲਾਕਿੰਗ ਪੂਲ ਕਿਸੇ ਵੀ ਭੌਤਿਕ ਅਰਥਾਂ ਵਿੱਚ ਮਜ਼ਬੂਤ ​​​​ਨਹੀਂ ਹੈ ਅਤੇ ਇਸਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਸ਼ੱਕੀ ਮੁੱਲ ਦੇ ਬਹੁਤ ਸਾਰੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲੋੜ ਹੈ।

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

“ਇਹ ਐਪੀਸੋਡ ਕਿਸੇ ਵੀ ਮੌਜੂਦਾ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਵਿਘਨ ਨਹੀਂ ਪਾਉਣੇ ਚਾਹੀਦੇ। /dev/urandom ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਰਹਿੰਦਾ। /dev/random ਅਜੇ ਵੀ ਬੂਟ ਹੋਣ 'ਤੇ ਤੁਰੰਤ ਬਲੌਕ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਪਹਿਲਾਂ ਨਾਲੋਂ ਘੱਟ ਬਲਾਕ ਕਰਦਾ ਹੈ। ਮੌਜੂਦਾ ਫਲੈਗ ਦੇ ਨਾਲ getentropy() ਇੱਕ ਨਤੀਜਾ ਵਾਪਸ ਕਰੇਗਾ ਜੋ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਵਿਹਾਰਕ ਉਦੇਸ਼ਾਂ ਲਈ ਢੁਕਵਾਂ ਹੈ।"

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

ਸਟੀਫਨ ਮੂਲਰ ਨੇ ਸੁਝਾਅ ਦਿੱਤਾ ਕਿ ਉਸ ਦਾ ਸੈੱਟ ਪੈਚ Linux ਲਈ ਰੈਂਡਮ ਨੰਬਰ ਜਨਰੇਟਰ (LRNG) (ਵਰਤਮਾਨ ਵਿੱਚ 26 ਜਾਰੀ ਕੀਤਾ ਗਿਆ) ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸਹੀ ਬੇਤਰਤੀਬ ਨੰਬਰ ਪ੍ਰਦਾਨ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੋ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ। LRNG "ਰੈਂਡਮ ਬਿੱਟ ਤਿਆਰ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਐਨਟ੍ਰੋਪੀ ਸਰੋਤਾਂ 'ਤੇ SP800-90B ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪਾਲਣਾ ਕਰਦਾ ਹੈ," ਇਸ ਨੂੰ ਸਰਕਾਰੀ ਮਿਆਰਾਂ ਦੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਬਣਾਉਂਦਾ ਹੈ।
ਮੈਥਿਊ ਗੈਰੇਟ ਨੇ "ਸੱਚੇ ਬੇਤਰਤੀਬੇ ਡੇਟਾ" ਸ਼ਬਦ 'ਤੇ ਇਤਰਾਜ਼ ਕੀਤਾ, ਇਹ ਨੋਟ ਕਰਦੇ ਹੋਏ ਕਿ ਨਮੂਨੇ ਲਏ ਗਏ ਯੰਤਰਾਂ ਨੂੰ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ ਯੋਗ ਬਣਾਉਣ ਲਈ ਬਿਲਕੁਲ ਸਹੀ ਢੰਗ ਨਾਲ ਮਾਡਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: "ਅਸੀਂ ਇੱਥੇ ਕੁਆਂਟਮ ਘਟਨਾਵਾਂ ਦਾ ਨਮੂਨਾ ਨਹੀਂ ਲੈ ਰਹੇ ਹਾਂ।"

ਮੂਲਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਕਿ ਇਹ ਸ਼ਬਦ ਇੱਕ ਬੇਤਰਤੀਬ ਸੰਖਿਆ ਜਨਰੇਟਰ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਜਰਮਨ ਸਟੈਂਡਰਡ AIS 31 ਤੋਂ ਆਇਆ ਹੈ ਜੋ ਸਿਰਫ ਇੱਕ ਨਤੀਜਾ ਪੈਦਾ ਕਰਦਾ ਹੈ "ਉਸੇ ਦਰ 'ਤੇ ਜਿਸ ਤਰ੍ਹਾਂ ਅੰਡਰਲਾਈੰਗ ਸ਼ੋਰ ਸਰੋਤ ਐਨਟ੍ਰੋਪੀ ਪੈਦਾ ਕਰਦਾ ਹੈ।"

ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੇ ਅੰਤਰ ਨੂੰ ਪਾਸੇ ਰੱਖੋ, LRNG ਪੈਚਾਂ ਦੁਆਰਾ ਸੁਝਾਏ ਅਨੁਸਾਰ ਇੱਕ ਲਾਕ ਪੂਲ ਹੋਣ ਨਾਲ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਣਗੀਆਂ, ਘੱਟੋ-ਘੱਟ ਜੇ ਇਸ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਤੋਂ ਬਿਨਾਂ ਐਕਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਜਿਵੇਂ ਕਿ ਲੂਟੋਮੀਰਸਕੀ ਨੇ ਕਿਹਾ: “ਇਸ ਨਾਲ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਦੋ ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾ gnupg ਵਰਗੇ ਮੂਰਖ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਇੱਕ ਦੂਜੇ ਨੂੰ ਨਿਕਾਸ ਕਰਨਗੇ। ਮੈਂ ਵੇਖਦਾ ਹਾਂ ਕਿ /dev/random ਨਾਲ ਵਰਤਮਾਨ ਵਿੱਚ ਦੋ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਹਨ: ਇਹ DoS (ਜਿਵੇਂ ਕਿ ਸਰੋਤ ਦੀ ਕਮੀ, ਖਤਰਨਾਕ ਪ੍ਰਭਾਵ ਜਾਂ ਕੁਝ ਸਮਾਨ) ਦੀ ਸੰਭਾਵਨਾ ਹੈ, ਅਤੇ ਕਿਉਂਕਿ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਇਹ ਦੁਰਵਿਵਹਾਰ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੀ ਹੈ। Gnupg ਗਲਤ ਹੈ, ਇਹ ਇੱਕ ਪੂਰਨ ਢਹਿ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਗੈਰ-ਅਧਿਕਾਰਤ ਇੰਟਰਫੇਸ ਜੋੜਦੇ ਹਾਂ ਜੋ ਕਿ gnupg ਅਤੇ ਸਮਾਨ ਪ੍ਰੋਗਰਾਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਗੇ, ਅਸੀਂ ਦੁਬਾਰਾ ਗੁਆ ਦੇਵਾਂਗੇ।"

ਮੂਲਰ ਨੇ ਨੋਟ ਕੀਤਾ ਕਿ getrandom() ਨੂੰ ਜੋੜਨਾ ਹੁਣ GnuPG ਨੂੰ ਇਸ ਇੰਟਰਫੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ, ਕਿਉਂਕਿ ਇਹ ਜ਼ਰੂਰੀ ਗਾਰੰਟੀ ਪ੍ਰਦਾਨ ਕਰੇਗਾ ਕਿ ਪੂਲ ਸ਼ੁਰੂ ਹੋ ਗਿਆ ਹੈ। GnuPG ਡਿਵੈਲਪਰ ਵਰਨਰ ਕੋਚ ਨਾਲ ਵਿਚਾਰ-ਵਟਾਂਦਰੇ ਦੇ ਆਧਾਰ 'ਤੇ, ਮੂਲਰ ਦਾ ਮੰਨਣਾ ਹੈ ਕਿ ਗਾਰੰਟੀ ਹੀ ਇੱਕੋ ਇੱਕ ਕਾਰਨ ਹੈ GnuPG ਵਰਤਮਾਨ ਵਿੱਚ /dev/random ਤੋਂ ਸਿੱਧਾ ਪੜ੍ਹਦਾ ਹੈ। ਪਰ ਜੇਕਰ ਕੋਈ ਗੈਰ-ਅਧਿਕਾਰਤ ਇੰਟਰਫੇਸ ਹੈ ਜੋ ਸੇਵਾ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਹੈ (ਜਿਵੇਂ ਕਿ /dev/random ਅੱਜ ਹੈ), ਲੂਟੋਮੀਰਸਕੀ ਨੇ ਦਲੀਲ ਦਿੱਤੀ ਹੈ ਕਿ ਕੁਝ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੁਆਰਾ ਇਸਦੀ ਦੁਰਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇਗੀ।

ਲੀਨਕਸ ਦੇ ਬੇਤਰਤੀਬ ਨੰਬਰ ਸਬ-ਸਿਸਟਮ ਦੇ ਡਿਵੈਲਪਰ, ਥੀਓਡੋਰ ਯੂ ਟਾਕ ਟਸਓ ਨੇ ਇੱਕ ਬਲਾਕਿੰਗ ਪੂਲ ਦੀ ਲੋੜ ਬਾਰੇ ਆਪਣਾ ਮਨ ਬਦਲ ਲਿਆ ਹੈ। ਉਸਨੇ ਕਿਹਾ ਕਿ ਇਸ ਪੂਲ ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਇਸ ਵਿਚਾਰ ਤੋਂ ਛੁਟਕਾਰਾ ਮਿਲ ਜਾਵੇਗਾ ਕਿ ਲੀਨਕਸ ਕੋਲ ਇੱਕ ਸੱਚਾ ਰੈਂਡਮ ਨੰਬਰ ਜਨਰੇਟਰ (TRNG) ਹੈ: "ਇਹ ਬਕਵਾਸ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ *BSD ਨੇ ਹਮੇਸ਼ਾ ਕੀਤਾ ਹੈ।"

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

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

"ਕਰਨਲ ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਦੇ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਸ਼ੋਰ ਸਰੋਤ ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਿਰਫ਼ ਇੱਕ GPG ਜਾਂ OpenSSL ਡਿਵੈਲਪਰ ਇੱਕ ਅਸਪਸ਼ਟ ਭਾਵਨਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਕਿ TRUERANDOM "ਬਿਹਤਰ" ਹੈ, ਅਤੇ ਕਿਉਂਕਿ ਉਹ ਵਧੇਰੇ ਸੁਰੱਖਿਆ ਚਾਹੁੰਦੇ ਹਨ, ਉਹ ਬਿਨਾਂ ਸ਼ੱਕ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ। ਕਿਸੇ ਸਮੇਂ ਇਸਨੂੰ ਬਲੌਕ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਜਦੋਂ ਕੋਈ ਹੋਰ ਸਮਾਰਟ ਉਪਭੋਗਤਾ (ਸ਼ਾਇਦ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਸਪੈਸ਼ਲਿਸਟ) ਇਸਨੂੰ init ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਿਰਫ ਲਿਨਸ ਟੋਰਵਾਲਡਜ਼ ਨੂੰ ਸ਼ਿਕਾਇਤ ਕਰਨੀ ਪਵੇਗੀ।"

Cao ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਰਾਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵੀ ਦੇਣ ਦੀ ਵਕਾਲਤ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ TRNG ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਉਪਭੋਗਤਾ ਸਪੇਸ ਵਿੱਚ ਆਪਣੀ ਖੁਦ ਦੀ ਐਂਟਰੌਪੀ ਦੀ ਵਾਢੀ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਜਿਵੇਂ ਕਿ ਉਹ ਠੀਕ ਸਮਝਦੇ ਹਨ. ਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਐਨਟ੍ਰੌਪੀ ਇਕੱਠੀ ਕਰਨਾ ਕੋਈ ਅਜਿਹੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ ਜੋ ਕਰਨਲ ਦੁਆਰਾ ਉਹਨਾਂ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰਾਂ 'ਤੇ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਿਸਦਾ ਇਹ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਕਰਨਲ ਖੁਦ ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਐਂਟਰੋਪੀ ਦੀ ਮਾਤਰਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦਾ ਹੈ।

"ਕਰਨਲ ਨੂੰ ਵੱਖੋ ਵੱਖਰੇ ਸ਼ੋਰ ਸਰੋਤਾਂ ਨੂੰ ਇਕੱਠਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਇਹ ਜਾਣਨ ਦਾ ਦਾਅਵਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਜਦੋਂ ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ CPU 'ਤੇ ਕਿਸੇ ਕਿਸਮ ਦੀ "ਟਵਿਚੀ ਐਂਟਰੋਪੀ ਗੇਮ" ਖੇਡਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ ਤਾਂ ਇਹ ਕਿੰਨੇ ਬਿੱਟ ਐਨਟ੍ਰੋਪੀ ਪ੍ਰਾਪਤ ਕਰ ਰਿਹਾ ਹੈ। ਉਪਭੋਗਤਾ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਆਰਕੀਟੈਕਚਰ। IOT/ਏਮਬੈਡਡ ਕੇਸ ਜਿੱਥੇ ਸਭ ਕੁਝ ਇੱਕ ਸਿੰਗਲ ਮਾਸਟਰ ਔਸਿਲੇਟਰ ਨਾਲ ਸਿੰਕ ਤੋਂ ਬਾਹਰ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਰਜਿਸਟਰ ਨੂੰ ਮੁੜ ਕ੍ਰਮਬੱਧ ਕਰਨ ਜਾਂ ਨਾਮ ਬਦਲਣ ਲਈ ਕੋਈ CPU ਨਿਰਦੇਸ਼ ਨਹੀਂ ਹੈ, ਆਦਿ।"

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

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

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

ਕੁਝ ਵਿਗਿਆਪਨ 🙂

ਸਾਡੇ ਨਾਲ ਰਹਿਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। ਕੀ ਤੁਹਾਨੂੰ ਸਾਡੇ ਲੇਖ ਪਸੰਦ ਹਨ? ਹੋਰ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਆਰਡਰ ਦੇ ਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਸਿਫਾਰਸ਼ ਕਰਕੇ ਸਾਡਾ ਸਮਰਥਨ ਕਰੋ, $4.99 ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਲਾਉਡ VPS, ਪ੍ਰਵੇਸ਼-ਪੱਧਰ ਦੇ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਐਨਾਲਾਗ, ਜਿਸਦੀ ਖੋਜ ਸਾਡੇ ਦੁਆਰਾ ਤੁਹਾਡੇ ਲਈ ਕੀਤੀ ਗਈ ਸੀ: VPS (KVM) E5-2697 v3 (6 ਕੋਰ) 10GB DDR4 480GB SSD 1Gbps ਤੋਂ $19 ਜਾਂ ਸਰਵਰ ਨੂੰ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰਨਾ ਹੈ ਬਾਰੇ ਪੂਰੀ ਸੱਚਾਈ? (RAID1 ਅਤੇ RAID10 ਦੇ ਨਾਲ ਉਪਲਬਧ, 24 ਕੋਰ ਤੱਕ ਅਤੇ 40GB DDR4 ਤੱਕ)।

ਡੈਲ R730xd ਐਮਸਟਰਡਮ ਵਿੱਚ ਈਕੁਇਨਿਕਸ ਟੀਅਰ IV ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ 2 ਗੁਣਾ ਸਸਤਾ? ਇੱਥੇ ਹੀ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ਟੀਵੀ $199 ਤੋਂ ਨੀਦਰਲੈਂਡ ਵਿੱਚ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ਤੋਂ! ਬਾਰੇ ਪੜ੍ਹੋ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕਾਰਪੋਰੇਸ਼ਨ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਡੇਲ R730xd E5-2650 v4 ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲਾਸ 9000 ਯੂਰੋ ਦੀ ਕੀਮਤ ਦੇ ਇੱਕ ਪੈਸੇ ਲਈ?

ਸਰੋਤ: www.habr.com