DJB ਅਤੇ ਨਿਰਮਾਣ-ਅਨੁਸਾਰ ਸੁਰੱਖਿਆ: qmail ਤੋਂ Curve25519

ਨਿਰਮਾਣ-ਅਨੁਸਾਰ ਸੁਰੱਖਿਆ ਦਾ ਕੀ ਮਤਲਬ ਹੈ (ਜਰਗਨ ਰਿਹਾ ਨਹੀਂ)\n\nSecurity-by-construction ਦਾ ਮਤਲਬ ਹੈ ਐਸਾ ਸਿਸਟਮ ਬਣਾਉਣਾ ਕਿ ਆਮ ਗਲਤੀਆਂ ਕਰਨਾ ਔਖਾ ਹੋਵੇ—ਅਤੇ ਜੇ ਕੋਈ ਗਲਤੀ ਹੋਵੇ ਤਾਂ ਉਸ ਦਾ ਨੁਕਸਾਨ ਸੀਮਤ ਰਹੇ। ਲੰਮੀ ਚੈੱਕਲਿਸਟ ('ਇੱਕਸ ਨੂੰ validate ਕਰੋ, ਵਾਈ ਨੂੰ sanitize ਕਰੋ, ਜੈਡ ਨੂੰ configure ਕਰੋ...') 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਸੋਫਟਵੇਅਰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਾਹ ਵੀ ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਹੋਵੇ।\n\nਇਸਨੂੰ ਬੱਚਿਆਂ ਲਈ ਐਨਕਪਿੰਗ ਵਾਂਗ ਸੋਚੋ: ਇਹ ਇਹ ਮੰਨਦਾ ਨਹੀਂ ਕਿ ਹਰ ਕੋਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਧਿਆਨਿਰਤ ਹੋਵੇਗਾ; ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਮਨੁੱਖ ਥਕੇ ਹੋਏ, ਵਿਅਸਤ ਅਤੇ ਕਦੀ-ਕਦੀ ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਚੰਗੀ ਡਿਜ਼ਾਈਨ ਇਸ ਗੱਲ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ ਕਿ ਵਿਕਾਸਕਾਰਾਂ, ਓਪਰੇਟਰਾਂ ਅਤੇ ਉਪਭੋਗਤਿਆਂ ਤੋਂ ਕਿੰਨੀ "ਪਰਫੈਕਟ ਬਿਹੇਵਿਯਰ" ਦੀ ਉਮੀਦ ਰੱਖਣੀ ਪੈਂਦੀ ਹੈ।\n\n### ਕਿਉਂ ਸਾਦਗੀ ਜੋਖਮ ਘਟਾਉਂਦੀ ਹੈ\n\nਸੁਰੱਖਿਆ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਜਟਿਲਤਾ ਵਿੱਚ ਲੁਕੀਆਂ ਹੁੰਦੀਆਂ ਹਨ: ਬਹੁਤ ਸਾਰੇ ਫੀਚਰ, ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ, ਕਮਪੋਨੈਂਟਾਂ ਦੇ ਆਕਾਰ-ਇੰਟਰੈਕਸ਼ਨ। ਹਰ ਇੱਕ ਵਾਧੂ ਨੋਬ ਨਵਾਂ ਫੇਲਅਰ ਮੋਡ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ—ਸਿਸਟਮ ਨੂੰ ਟੁੱਟਣ ਜਾਂ ਗਲਤ ਵਰਤੋਂ ਕਰਨ ਦਾ ਅਣਪਛਾਤਾ ਤਰੀਕਾ।\n\nਸਾਦਗੀ ਦੋ ਪ੍ਰਯੋਗਤਮਕ ਤਰੀਕਿਆਂ ਨਾਲ ਮਦਦ ਕਰਦੀ ਹੈ:\n\n- ਘੱਟ ਕੋਡ ਆਡੀਟ ਕਰਨ ਲਈ: ਘੱਟ ਬ੍ਰਾਂਚ, ਘੱਟ ਖਾਸ ਕੇਸ, ਘੱਟ ਛੁਪਿਆ ਹੋਇਆ ਬਿਹੇਵਿਯਰ।\n- ਘੱਟ ਗਲਤ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਦੇ ਤਰੀਕੇ: ਜਦ ਇੱਕ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹੋਵੇ ਨਾਂ ਕਿ ਦੱਸ ਵਿਕਲਪ, ਤਾਂ ਹਾਦਸਾਤਮਕ ਅਸੁਰੱਖਿਆ ਦੀ ਗੁੰਜਾਇਸ਼ ਘੱਟ ਹੁੰਦੀ ਹੈ।\n\nਇਹ ਆਪਣੀ ਹੀ ਖਾਤਰ ਮਿਨਿਮਲਿਜ਼ਮ ਨਹੀਂ ਹੈ। ਇਹ ਇਸ ਗੱਲ ਲਈ ਹੈ ਕਿ ਬਿਹੇਵਿਯਰ ਦਾ ਸੈੱਟ ਇਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਸਮਝ ਸਕੋ, ਟੈਸਟ ਕਰ ਸਕੋ ਅਤੇ ਸੋਚ ਸਕੋ ਕਿ ਕੁਝ ਗਲਤ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ।\n\n### ਇਹ ਪੋਸਟ ਕੀ ਕਵਰ ਕਰਦੀ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)\n\nਇਹ ਪੋਸਟ Daniel J. Bernstein ਦੇ ਕੰਮ ਨੂੰ security-by-construction ਦੇ ਸਰਗਰਮ ਉਦਾਹਰਣ ਵਜੋਂ ਵਰਤਦੀ ਹੈ: qmail ਨੇ ਕਿਵੇਂ ਫੇਲਅਰ ਮੋਡ ਘੱਟ ਕੀਤੇ, constant-time ਸੋਚ ਕਿਵੇਂ ਅਦਿੱਖ ਲੀਕਾਂ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ, ਅਤੇ Curve25519/X25519 ਅਤੇ NaCl ਕਿਵੇਂ ਐਸਾ crypto ਪ੍ਰੋਵਾਈਡ ਕਰਦੇ ਹਨ ਜੋ ਗਲਤ ਵਰਤੋਂ ਲਈ ਔਖਾ ਹੋਵੇ।\n\nਇਹ ਨਹੀਂ ਕਰੇਗੀ: ਕ੍ਰਿਪਟੋਗਰਾਫੀ ਦਾ ਪੂਰਾ ਇਤਿਹਾਸ ਦੱਸਣਾ, ਅਲਗੋਰਿਦਮਾਂ ਦੀ ਸੁਰੱਖਿਆ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ, ਜਾਂ ਇਹ ਦਾਵਾ ਕਰਨਾ ਕਿ ਹਰ ਪ੍ਰੋਡਕਟ ਲਈ ਇੱਕੋ "ਸਭ ਤੋਂ ਵਧੀਆ" ਲਾਇਬ੍ਰੇਰੀ ਹੈ। ਅਤੇ ਇਹ ਇਹ ਵੀ ਨਹੀਂ ਮੰਨੇਗੀ ਕਿ ਚੰਗੇ ਪ੍ਰਿਮਟਿਵਸ ਸਾਰੇ ਸਮੱਸਿਆਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਨ—ਅਸਲ ਸਿਸਟਮ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ ਕਿ ਕੀ-ਹੈਂਡਲਿੰਗ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਗਲਤੀਆਂ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਖ਼ਾਮੀਆਂ ਕਾਰਨ।\n\nਮਕਸਦ ਸਧਾਰਨ ਹੈ: ਐਸੇ ਡਿਜ਼ਾਈਨ ਪੈਟਰਨ ਦਿਖਾਉਣਾ ਜੋ ਸੁਰੱਖਿਅਤ ਨਤੀਜੇ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਵਧਾਉਂਦੇ ਹਨ, ਭਾਵੇਂ ਤੁਸੀਂ ਕ੍ਰਿਪਟੋਗਰਾਫੀ ਦੇ ਮਾਹਿਰ ਨਾ ਹੋਵੋ।\n\n## Daniel J. Bernstein ਕੌਣ ਹੈ ਅਤੇ ਲੋਕ ਉਸਦੇ ਕੰਮ ਦਾ ਹਵਾਲਾ ਕਿਉਂ ਦੇਂਦੇ ਹਨ\n\nDaniel J. Bernstein (ਅਕਸਰ “DJB”) ਇੱਕ ਗਣਿਤ ਅਤੇ ਕੰਪਿਊਟਰ ਵਿਗਿਆਨੀ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਕੰਮ ਪ੍ਰਯੋਗਤਮਕ ਸੁਰੱਖਿਆ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਵਾਰ-ਵਾਰ ਮਿਲਦੇ ਹਨ: ਈਮੇਲ ਸਿਸਟਮ (qmail), ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਪ੍ਰਿਮਟਿਵਸ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ (ਖਾਸ ਕਰ ਕੇ Curve25519/X25519), ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜੋ ਰੀਅਲ-ਵਰਲਡ ਲਈ crypto ਪੈਕੇਜ ਕਰਦੀਆਂ ਹਨ (NaCl)।\n\nਲੋਕ DJB ਨੂੰ ਇਸ ਲਈ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ ਕਿ ਉਹ ਇਕੋ "ਠੀਕ" ਤਰੀਕੇ ਦੇ ਲੇਖਕ ਨਹੀਂ ਹਨ, ਪਰ ਉਨ੍ਹਾਂ ਦੀਆਂ ਪ੍ਰਾਜੈਕਟਾਂ ਵਿੱਚ ਇੱਕ ਮਿਲਦੀ ਜੁਲਦੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸੋਚ ਹੁੰਦੀ ਹੈ ਜੋ ਗਲਤ ਹੋਣ ਦੇ ਤਰੀਕਿਆਂ ਦੀ ਗਿਣਤੀ ਘਟਾਉਂਦੀ ਹੈ।\n\n### ਇੰਜੀਨੀਅਰ DJB-ਸ਼ੈਲੀ ਕੰਮ ਤੋਂ ਕੀ ਸਿੱਖਦੇ ਹਨ\n\nਇੱਕ ਮੁੜ-ਆਉਣ ਵਾਲਾ ਥੀਮ ਹੈ ਛੋਟੇ, ਸਖਤ ਇੰਟਰਫੇਸ। ਜੇ ਇੱਕ ਸਿਸਟਮ ਘੱਟ ਐਂਟਰੀ-ਪਾਇੰਟ ਅਤੇ ਘੱਟ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਚੋਇਸਜ਼ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਡੀਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ, ਟੈਸਟ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਗਲਤੀ ਨਾਲ ਗਲਤ ਵਰਤੋਂ ਹੋਣ ਵਿੱਚ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।\n\nਦੂਜਾ ਥੀਮ ਹੈ ਖੁਲ੍ਹੇ ਤੌਰ 'ਤੇ ਧਾਰਨਾਵਾਂ ਦਾ ਦਰਸਾਉਣਾ। ਸੁਰੱਖਿਆ ਫੇਲਅਰ ਅਕਸਰ ਅਣਕਹੀਆਂ ਉਮੀਦਾਂ ਕਾਰਨ ਹੁੰਦੇ ਹਨ—ਰੈਂਡਮਨੈੱਸ, ਟਾਈਮਿੰਗ ਬਿਹੇਵਿਅਰ, error handling, ਜਾਂ ਕਿਸ ਤਰ੍ਹਾਂ ਚਾਬੀਆਂ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। DJB ਦੇ ਲੇਖ ਅਤੇ ਇੰਪਲੀਮੇнਟੇਸ਼ਨ ਅਕਸਰ ਥ੍ਰੈਟ ਮਾਡਲ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ: ਕੀ ਸੰਰੱਖਿਅਤ ਹੈ, ਕਿਸ ਤੋਂ, ਅਤੇ ਕਿਹੜੇ ਹਾਲਾਤਾਂ 'ਚ।\n\nਅੰਤ ਵਿੱਚ, ਇੱਕ ਰੁਝਾਨ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟਸ ਅਤੇ ਬੋਰੀਂਗ ਕਰੈਕਟਨੇਸ ਵੱਲ ਹੈ। ਇਸ ਰਵਾਇਤ ਦੀਆਂ ਕਈ ਡਿਜ਼ਾਈਨਾਂ ਤੇਜ਼ ਤਰਕੀਬਾਂ ਅਤੇ ਅਸਪਸ਼ਟ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਹਟਾਉਂਦੀਆਂ ਹਨ ਜੋ ਨਾਜ਼ੁਕ ਬੱਗ ਪੈਦਾਂ ਕਰਦੇ ਹਨ: ਅਸਪਸ਼ਟ ਪੈਰਾਮੀਟਰ, ਵਿਕਲਪਿਕ ਮੋਡ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸ਼ਾਰਟਕੱਟ ਜੋ ਜਾਣਕਾਰੀ ਲੀਕ ਕਰਦੇ ਹਨ।\n\n### ਜੀਵਨੀ ਨਹੀਂ—ਇੰਜੀਨੀਅਰਿੰਗ ਨਜ਼ਰੀਆ ਹੈ\n\nਇਹ ਲੇਖ ਜੀਵਨੀ ਜਾਂ ਨਜ਼ਰ-ਥਾਂਡੀ ਵਿਚਾਰ-वਿਮਰਸ਼ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ ਪਾਠ ਹੈ: qmail, constant-time ਸੋਚ, Curve25519/X25519, ਅਤੇ NaCl ਵਿੱਚ ਕਿਹੜੇ ਪੈਟਰਨ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਵਰਤ ਕੇ ਪ੍ਰਣਾਲੀਆਂ ਹੁਣ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਘੱਟ ਨਾਜੁਕ ਬਣਾਈਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।\n\n## qmail: ਘੱਟ ਫੇਲਅਰ ਮੋਡ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਇਕ ਪ੍ਰਯੋਗਤਮਕ ਮਿਸਾਲ\n\nqmail ਇੱਕ ਬਹੁਤ ਸਧਾਰਨ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ: ਈਮੇਲ ਨੂੰ ਭਰੋਸੇਮੰਦ ਤਰੀਕੇ ਨਾਲ ਡਿਲਿਵਰ ਕਰਨਾ ਜਿਸ ਦੌਰਾਨ ਮੈਲ ਸਰਵਰ ਇੱਕ ਉੱਚ-ਵੈਲਯੂ ਟਾਰਗੇਟ ਵਜੋਂ ਵਰਤਿਆ ਜਾਵੇ। ਮੈਲ ਸਿਸਟਮ ਇੰਟਰਨੈਟ 'ਤੇ ਰਹਿੰਦੇ ਹਨ, ਦਿਨ ਭਰ ਸ਼ਤਰੂ-ਪੂਰਨ ਇਨਪੁਟ ਸਵੀਕਾਰਦੇ ਹਨ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ (ਮੇਸੇਜ, ਕ੍ਰੈਡੈਂਸ਼ਲ, ਰੁਟਿੰਗ ਨਿਯਮ) ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਨ। ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ, ਇੱਕ ਬੱਗ ਇੱਕ ਮੋਨੋਲਿਥਿਕ ਮੈਲ ਡੈਮਨ ਵਿੱਚ ਪੂਰੇ ਸਿਸਟਮ ਰਾਹੀਂ ਕਮਪ੍ਰੋਮਾਈਜ਼ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਸੀ—ਜਾਂ ਚੁਪਚਾਪ ਮੇਸੇਜ ਲੋਸ ਹੋਣਾ ਜੋ ਬਹੁਤ ਦੇਰ ਬਾਅਦ ਪਤਾ ਲਗੇ।\n\n### ਕੰਮ ਵੰਡੋ, blast radius ਘਟਾਓ\n\nqmail ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ "ਮੇਲ ਡਿਲਿਵਰੀ" ਨੂੰ ਛੋਟੇ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ ਵੰਡੋ ਜਿਹੜੇ ਹਰ ਇੱਕ ਇਕ ਕੰਮ ਕਰਦੇ ਹਨ: ਰਿਸੀਵ ਕਰਨਾ, ਕਿਊਇੰਗ, ਲੋਕਲ ਡਿਲਿਵਰੀ, ਰਿਮੋਟ ਡਿਲਿਵਰੀ ਆਦਿ। ਹਰ ਹਿੱਸੇ ਦੀ ਇੱਕ ਪਾਤਰ ਇੰਟਰਫੇਸ ਅਤੇ ਸੀਮਤ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ।\n\nਇਹ ਵੰਡ ਅਹੰਕਾਰਕ ਹੈ ਕਿਉਂਕਿ ਫੇਲਅਰ ਲੋਕਲ ਹੋ ਜਾਂਦੇ ਹਨ:\n\n- ਜੇ ਇਕ ਕੰਪੋਨੈਂਟ ਕਰੈਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕਿਊ ਨੂੰ ਕਰਪਟ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਸਾਰਾ ਸਿਸਟਮ ਡਾਊਨ ਨਹੀਂ ਹੁੰਦਾ।\n- ਜੇ ਇਕ ਕੰਪੋਨੈਂਟ ਵਿਚ ਸੁਰੱਖਿਅਤ ਬੱਗ ਹੈ, ਤਾਂ ਹਮਲਾਵਰ ਤੁਰੰਤ ਹਰ ਹੋਰ ਹਿੱਸੇ ਦੀ ਪ੍ਰਿਵਿਲੇਜਸ ਨਹੀਂ ਪ੍ਰਾਪਤ ਕਰ ਲੈਂਦਾ।\n- ਜੇ ਤੁਸੀਂ ਇੱਕ ਕੰਪੋਨੈਂਟ ਨੂੰ ਅਲੱਗ ਤੋਂ ਤਰਕ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਬੇਹਤਰ ਤਰੀਕੇ ਨਾਲ ਟੈਸਟ ਅਤੇ ਆਡਿਟ ਕਰ ਸਕਦੇ ਹੋ।\n\nਇਹ security-by-construction ਦਾ ਪ੍ਰਯੋਗਤਮਕ ਰੂਪ ਹੈ: ਸਿਸਟਮ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ "ਇੱਕ ਗਲਤੀ" ਨੂੰ "ਸੰਪੂਰਣ ਫੇਲ" ਬਣਨ ਦਾ ਰਸਤਾ ਘੱਟ ਹੋਵੇ।\n\n### ਨਕਲ ਕਰਨ ਜਾਇਕ ਡਿਜ਼ਾਈਨ ਆਦਤਾਂ\n\nqmail ਉਹ ਆਦਤਾਂ ਵੀ ਮਾਡਲ ਕਰਦਾ ਹੈ ਜੋ ਈਮੇਲ ਤੋਂ ਬਾਹਰ ਵੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ:\n\n- ਸਪਸ਼ਟ ਸਰਹੱਦ: ਇੱਕ ਕੰਪੋਨੈਂਟ ਕੀ ਇਨਪੁਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਕੀ ਆਉਟਪੁੱਟ ਦਿੰਦਾ ਹੈ, ਇਹ ਸਪਸ਼ਟ ਪਰਿਭਾਸ਼ਤ ਕਰੋ। ਛੋਟੇ, ਸਪਸ਼ਟ ਕਰਾਰ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।\n- ਕੜੀ ਇਨਪੁੱਟ ਹੈਂਡਲਿੰਗ: ਨੈਟਵਰਕ ਤੋਂ ਆਉਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਸੰਭਾਵਤ ਖ਼ਤਰਨਾਕ ਸਮਝੋ; ਜਲਦੀ validate ਕਰੋ, ਅਜਿਹੇ ਕੇਸ ਰੱਦ ਕਰੋ ਅਤੇ "ਮਦਦਗਾਰ" ਅਨੁਮਾਨ ਕਰਨ ਤੋਂ ਬਚੋ।\n- ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਡਿਫਾਲਟ: ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਅਧਿਕਾਰ ਦਿਓ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਲੋੜੀਦੇ ਹਨ, ਤਾਂ ਕਿ ਇੱਕ ਬੱਗ ਨਾਲ ਪੂਰੀ ਕਬਜ਼ਾ ਆਸਾਨ ਨ ਹੋਵੇ।\n\nਟੇਕਅਵੇ ਇਸਦਾ ਇਹ ਨਹੀਂ ਕਿ "qmail ਵਰਤੋ"। ਇਹ ਇਹ ਹੈ ਕਿ ਅਕਸਰ ਤੁਸੀਂ ਵੱਡੇ ਸੁਰੱਖਿਆ ਲਾਭ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਖ਼ਤਰਨਾਕ ਫੇਲਅਰ ਮੋਡ ਬਣਾਉਂਦੇ ਹਨ—ਇਹ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਹੋਰ ਕੋਡ ਲਿਖੋ ਜਾਂ ਹੋਰ ਨੋਬ ਜੋੜੋ।\n\n## ਟਾਇਮ-ਟਾਈਮ ਸੋਚ: ਉਹ ਲੀਕਾਂ ਰੋਕੋ ਜੋ ਤੁਸੀਂ ਦੇਖ ਨਹੀਂ ਸਕਦੇ\n\n"Constant-time" ਬਰਤਾਵ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਗਣਨਾ (ਲਗਭਗ) ਇੱਕੋ ਸਮਾਂ ਲੈਂਦੀ ਹੈ ਭਾਵੇਂ ਰਾਜ਼ੀ ਮੁੱਲ ਕੀ ਹੋਣ। ਮਕਸਦ ਤੇਜ਼ ਹੋਣਾ ਨਹੀਂ; ਮਕਸਦ ਹੈ "ਬੋਰਿੰਗ" ਰਹਿਣਾ: ਜੇ ਹਮਲਾਵਰ ਰਨਟਾਈਮ ਨੂੰ ਰਾਜ਼ਾਂ ਨਾਲ ਜੋੜ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਉਹਨਾਂ ਲਈ ਰਾਜ਼ ਬਾਹਰ ਕੱਢਣਾ ਬਹੁਤ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ।\n\nਟਾਈਮਿੰਗ ਲੀਕ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਹਮਲਾਵਰ ਹਮੇਸ਼ਾਂ ਗਣਿਤ ਤੋੜਨ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦੇ। ਜੇ ਉਹ ਇੱਕੋ ਆਪਰੇਸ਼ਨ ਕਈ ਵਾਰੀ ਚਲਾ ਸਕਦੇ ਹਨ (ਜਾਂ ਸਾਂਝੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦੇ ਹਨ), ਤਾਂ ਛੋਟੇ ਫਰਕ—ਮਾਈਕ्रोਸੈਕੰਡ, ਨੈਨੋਸੈਕੰਡ, ਜਾਂ ਕੈਸ਼ ਪ੍ਰਭਾਵ—ਅਜਿਹਾ ਪੈਟਰਨ ਦਿਖਾ ਸਕਦੇ ਹਨ ਜੋ ਰਾਜ਼ੀ ਮੁੱਲਾਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ।\n\n### ਟਾਈਮਿੰਗ ਤਬਦੀਲੀ ਕਿੱਥੇ ਆਉਂਦੀ ਹੈ\n\nਆਮ ਕੋਡ ਵੀ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਹੋ ਕੇ ਵੱਖਰਾ ਵਰਤਾਅ ਦਿਖਾ ਸਕਦਾ ਹੈ:\n\n- ਰਾਜ਼ੀ ਡੇਟਾ 'ਤੇ ਆਧਾਰਤ ਬ੍ਰਾਂਚ: if (secret_bit) { ... } ਕੰਟਰੋਲ ਫਲੋ ਤੇ runtime ਨੂੰ ਬਦਲਦਾ ਹੈ।\n- ਰਾਜ਼ਾਂ ਨਾਲ index ਕੀਤੇ ਗਏ ਟੇਬਲ ਲੁੱਕਅੱਪ: ਗੁਪਤਆਧਾਰਤ ਇੰਡੈਕਸ ਵੱਖਰੇ ਕੈਸ਼ ਲਾਈਨਾਂ ਖਿੱਚ ਸਕਦੇ ਹਨ।\n- ਕੈਸ਼ ਅਤੇ ਮੇਮੋਰੀ ਪ੍ਰਭਾਵ: ਗੁਪਤ-ਨਿਰਭਰ ਮੇਮੋਰੀ ਐਕਸੈੱਸ ਪੈਟਰਨ CPU caches, page faults, ਜਾਂ prefetching ਰਾਹੀਂ ਲੀਕ ਕਰ ਸਕਦੇ ਹਨ।\n- ਵੈਰੀਏਬਲ-ਟਾਈਮ ਇੰਸਟਰਕਸ਼ਨ: ਕੁਝ big-number operations, division, ਜਾਂ early-exit loops ਕੁਝ ਇਨਪੁੱਟ ਲਈ ਵੱਧ ਸਮਾਂ ਲੈਂਦੇ ਹਨ।\n\n### ਟਾਈਮਿੰਗ ਰਿਸਕ ਲਈ ਉੱਚ-ਪੱਧਰੀ ਆਡਿਟ ਤਰੀਕੇ\n\nਤੁਹਾਨੂੰ<Assembly> ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ:\n\n1. ਰਾਜ਼ੀ ਪ੍ਰਭਾਵ ਨੂੰ ਟਰੇਸ ਕਰੋ: ਕਿਹੜੇ ਵੇਰੀਏਬਲ ਗੁਪਤ ਹਨ (private keys, shared secrets, authentication tags) ਅਤੇ ਉਹ ਕਿੱਥੇ ਫਲੋ ਕਰਦੇ ਹਨ।\n2. ਲਾਲ ਝੰਡੇ ਲੱਭੋ: ਰਾਜ਼ੀ-ਨਿਰਭਰ if ਬਿਆਨ, array ਇੰਡੈਕਸ, ਸਿਕਰਟ-ਆਧਾਰਤ ਟਰਮੀਨੇਸ਼ਨ ਵਾਲੇ ਲੂਪ, ਅਤੇ "ਫਾਸਟ ਪਾਥ/ਸਲੋ ਪਾਥ" ਲੌਜਿਕ।\n3. Dependencies ਨੂੰ threat model ਦਾ ਹਿੱਸਾ ਮਾਨੋ: ਯਕੀਨੀ ਬਣਾਓ ਕਿ crypto library ਦਾ ਖ਼ਾਸ ਦਾਅਵਾ ਹੈ ਕਿ ਰਿਲੈਵੈਂਟ operations constant-time ਹਨ।\n4. ਵੈਰੀਅੰਸ ਦੀ ਜਾਂਚ ਕਰੋ: ਵੱਖ-ਵੱਖ ਰਾਜ਼ਾਂ ਨਾਲ ਆਪਰੇਸ਼ਨ ਕਈ ਵਾਰੀ ਚਲਾਓ ਅਤੇ ਵੰਡਾਂ ਮਾਪੋ; ਵੱਡੇ, ਸਥਾਈ ਫਰਕ ਚੇਤਾਵਨੀ ਹਨ।\n\nConstant-time ਸੋਚ ਹੀਰੋਇਕ ਕੰਮ ਨਹੀਂ—ਇਹ ਅਨੁਸ਼ਾਸਨ ਬਾਰੇ ਹੈ: ਕੋਡ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਰਾਜ਼ ਟਾਈਮਿੰਗ ਨੂੰ ਨਿਰਦੇਸ਼ਿਤ ਨਾ ਕਰ ਸਕਣ।\n\n## Curve25519 ਅਤੇ X25519: ਗਲਤ ਵਰਤੋਂ ਲਈ ਔਖਾ ਬਣਾਇਆ ਗਿਆ crypto\n\nElliptic-curve key exchange ਉਸ ਤਰੀਕੇ ਨੂੰ ਕਹਿੰਦੇ ਹਨ ਜਿਸ ਨਾਲ ਦੋ ਡਿਵਾਈਸ ਇੱਕੋ shared secret ਬਣਾਉਂਦੇ ਹਨ ਹਾਲਾਂਕਿ ਉਹ ਸਿਰਫ਼ public messages ਨੈੱਟਵਰਕ 'ਤੇ ਭੇਜਦੇ ਹਨ। ਹਰ ਪੱਖ private value ਬਣਾਉਂਦਾ ਹੈ (ਰਾਜ਼ ਰੱਖਿਆ) ਅਤੇ ਇਕ public value ਜੋ ਭੇਜੀ ਜਾ ਸਕਦੀ ਹੈ। public values ਦੇ ਅਦਲਾ-ਬਦਲੀ ਤੋਂ ਬਾਅਦ, ਦੋਹਾਂ ਆਪਣੇ private value ਨੂੰ ਦੂਜੇ ਪੱਖ ਦੀ public value ਨਾਲ ਜੋੜ ਕੇ ਇਕੋ shared secret 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ। ਇਕ ਸਨਦੀਖਰ public values ਦੇਖਦਾ ਹੈ ਪਰ shared secret ਨੂੰ ਵਸ ਤੋਰ 'ਤੇ ਬਣਾਉਣਾ ਨਾ-ਮਮਕਿਨ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਦੋ ਪੱਖ ਫਿਰ symmetric encryption ਦੀਆਂ keys ਨਿਕਾਲ ਕੇ ਪਰਦੇਸੀ ਤੌਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰ ਸਕਦੇ ਹਨ।\n\n### Curve25519/X25519 ਕਿਉਂ ਲੋਕਪ੍ਰਿਯ ਹੋਏ\n\nCurve25519 ਮੂਲ ਕਰਵ ਹੈ; X25519 ਇੱਕ ਨਿਯਮਬੱਧ, "ਇਹ ਖਾਸ ਕੰਮ ਕਰੋ" key-exchange ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਇਸ ਦੇ ਉਪਰ ਬਣਾਇਆ ਗਿਆ। ਉਹਨਾਂ ਦੀ ਆਕਰਸ਼ਣ ਮੁੱਖ ਤੌਰ 'ਤੇ security-by-construction ਹੈ: ਘੱਟ foot-guns, ਘੱਟ ਪੈਰਾਮੀਟਰ ਚੋਣਾਂ, ਅਤੇ ਘੱਟ ਤਰੀਕੇ ਜਿਹੜੇ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਅਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗ ਚੁਣ ਸਕਦੇ ਹੋ।\n\nਉਹ ਤੇਜ਼ ਵੀ ਹਨ ਵੱਖ-ਵੱਖ ਹਾਰਡਵੇਅਰ 'ਤੇ, ਜੋ ਸੇਰਵਰਾਂ ਅਤੇ ਫੋਨਾਂ ਦੋਹਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਅਤੇ ਡਿਜ਼ਾਈਨ ਐਸੀਆਂ ਇੰਪਲੀਮੇਨਟੇਸ਼ਨਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ ਜੋ constant-time ਰੱਖਣ ਵਿੱਚ ਆਸਾਨ ਹਨ (ਟਾਈਮਿੰਗ ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ), ਜੋ ਰਾਜ਼ਾਂ ਨੂੰ ਛੋਟੇ ਪ੍ਰਦਰਸ਼ਨ ਫਰਕਾਂ ਨਾਲ ਬਾਹਰ ਕੱਢਣ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦਾ ਹੈ।\n\n### ਇਹ ਕੀ ਦਿੰਦਾ ਹੈ—ਅਤੇ ਕੀ ਨਹੀਂ ਦਿੰਦਾ\n\nX25519 ਤੁਹਾਨੂੰ key agreement ਦਿੰਦਾ ਹੈ: ਇਹ ਦੋ ਪੱਖਾਂ ਨੂੰ shared secret ਨਿਕਾਲਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜੋ ਬਾਅਦ ਵਿੱਚ symmetric encryption ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।\n\nਇਹ ਖੁਦ authentication ਨਹੀਂ ਦਿੰਦਾ। ਜੇ ਤੁਸੀਂ X25519 ਨੂੰ ਇਸਤੋਂ ਬਿਨਾਂ ਚਲਾਉਂਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨਾਲ ਗੱਲ ਕਰ ਰਹੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ ਸਰਟੀਫਿਕੇਟ, ਸਿਗਨੇਚਰ, ਜਾਂ ਪ੍ਰੀ-ਸ਼ੇਅਰ ਕੀ ਨਾਲ), ਤਾਂ ਤੁਹਾਨੂੰ ਫਿਰ ਵੀ ਗਲਤ ਪਾਰਟੀ ਵੱਲ ਧੋਖਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ: X25519 eavesdropping ਰੋਕਦਾ ਹੈ, ਪਰ impersonation ਖੁਦ-ਬ-ਖੁਦ ਨਹੀਂ ਰੋਕਦਾ।\n\n## NaCl ਦਾ ਵੱਡਾ ਵਿਚਾਰ: ਘੱਟ ਚੋਇਸز, ਘੱਟ ਗਲਤੀਆਂ\n\nNaCl ("Networking and Cryptography library") ਇਕ ਸਧਾਰਨ ਲਕੜੀ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਸੀ: ਐਪ ਡਿਵੈਲਪਰਾਂ ਲਈ ਅਣਜਾਣਵੀਂ ਅਸੁਰੱਖਿਅਤ ਕ੍ਰਿਪਟੋ ਜੋੜਨ ਨੂੰ ਔਖਾ ਬਣਾਉਣਾ। ਬਹੁਤ ਸਾਰੇ algorithms, modes, padding rules, ਅਤੇ configuration knobs ਦੇ ਬਜਾਏ, NaCl ਤੁਹਾਨੂੰ ਉੱਚ-ਸਤਰ ਦੇ ਕੁਝ ਓਪਰੇਸ਼ਨਾਂ ਵੱਲ ਧਕੇਲਦੀ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਜੋੜੇ ਹੁੰਦੇ ਹਨ।\n\n### “box” ਅਤੇ “secretbox” ਸੁਰੱਖਿਅਤ ਬਿਲਡਿੰਗ ਬਲਾਕ ਵਜੋਂ\n\nNaCl ਦੀਆਂ API ਉਹਨਾਂ ਕੰਮਾਂ ਦੇ ਨਾਮ 'ਤੇ ਨਾਂ ਮਿਲਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਨਾ ਕਿ ਇਸ ਗੱਲ ਤੇ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਪ੍ਰਿਮਟਿਵਸ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ।\n\n- crypto_box ("box"): public-key authenticated encryption। ਤੁਸੀਂ ਆਪਣਾ private key, ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ public key, ਇਕ nonce, ਅਤੇ message ਦਿੰਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਇੱਕ ciphertext ਮਿਲਦਾ ਹੈ ਜੋ (a) message ਨੂੰ ਛੁਪਾਂਦਾ ਹੈ ਅਤੇ (b) ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸੇ ਨੇ ਸਹੀ key ਜਾਣਦਿਆਂ ਭੇਜਿਆ ਹੈ।\n- crypto_secretbox ("secretbox"): shared-key authenticated encryption। ਉਹੀ ਖਿਆਲ, ਪਰ ਇਕ shared secret key ਨਾਲ।\n\nਮੁੱਖ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ "encryption mode" ਅਤੇ "MAC algorithm" ਅਲੱਗ-ਅਲੱਗ ਚੁਣਕੇ ਉਨ੍ਹਾਂ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਜੋੜਨ ਤੋਂ ਬਚਦੇ ਹੋ। NaCl ਦੇ ਡਿਫਾਲਟ ਅਧੁਨਿਕ, misuse-resistant ਸੰਯੋਜਨਾਂ (encrypt-then-authenticate) ਨੂੰ ਬਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਆਮ failure modes—ਜਿਵੇਂ integrity checks ਭੁੱਲ ਜਾਣਾ—ਘੱਟ ਹੋ ਜਾਂਦੇ ਹਨ।\n\n### ਤਰਕ-ਤਰਕ: ਘੱਟ ਚੋਇਸਜ਼ ਬਨਾਮ ਲਚਕੀਲਾਪਣ\n\nNaCl ਦੀ ਸਖਤੀ ਉਹਨਾਂ ਲਈ ਸੀਮਤ ਮਹਿਸੂਸ ਹੋ ਸਕਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਲੈਗਸੀ ਪ੍ਰੋਟੋਕੋਲ, ਵਿਸ਼ੇਸ਼ ਫਾਰਮੈਟ, ਜਾਂ ਨਿਯਮਤਲਾਗੂ ਐਲਗੋਰਿਦਮਾਂ ਨਾਲ ਕੰਪੈਟਿਬਿਲਿਟੀ ਦੀ ਲੋੜ ਹੋਵੇ। ਤੁਸੀਂ "ਹਰ ਪੈਰਾਮੀਟਰ ਨੂੰ ਟਿਊਨ ਕਰਨ" ਦੇ ਬਦਲੇ "ਬਿਨਾਂ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਵਿਸ਼ੇਸ਼ਜ੍ञ ਹੋਏ ਕੁਝ ਸੁਰੱਖਿਅਤ ਚੀਜ਼ਾਂ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ" ਨੂੰ ਤਰਜੀਹ ਦੇ ਰਹੇ ਹੋ।\n\nਕਈ ਪ੍ਰੋਡਕਟਾਂ ਲਈ, ਇਹੀ ਮਕਸਦ ਹੈ: ਡਿਜ਼ਾਈਨ ਸਪੇਸ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰੋ ਤਾਂ ਕਿ ਘੱਟ ਬੱਗ ਹੋ ਸਕਣ। ਜੇ ਤੁਹਾਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਨਿਚਲੇ-ਸਤਰ ਦੇ ਪ੍ਰਿਮਟਿਵਸ ਉੱਤੇ ਜਾ ਸਕਦੇ ਹੋ—ਪਰ ਫਿਰ ਤੁਸੀਂ ਖੁਦ ਨੂੰ ਮੁੜ-ਤੇਜ਼ ਧਾਰ ਵਾਲੇ ਖ਼ਤਰਿਆਂ ਵਿੱਚ ਲਿਆਉਂਦੇ ਹੋ।\n\n## ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਅਤੇ ਬਹੁਤ ਏਨੇ ਨੋਬਾਂ ਦੀ ਲਾਗਤ\n\n"Default ਸੁਰੱਖਿਅਤ" ਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ, ਅਤੇ ਤਰਕਸੰਗਤ ਵਿਕਲਪ ਤੁਹਾਨੂੰ ਉਹ ਮਿਲਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰਦੇ। ਜੇ ਕੋਈ ਡਿਵੈਲਪਰ ਲਾਇਬ੍ਰੇਰੀ ਇੰਸਟਾਲ ਕਰਦਾ ਹੈ, ਇੱਕ ਤੇਜ਼ ਉਦਾਹਰਨ ਨਕਲ ਕਰਦਾ ਹੈ, ਜਾਂ ਫਰੇਮਵਰਕ ਡਿਫਾਲਟ ਵਰਗੇ ਚਲਦਾ ਹੈ, ਨਤੀਜਾ ਅਕਸਰ ਅਸੁਰੱਖਿਅਤ ਹੋਣ ਲਈ ਮੁਸ਼ਕਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।\n\nਡਿਫਾਲਟ ਮੈਟਰ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਵਿਆਦਿਕ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਿਸਟਮ ਉਨ੍ਹਾਂ 'ਤੇ ਚੱਲਦੇ ਹਨ। ਟੀਮ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ, ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ ਸਿਰਫ਼ ਸਕਿਮ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਆਰਗੈਨਿਕ ਤਰੀਕੇ ਨਾਲ ਵਧਦਾ ਹੈ। ਜੇ ਡਿਫਾਲਟ "ਲਚਕੀਲਾ" ਹੈ, ਤਾਂ ਇਹ ਅਕਸਰ "ਗਲਤ ਕਨਫ਼ਿਗਰ ਕਰਨਾ ਆਸਾਨ" ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ।\n\n### ਡਿਫਾਲਟ ਕਿਵੇਂ ਚੁਪਚਾਪ ਜੋਖਮ ਪੈਦਾ ਕਰਦੇ ਹਨ\n\nਕ੍ਰਿਪਟੋ ਫੇਲਅਰ ਆਮ ਤੌਰ 'ਤੇ "ਖਰਾਬ ਗਣਿਤ" ਨਾਲ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਅਕਸਰ ਖਤਰਨਾਕ ਸੈਟਿੰਗ ਚੁਣਨ ਨਾਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਉਪਲਬਧ, ਜਾਣੂ, ਜਾਂ ਆਸਾਨ ਸੀ।\n\nਆਮ ਡਿਫਾਲਟ陷阱 ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:\n\n- ਨਾਜੁਕ ਜਾਂ ਪੇਸ਼ਗੀ ਜਾਣ ਕੇ randomness: non-cryptographic PRNG ਵਰਤਣਾ, seeds ਦੁਹਰਾਉਣਾ, ਜਾਂ containers/VMs ਵਿੱਚ ਘੱਟ-ਐਨਟਰੋਪੀ ਸੋਰਸਾਂ 'ਤੇ fallback। ਜੇ key generation ਘੱਟ randomness 'ਤੇ ਨਿਰਭਰ ਹੈ ਤਾਂ ਸਭ ਕੁਝ ਕੁਝ ਕਮਜ਼ੋਰ ਹੋ ਜਾਂਦਾ ਹੈ।\n- ਕੰਪੈਟਿਬਿਲਿਟੀ ਲਈ ਜਿਆਦਾ ਸਮਾਂਤਰ ਅਲਗੋਰਿਦਮ ਰਹਿਣਾ: SHA-1, MD5, ਜਾਂ ਪੁਰਾਣੀਆਂ RSA ਸਾਈਜ਼ਾਂ ਨੂੰ "ਕਦੇ-ਕਦੇ" ਵਰਤਣ ਲਈ ਖੁੱਲ੍ਹਾ ਛੱਡਣਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਲੱਗਣਾ ਕਿ ਸਿਸਟਮ ਉਹਨਾਂ ਨੂੰ ਹਕੀਕਤ ਵਿੱਚ ਵਰਤ ਰਿਹਾ ਹੈ।\n- ਅਜੀਬ/ਕਸਟਮ ਮੋਡ ਅਤੇ ਪੈਰਾਮੀਟਰ: ਬਹੁਤ ਸਾਰੇ ਨੋਬ ਬਲਾਕ ਸਾਈਫਰ ਮੋਡ, padding ਨਿਯਮ, nonce ਹੈਂਡਲਿੰਗ, ਜਾਂ ਘਰੇਲੂ ਸਕੀਮਾਂ ਲਈ। ਜਿੰਨੀ ਵੱਧ ਚੋਇਸ ਹੈ, ਉੱਨੀ ਵੱਧ ਰਸਤੇ ਹਨ ਜੋ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਇਕ ਐਸਾ ਪ੍ਰੋਟੋਕੋਲ ਬਣਾਵੋ ਜੋ ਦਿੱਖ ਵਿੱਚ ਇਨਕ੍ਰਿਪਟਡ ਹੋਵੇ ਪਰ ਸੁਰੱਖਿਅਤ ਨਾ ਹੋਵੇ।\n\n### ਇਕ ਪ੍ਰਯੋਗਤਮਕ ਨਿਯਮ: ਘੱਟ ਵਿਕਲਪ, ਸੁਰੱਖਿਅਤ ਨਤੀਜੇ\n\nਉਹਨਾਂ ਸਟੈਕਸ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਸੁਰੱਖਿਅਤ ਰਾਹ ਨੂੰ ਸਭ ਤੋਂ ਆਸਾਨ ਰਾਹ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਪ੍ਰੀ-ਸਮੀਖਿਆ ਕੀਤੇ ਪ੍ਰਿਮਟਿਵਸ, ਸੰਰਕਸ਼ਿਤ ਪੈਰਾਮੀਟਰ, ਅਤੇ ਐਪੀਜ਼ ਜੋ ਤੁਸੀਂ ਨਾਜੁਕ ਫੈਸਲੇ ਕਰਨ ਲਈ ਨਹੀਂ ਪੁੱਛਦੇ। ਜੇ ਇਕ ਲਾਇਬ੍ਰੇਰੀ ਤੁਹਾਨੂੰ ਦਸ ਅਲਗੋਰਿਦਮ, ਪੰਜ ਮੋਡ, ਅਤੇ ਕਈ ਐਨਕੋਡਿੰਗਾਂ ਦੇ ਵਿਚਕਾਰ ਚੁਣਨ ਲਈ ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ configuration ਰਾਹੀਂ ਸੁਰੱਖਿਆ ਇੰਜੀਨੀਅਰਿੰਗ ਕਰ ਰਹੇ ਹੋ।\n\nਜਦੋਂ ਸੰਭਵ ਹੋਵੇ, ਉਹ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਡਿਜ਼ਾਈਨਾਂ ਚੁਣੋ ਜੋ:

\n- ਮਾਡਰਨ, ਚਰਚਿਤ ਅਲਗੋਰਿਦਮਾਂ ਨੂੰ ਡਿਫਾਲਟ ਰੱਖਦੀਆਂ ਹਨ