ಹಂಚಿಕೆಯ DH ಗುಂಪು, ಹೊಸ ರಹಸ್ಯಗಳು: ದಾಳಿ ಏಕೆ ಅಗ್ಗವಾಗುತ್ತದೆ

ಗುಂಪಿನ ನಿಯತಾಂಕಗಳು ವಿನ್ಯಾಸದಿಂದಲೇ ಸಾರ್ವಜನಿಕ, ಮತ್ತು ಆ ಸಾರ್ವಜನಿಕತೆಯೇ ಅವುಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ. ಸೀಮಿತ-ಕ್ಷೇತ್ರ Diffie-Hellman ನಲ್ಲಿ ಮಾಡ್ಯುಲಸ್ ಮತ್ತು ಜನರೇಟರ್ ಹಂಚಿಕೆಯಾಗಿರುತ್ತವೆ, ಆದರೆ ಖಾಸಗಿ ಘಾತಗಳು ಮತ್ತು ಅವುಗಳಿಂದ ಉಂಟಾಗುವ ಸೆಷನ್ ಕೀಗಳು ಹಂಚಿಕೆಯಾಗುವುದಿಲ್ಲ. ಸಂಖ್ಯಾ-ಕ್ಷೇತ್ರ ಜರಡಿ ದಾಳಿಯ ದುಬಾರಿ ಹಂತವು ಒಂದು ವಿನಿಮಯದ ಮೇಲಲ್ಲ, ಗುಂಪಿನ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಆದ್ದರಿಂದ ಎಲ್ಲೆಡೆ ಬಳಸುವ ಒಂದು ದುರ್ಬಲ ಗುಂಪು ಹಂಚಿದ ಹೊಣೆಗಾರಿಕೆಯಾಗುತ್ತದೆ. ನಿಯತಾಂಕಗಳನ್ನು ಸಾರ್ವಜನಿಕ ಎಂದು ಕರೆಯುವುದು ನಿಖರ ಮತ್ತು ವಿಷಯದ ಹೊರಗೆ, ಏಕೆಂದರೆ ಮರುಬಳಕೆಯಾಗುವ ವೆಚ್ಚವು ಅದೇ ಗುಂಪಿನ ಮೇಲಿನ ದಾಳಿಯ ವೆಚ್ಚವಾಗಿದೆ.

ಸಾರ್ವಜನಿಕ ಅರ್ಧವು ದುರ್ಬಲ ಅರ್ಧವಲ್ಲ, ಮತ್ತು ಅಲ್ಲಿಯೇ ಬಲೆ

ಸಾಮಾನ್ಯ ಅರ್ಧ-ವಾದವು ಹೇಳುವುದು, ನಿಯತಾಂಕಗಳು ಒಂದು ಮಾನದಂಡದಲ್ಲಿ ಪ್ರಕಟವಾಗಿವೆ, ಆದ್ದರಿಂದ ದಾಳಿಕೋರನಿಗೆ ಅವು ಈಗಾಗಲೇ ತಿಳಿದಿವೆ ಮತ್ತು ಅವನ್ನು ಮರೆಮಾಡುವುದರಿಂದ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಎರಡೂ ಹೇಳಿಕೆಗಳು ನಿಜ, ಮತ್ತು ಒಂದರಿಂದ ಇನ್ನೊಂದು ಅನುಸರಿಸುವುದಿಲ್ಲ. ಒಳಗೊಂಡಿರುವ ಡೀಫಾಲ್ಟ್ ಗುಂಪು ಸಾರ್ವಜನಿಕ, ಮತ್ತು ಕಳೆದ ವಾರ ನೀವು ರಚಿಸಿದ ಖಾಸಗಿ ಗುಂಪು ಕೂಡ ಕೈಕುಲುಕನ್ನು ಪೂರ್ಣಗೊಳಿಸುವ ಯಾರಿಗಾದರೂ ಗೋಚರವಾಗಿದೆ. ಗೋಪ್ಯತೆ ಎಂದಿಗೂ ನಿಯಂತ್ರಣವಾಗಿರಲಿಲ್ಲ; ಶಕ್ತಿ ಮತ್ತು ಮೌಲ್ಯೀಕರಣವೇ ನಿಯಂತ್ರಣ.

ಬದಲಾಗುವುದು ಏನೆಂದರೆ, ಒಂದೇ ದೌರ್ಬಲ್ಯವನ್ನು ಎಷ್ಟು ಸ್ಥಳಗಳು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದು. ತನ್ನದೇ 2048-ಬಿಟ್ ಗುಂಪನ್ನು ರಚಿಸುವ ಸಂಸ್ಥೆ ತನ್ನದೇ ದಾಳಿಯ ವೆಚ್ಚವನ್ನು ತೆರುತ್ತದೆ, ಆದರೆ ಲಕ್ಷಾಂತರ ಮಂದಿ ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರೋಟೋಕಾಲ್ ಡೀಫಾಲ್ಟ್ ಒಂದು ವೆಚ್ಚವನ್ನು ಅವರೆಲ್ಲರ ಮೇಲೆ ಹಂಚುತ್ತದೆ. ಆ ಅರ್ಥದಲ್ಲಿ ಅಸಾಮಾನ್ಯ ಗುಂಪು ತಾನಾಗಿಯೇ ಉತ್ತಮವಲ್ಲ. ತುಂಬಾ ಚಿಕ್ಕದಾದ ಅಸಾಮಾನ್ಯ ಗುಂಪು ಕಡಿಮೆ ಕಣ್ಣುಗಳಿರುವ ಚಿಕ್ಕ ಹಂಚಿದ ರಹಸ್ಯ ಮಾತ್ರ.

ಮೌಲ್ಯೀಕರಣವು ಗಾತ್ರದಷ್ಟೇ ಮುಖ್ಯ. ಸಣ್ಣ ಅಂಶಗಳಿರುವ ಮಾಡ್ಯುಲಸ್ ಕಳುಹಿಸುವ ಸಹಚರ, ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ ನಿರೀಕ್ಷಿಸುವ ಆಕಾರವಿಲ್ಲದ ಮಾಡ್ಯುಲಸ್, ಬಿಟ್ ಉದ್ದವು ಗೌರವಾರ್ಹವಾಗಿ ಕಂಡರೂ ಖಾಸಗಿ ಘಾತದ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸೋರಿಸಬಹುದು. ಪ್ರವೇಶದ್ವಾರದಲ್ಲೇ ವಿಕೃತ ನಿಯತಾಂಕಗಳನ್ನು ತಿರಸ್ಕರಿಸುವ ಗ್ರಂಥಾಲಯಗಳು ನಿಜವಾದ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಕೈಯಿಂದ ಬರೆದ ನಿಯತಾಂಕ ವಿಶ್ಲೇಷಣೆ ಶ್ರಮ ಉಳಿಸಲು ಕೆಟ್ಟ ಸ್ಥಳ.

ಪೂರ್ವ-ಗಣನೆ ದಾಳಿಕೋರನಿಗೆ ನಿಜವಾಗಿ ಏನನ್ನು ಕೊಡುತ್ತದೆ

ಸಂಖ್ಯಾ-ಕ್ಷೇತ್ರ ಜರಡಿಗೆ ಅವಿಭಾಜ್ಯ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಮಾತ್ರ ಅವಲಂಬಿತವಾದ ಹಂತವಿದೆ, ಮತ್ತು ಅದರ ಫಲಿತಾಂಶವು ಆ ಅವಿಭಾಜ್ಯವನ್ನು ಬಳಸುವ ಪ್ರತಿಯೊಂದು ವಿನಿಮಯದ ವಿರುದ್ಧ ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಐತಿಹಾಸಿಕ ಕಳವಳದ ಹಿಂದಿನ ಸಂಪೂರ್ಣ ಕಾರ್ಯವಿಧಾನ ಅದೇ: ದುಬಾರಿ ಭಾಗವನ್ನು ಒಮ್ಮೆ ಪಾವತಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಮುಂದಿನ ಸೆಷನ್‌ನ ಕನಿಷ್ಠ ವೆಚ್ಚ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಹೊಸ ಘಾತಗಳು ಪ್ರತಿ ಪ್ರತ್ಯೇಕ ವಿನಿಮಯವನ್ನು ನಿಷ್ಕ್ರಿಯ ವೀಕ್ಷಕರಿಂದ ಇನ್ನೂ ರಕ್ಷಿಸುತ್ತವೆ, ಗುಂಪು ಜರಡಿಯನ್ನು ಅಸಾಧ್ಯವಾಗಿಸುವಷ್ಟು ದೊಡ್ಡದಾಗಿರುವವರೆಗೆ. ಎರಡೂ ಹೇಳಿಕೆಗಳು ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಈ ವಿಷಯದ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಚರ್ಚೆಗಳು ಒಂದನ್ನು ಆರಿಸಿ ಇನ್ನೊಂದನ್ನು ಬಿಡುವುದರಿಂದ ಬರುತ್ತವೆ.

2015 ರ Logjam ಪ್ರಬಂಧವು 512-ಬಿಟ್ ರಫ್ತು-ದರ್ಜೆಯ Diffie-Hellman ಗೆ ಇಳಿಕೆಯನ್ನು ತೋರಿಸಿತು ಮತ್ತು ಗಣನೀಯ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ದೊಡ್ಡ, ವ್ಯಾಪಕವಾಗಿ ಮರುಬಳಕೆಯಾಗುವ ಗುಂಪುಗಳ ಮೇಲೆ ದಾಳಿಯ ವೆಚ್ಚ ಎಷ್ಟೆಂದು ಅಂದಾಜಿಸಿತು. ಪ್ರದರ್ಶನವು ನಿರ್ದಿಷ್ಟವಾಗಿತ್ತು, ಅಂದಾಜುಗಳು ಅಂದಾಜುಗಳಾಗಿದ್ದವು, ಮತ್ತು ಯಾವುದೂ ಒಂದು ನಿರ್ದಿಷ್ಟ VPN ಸೆಷನ್ ಡೀಕ್ರಿಪ್ಟ್ ಆಯಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಾಗಿರಲಿಲ್ಲ.

ಪ್ರಬಂಧವನ್ನು ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ಪ್ರದರ್ಶಿತ ಇಳಿಕೆಗಾಗಿ ಉಲ್ಲೇಖಿಸಿ, ನಿಮ್ಮ ನಿಯೋಜನೆಯ ಅಳತೆಯಾಗಿ ಅಲ್ಲ. ಎಷ್ಟು ಸರ್ವರ್‌ಗಳು ಡೀಫಾಲ್ಟ್ ಗುಂಪನ್ನು ಹಂಚಿಕೊಂಡವು ಎಂಬ ಹಳೆಯ ಅಂಕಿಅಂಶಗಳು ಆ ವರ್ಷದ ಇಂಟರ್ನೆಟ್ ಅನ್ನು ವಿವರಿಸುತ್ತವೆ, ಇಂದು ನೀವು ಪರಿಶೀಲಿಸಬಹುದಾದ ಜಾಲವನ್ನಲ್ಲ. ಮುಂದಕ್ಕೆ ಒಯ್ಯಬಹುದಾದ ಉಪಯುಕ್ತ ಅಂಶ ಪ್ರಶ್ನೆ: ನಿಮ್ಮ ಸಾಧನಗಳು ಇನ್ನೂ ಚಿಕ್ಕ ಅಥವಾ ದುರ್ಬಲವಾಗಿ ಮೌಲ್ಯೀಕರಿಸಿದ ಗುಂಪಿನ ಮೇಲೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತವೆಯೇ?

ಪ್ರಮಾಣೀಕೃತವಾಗಿರುವುದು ದುರ್ಬಲವಾಗಿರುವುದಲ್ಲ

RFC 7919 ಹೆಸರಿನ ಸೀಮಿತ-ಕ್ಷೇತ್ರ ಗುಂಪುಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಇದರಿಂದ ಎರಡೂ ತುದಿಗಳು ಗುರುತಿಸುವಿಕೆಯ ಮೂಲಕ ಗುಂಪಿನ ಮೇಲೆ ಒಪ್ಪಿ ಸ್ಥಿರವಾದ ನೀತಿಯನ್ನು ಅನ್ವಯಿಸುತ್ತವೆ. ಪ್ರಮಾಣೀಕೃತವಾಗಿರುವುದು ಒಂದು ಲಾಭ, ಏಕೆಂದರೆ ಅದು ಮಾತುಕತೆಯ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಅನುಷ್ಠಾನಕ್ಕೆ ಬೆಂಬಲಿಸದ ಗಾತ್ರಗಳನ್ನು ನಿರಾಕರಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಹೆಸರಿನ ಗುಂಪು ನೀವು ಅನುಸರಿಸುತ್ತೇನೆ ಎಂದು ಹೇಳುವ ನೀತಿಗಿಂತ ಅದರ ಗಾತ್ರ ಕೆಳಗಿದ್ದಾಗ ಮಾತ್ರ ದುರ್ಬಲ, ದಾಖಲೆಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವುದರಿಂದ ಅಲ್ಲ. ಅದೇ ತರ್ಕವು ದೀರ್ಘವೃತ್ತೀಯ ವಕ್ರ ಗುಂಪುಗಳಿಗೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಅವುಗಳ ರಚನೆ ಮತ್ತು ವೈಫಲ್ಯ ವಿಧಾನಗಳು ಬೇರೆ.

ಅವುಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುವಾಗ ನಿರ್ಮಾಣಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಸೀಮಿತ-ಕ್ಷೇತ್ರ Diffie-Hellman ಬಗ್ಗೆ ತೀರ್ಮಾನವು X25519 ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು 1024-ಬಿಟ್ MODP ಗುಂಪಿನ ಬಗ್ಗೆ ತೀರ್ಮಾನವು 3072-ಬಿಟ್ ಗುಂಪಿನ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಶಕ್ತಿ ನೀತಿಯು ಪ್ರತಿ ಕಾರ್ಯವಿಧಾನ, ಪ್ರತಿ ಗಾತ್ರ ಮತ್ತು ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿಗೆ, ಆದ್ದರಿಂದ ಬಲವಾದ ಗೂಢಲಿಪೀಕರಣ ಎಂಬ ಪದಗುಚ್ಛವು ಪರಿಶೀಲನೀಯ ಹೇಳಿಕೆಯಲ್ಲ.

ದೃಢೀಕರಣವು ಇನ್ನೊಂದು ಅರ್ಧ, ಮತ್ತು ಅದು ಬದಲಿಯಲ್ಲ. ಸಹಚರ ಪರಿಶೀಲನೆ ಇಲ್ಲದ ಬಲವಾದ ಗುಂಪು ದಾಳಿಕೋರನನ್ನು ಮಧ್ಯದಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಮತ್ತು ಮಾನ್ಯ ಪ್ರಮಾಣಪತ್ರವು 768-ಬಿಟ್ ವಿನಿಮಯವನ್ನು ಉಳಿಸಲಾರದು. ಅವುಗಳನ್ನು ಎರಡು ಸ್ವತಂತ್ರ ಸಾಲುಗಳಾಗಿ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಎರಡೂ ನಿಜವಾಗಿಯೂ ಮಾತುಕತೆಯಾಗುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ನಿಜವಾದ ಸಂಪರ್ಕದಲ್ಲಿ ಮಾತುಕತೆಯಾದ ಗುಂಪನ್ನು ಓದಿ

ಮಾತುಕತೆಯಾದ ಗುಂಪನ್ನು ಸಂರಚನಾ ಟೆಂಪ್ಲೇಟ್‌ನಿಂದ ಅಲ್ಲ, ಸಾಧನದಿಂದ ಓದಿ. ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಉದ್ದೇಶವನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಆಸಕ್ತಿದಾಯಕ ಮೌಲ್ಯವು ಕೊನೆಯ ಕೈಕುಲುಕಿನ ಸಮಯದಲ್ಲಿ ಎರಡೂ ಪಕ್ಷಗಳು ಒಪ್ಪಿದ ಮೌಲ್ಯ. IPsec ತುದಿಯಲ್ಲಿ ಸ್ಥಿತಿ ಔಟ್‌ಪುಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಆಯ್ಕೆಯಾದ ಪ್ರಸ್ತಾಪವನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, MODP ಗುಂಪು ಸೇರಿದಂತೆ.

ನೀತಿ ಬದಲಾವಣೆಯ ಮೊದಲು ಮತ್ತು ನಂತರ ಆ ಸಾಲನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ, ಮತ್ತು ಎರಡನ್ನೂ ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ. ಹೋಲಿಕೆಯೇ ಸಾಕ್ಷ್ಯ.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

ಬದಲಾವಣೆಯ ನಂತರವೂ ಸ್ಥಿತಿ ಹಳೆಯ ಗುಂಪನ್ನು ತೋರಿಸಿದರೆ, ಸಂಪರ್ಕವು ಮತ್ತೆ ಮಾತುಕತೆ ನಡೆಸಿಲ್ಲ ಮತ್ತು ಸಂರಚನಾ ಸಂಪಾದನೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸಿಲ್ಲ. ಸಹಚರವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಅಥವಾ ಭದ್ರತಾ ಸಂಘವನ್ನು ಅಳಿಸಿ, ನಂತರ ಸ್ಥಿತಿಯನ್ನು ಮತ್ತೆ ಓದಿ. ಹೊಸ ಸಂಪರ್ಕಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯವಾಗುವ ನೀತಿ, ದೀರ್ಘಕಾಲಿಕ ಸುರಂಗಗಳನ್ನು ಅವು ನಿಂತಿರುವವರೆಗೆ ಹಳೆಯ ನಿಯತಾಂಕಗಳಲ್ಲೇ ಬಿಡುತ್ತದೆ.

ಗುಂಪು ಮತ್ತು ಸಹಚರ ಗುರುತನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ

ಗುಂಪು ಏನನ್ನು ರಕ್ಷಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿ ಯಾರಿದ್ದಾರೆ ಎಂಬುದರಿಂದ ಬೇರ್ಪಡಿಸಿ. ಕೀ-ವಿನಿಮಯ ವಿಧಾನ, ಗುಂಪಿನ ಗಾತ್ರ ಮತ್ತು ದೃಢೀಕರಣ ವಿಧಾನವನ್ನು ಮೂರು ಕ್ಷೇತ್ರಗಳಾಗಿ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಅವು ಸ್ವತಂತ್ರವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ. 3072-ಬಿಟ್ ಗುಂಪಿನ ಮೇಲೆ ಮಾತುಕತೆ ನಡೆಸಿ ಆದರೆ ಯಾವುದೇ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ವೀಕರಿಸುವ ಸುರಂಗವು, ಸಹಚರವನ್ನು ಪಿನ್ ಮಾಡಿ 2048-ಬಿಟ್ ಗುಂಪು ಬಳಸುವ ಸುರಂಗದಷ್ಟೇ ಅಪಾಯವಲ್ಲ.

ಪರಿಶೀಲನೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳನ್ನು ಬರೆಯಿರಿ, ಇದರಿಂದ ಫಲಿತಾಂಶವು ಅಭಿಪ್ರಾಯವಲ್ಲ, ಹೋಲಿಕೆಯಾಗುತ್ತದೆ. ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿಗೆ ಕನಿಷ್ಠ ಗುಂಪು ಗಾತ್ರ, ಹೆಸರಿನ ಗುಂಪುಗಳ ಅನುಮತಿ ಪಟ್ಟಿ ಮತ್ತು ಕಡ್ಡಾಯ ಸಹಚರ ಪರಿಶೀಲನೆ ನಿರ್ಣಯವನ್ನು ಯಾಂತ್ರಿಕಗೊಳಿಸಲು ಸಾಕು. ಆ ಪಟ್ಟಿಯಲ್ಲಿನ ಅಸ್ಪಷ್ಟತೆಯೇ ಪರಿಶೀಲನೆಯನ್ನು ವಾದವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ವಾದಗಳಿಗೆ ಪರಿಹಾರವಿಲ್ಲ. ಆಗ ಔಟ್‌ಪುಟ್ ಘೋಷಿತ ನಿಯಮವನ್ನು ಮೀರುವ ತುದಿಗಳ ಪಟ್ಟಿಯಾಗಿರುತ್ತದೆ.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

ಪರಿಹಾರದ ನಂತರ ಮಾತುಕತೆಯಾದ ಮೌಲ್ಯಗಳನ್ನು ಮತ್ತೆ ಓದುವ ಮೂಲಕ ಚಕ್ರವನ್ನು ಮುಚ್ಚಿ. ಅನುಸರಣೆಯ ಸಂರಚನಾ ಫೈಲ್ ಒಂದು ಸುರಂಗವು ಅದನ್ನು ಸ್ವೀಕರಿಸಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಸ್ಥಿತಿ ಔಟ್‌ಪುಟ್ ಮತ್ತು ಒಂದು ಹೊಸ ಕೈಕುಲುಕು ಸಾಕ್ಷ್ಯ, ಮತ್ತು ಅವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಅವು ಬೇಕೇ ಎಂಬ ಸಭೆಗಿಂತ ಕಡಿಮೆ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.