Thời gian

Hôm thứ sáu tôi nhấn nút phát hành phiên bản đầu tiên của Tink, thư viện mã hóa miễn phí, mã nguồn mở do nhóm của tôi ở Google phát triển.

Từ đầu năm đến nay ngoại trừ cuối tuần và hai tuần về Việt Nam ngày nào tôi cũng làm việc trung bình 12 tiếng. Có những ngày ở Châu Âu buổi sáng đi làm trời còn chưa tỏ, ra về trời đã tối mịt. Có những đêm đi ngủ mà lòng cứ nao nao, chỉ mong trời sáng để tiếp tục công việc. Mệt nhưng hào hứng vì tôi tin rằng, dẫu còn nhiều chỗ cần phải hoàn thiện, Tink đã và sẽ có tác động tích cực và lâu dài đến việc triển khai các giải pháp mật mã ở Google và trên thế giới.

Làm việc với cường độ và áp lực cao trong một thời gian dài đem đến cho tôi vài suy nghĩ mới.

Thứ nhất, rất khó để cho một ai đó biết quý và sử dụng thời gian hợp lý cho đến khi họ phải làm việc cực lực, chạy đua với thời gian. Một khi đã thấy trong một tiếng đồng hồ ta có thể làm được bao nhiêu việc, tôi đã phải cân nhắc từng hoạt động hàng ngày và không còn đủ can đảm theo đuổi những hoạt động, những thói quen vô thưởng vô phạt.

Cái gì là vô thưởng vô phạt thì tùy người, nhưng thời đại bây giờ đa số đều có vấn đề chung là kiểm tra điện thoại quá nhiều lần. Trung bình một người bình thường kiểm tra điện thoại 150 lần mỗi ngày. Tôi giật mình nhận ra có những lúc tôi lấy điện thoại ra xem có email mới hay không như một phản xạ không điều kiện. Đó là lý do tôi xóa hết tất cả app khiến tôi luôn thấy nôn nao, muốn kiểm tra xem có gì mới hay không. Tôi cũng đặt điện thoại ở chế độ im lặng, tắt hết thông báo. Tôi muốn giữ độc quyền quyết định khi nào thì tôi muốn bị làm phiền.

Trong chuyến đi Sơn Đoòng, chúng tôi cắt đứt liên lạc với thế giới bên ngoài. Không sóng điện thoại, không Internet. Điện thoại vệ tinh cũng không có, vì ở trong hang. Mỗi buổi tối cả đám ngồi ăn, uống trà, cafe, nói chuyện râm ran với nhau, cứ như bọn tâm thần! Khoảnh khắc chúng tôi ra khỏi hang và có sóng điện thoại, có người nhận được cả ngàn tin nhắn. Tôi thấy humble và cảm động, khi nhận được một email và một tin nhắn của hai người bạn thân từ nhỏ. Hóa ra hòa bình thế giới và văn minh nhân loại chẳng bị ảnh hưởng gì cả nếu tôi không kiểm tra email trong 7 ngày, vậy thì chẳng có lý do gì để tôi kiểm tra email mỗi 7 phút.

Nhiều người ngạc nhiên khi biết tôi không có tài khoản Facebook. Ngoài bảo vệ sự riêng tư, tôi còn muốn bảo vệ năng suất làm việc. Tôi chỉ làm việc tốt nếu tập trung và tôi không thể tập trung nếu cứ luôn lo không biết mình có đang bỏ lỡ cái gì hay hông. Tôi hiểu được những lợi ích mà Facebook đem đến. Nó là phương tiện không tồi để giải trí, cập nhật tin tức và kết nối với thế giới. Nhưng nó là một công cụ, mình nên làm chủ nó, không nên để nó làm chủ mình. Facebook trở thành ông chủ khi mà mỗi ngày mỗi giờ nó khiến mình ray rứt bực dọc nếu không cập nhật trạng thái mới hay mở lên kiểm tra xem có gì mới hay không.

Tôi thấy không khỏi cám cảnh khi trung bình người Việt Nam dành ra mỗi ngày 2,5 tiếng đồng hồ xài Facebook. Đây là con số thống kê năm 2015, bây giờ 2017 tôi tin rằng còn phải nhiều hơn nữa. Việt Nam cũng là một trong những nước xem YouTube nhiều nhất thế giới. Có lần tôi ăn tối với một nhóm tinh hoa ở Việt Nam và thấy kinh ngạc khi nhiều người chụp hình, cập nhật Facebook, vài ba phút lại mở điện thoại ra xem có ai còm hay được bao nhiêu like.

Thứ hai, một khi đã quý trọng thời gian của bản thân người ta sẽ biết tôn trọng thời gian của người khác. Thói quen trễ hẹn, không chịu xếp hàng hay chen hàng ở nơi công cộng là do xem thường thời gian của bản thân, từ đó xem nhẹ thời gian của người khác. Một người có thể phí phạm vài tiếng đồng hồ mỗi ngày sẽ không thể hiểu được tại sao cần phải tôn trọng vài phút đồng hồ của người khác.

Ở công ty của tôi, các cuộc họp đương nhiên là bắt đầu đúng giờ, nhưng quan trọng hơn nữa là luôn kết thúc đúng giờ, bất kể vấn đề đang họp có được giải quyết hay chưa (nếu chưa xong thì hẹn một cuộc họp khác). Đơn giản vì mỗi người đều có kế hoạch sử dụng thời gian khác nhau, thành ra không ai dám xâm phạm kế hoạch của người khác, nếu không có sự đồng ý của họ.

Cuối cùng, dẫu giàu hay nghèo, bệnh tật hay khỏe mạnh, người Việt hay người Mỹ, ai cũng có 24 giờ mỗi ngày. Sử dụng thời gian thế nào ảnh hưởng rất lớn đến cuộc sống của mỗi người. Mỗi lần chúng ta mở điện thoại ra để xem thông báo mới là một lần chúng ta đầu hàng, cho phép bất kỳ ai từ bất kỳ nơi đâu chiếm dụng thời gian của ta. Hầu như ai cũng thấy khó chịu khi bị chen hàng, nhưng bạn có nhận ra mỗi lần điện thoại réo lên có thông báo mới cũng là một lần nơi gửi thông báo đó đang chen hàng để hút sự chú ý của bạn?

Comments

Unknown said…
Nhắc tới Facebook - Em là một người từng có và sau đó thì bỏ Facebook. Sau khi bỏ từ một năm nay thì thấy tinh thần thoải mái hơn rất nhiều. Khi không có nữa thì việc thấy không có thực ra mình cũng chẳng mất mát bỏ lỡ gì nhiều, như thể ngày trước khi người người có blog trên Yahoo thì thấy có cũng vui, không có cũng chẳng sao. Ngẫm lại thì thấy có những người viết có nội dung mà vẫn làm được việc như anh, nhưng một phần nhiều thật ra cũng không có cái gì để mà chia sẻ.

Facebook, hay blog Yahoo ngày xưa, đó là một cách để giết thời gian.

Anh Thái có đề cập tới chuyện con số 2.5 tiếng mỗi ngày. Thiển ý của em - đó là triệu chứng chứ không phải căn bệnh. Nếu họ không lướt Facebook thì họ cũng phí thời gian vào việc khác, ví dụ, đánh cờ tướng trên vỉa hè, hoặc đọc báo, hoặc uống rượu, hoặc đọc Hacker News. Có thể đánh cờ tướng hay đọc báo giấy thì tốt hơn đọc status của Facebook nhưng em nghĩ đó cần phải bàn luận dài dài...

Có lẽ có một điều không cần bàn cãi là Facebook cũng gây nghiện và có hàng trăm hàng ngàn kỹ sư giỏi đang làm việc ngày đêm để làm người ta nghiện nhiều hơn. Hôm nay trên HN có bài này. http://bradfrost.com/blog/post/facebook-you-needy-sonofabitch/
Unknown said…
lâu không thấy ông này có bài mới cứ tưởng ổng đi Sơn Đoòng gặp chuyện gì rồi.
JV kenny said…
có ai trả lời e 1 câu hỏi này không :(( dù nói e trẻ trâu cũng được . e rất thích nhưng người làm như " chuyên gia bảo mật, an ninh mạng " thì phải học ngành gì ở Việt nam ạ . mọi người hay chê ngành An toàn thông tin ở các trường đại học ở VN nhưng đây là ước nguyện e sẽ theo đuổi . ai cho e câu trả lời với .... sắp tới e đang cố để đi du học ở phần lan .. mọi người có lời khuyên cho e để theo đuổi ước nguyện không ạ . e cảm ơn
Trung Dinh said…
hi anh Thái,
em vừa vọc thử thư viện Tink, em thấy xài dễ dàng, đúng như tiêu chí design ban đầu, appriciate the great work!!! hy vọng tink sẽ tiếp tục phát triển tốt.

em cũng có thử benchmark performance của tink (encrypt 1 file 500MB) trên Macbook pro i7, tốc độ AES-GCM-128 của tink là khoảng 42MB/s, (của openssl AES-CTR-128 là khoảng 80MB/s, không compiled with AES-NI, em biết CTR không phải là Authenticated Encryption nhưng về lý thuyết CTR and GCM should have similar speed), không biết lúc build tink mình có lưu ý option nào về tốc độ hay hỗ trợ AES-NI không? Thanks anh.

dd if=/dev/zero of=foo.txt bs=1m count=500

time ./bazel-bin/helloworld/java/helloworld encrypt --keyset test.cfg --in foo.txt --out bar.encrypted

real 0m11.759s
user 0m10.839s
sys 0m1.115s

time openssl enc -aes-128-ctr -in foo.txt -out with_openssl.encrypted
enter aes-128-ctr encryption password:
Verifying - enter aes-128-ctr encryption password:

real 0m6.180s
user 0m0.177s
sys 0m0.706s
Thai Duong said…
Chào Trung,

Rất cảm ơn phản hồi của bạn.

Đúng như bạn nói AES-GCM có thể chậm hơn AES-CTR một chút, nhưng không thể đến nỗi chậm hơn như bạn đã quan sát. Tôi nghĩ ở đây có hai lý do:

1/ Tink sử dụng AES-GCM nằm trong JCE, có lẽ phiên bản JCE mà bạn đang sử dụng không được tối ưu hóa tốt bằng phiên bản trong OpenSSL.

Hay là bạn thử chạy Tink với https://conscrypt.org? Đây là một JCE provider dựa hoàn toàn trên OpenSSL. Nếu được bạn báo lại cho tôi kết quả nhé.

2/ Chương trình helloworld đọc toàn bộ nội dung của foo.txt lên bộ nhớ, sau đó lại tạo ra trên bộ nhớ ciphertext, xong rồi mới ghi toàn bộ xuống bar.encrypted.

Tôi đồ rằng thời gian đọc và ghi file có thể còn nhiều hơn thời gian mã hóa, thành ra số liệu có thể không còn chính xác. openssl cũng phải đọc và ghi file, nhưng có thể họ sử dụng API tốt hơn là Java cung cấp.

Để tính benchmark chính xác hơn, có lẽ cần phải loại bỏ đọc và ghi file, chỉ so thời gian mã hóa. Nhóm có kế hoạch thêm vào một số benchmarking suite, nhưng mà cho đến nay vẫn chưa có thời gian để làm. Nếu bạn có hứng thú muốn đóng góp, chúng ta có thể trao đổi thêm.

> không biết lúc build tink mình có lưu ý option nào về tốc độ hay hỗ trợ AES-NI không? Thanks anh.

Hiện giờ thì không. Tôi có kế hoạch cung cấp một JNI-based implementation dựa trên OpenSSL, khi đó miễn OpenSSL sử dụng AES-NI thì Tink cũng sẽ sử dụng AES-NI, nhưng mà tôi cũng phân vân liệu mình có nên dành thời gian cho việc này, hay là nên dành thời gian làm cho Conscrypt hoặc OpenJDK chạy nhanh hơn.
Thai Duong said…
> Hay là bạn thử chạy Tink với https://conscrypt.org? Đây là một JCE provider dựa hoàn toàn trên OpenSSL. Nếu được bạn báo lại cho tôi kết quả nhé.

Àh tôi mới nhớ ra hiện giờ để chạy Tink với conscrypt cũng không đơn giản lắm. Bạn cần phải tải Conscrypt về, sau đó cần phải install cái OpenSSLProvider ở vị trí đầu tiên trước khi chạy benchmark, giống như ở đây: https://github.com/google/wycheproof/blob/master/java/com/google/security/wycheproof/ConscryptTest.java#L49.

Thai Duong said…
Tôi thử chạy với Conscrypt thì thấy tốc độ vẫn giống như bạn đã thông báo. Có lẽ vấn đề chính ở đây vẫn là chuyện sử dụng nhiều bộ nhớ.

Ngoài ra OpenSSL có thể, tôi không chắc, mã hóa song song nhiều block cùng một lúc. Hiện giờ Tink chỉ sử dụng một thread duy nhất để mã hóa mà thôi.
Trung Dinh said…
Hi anh,
em cũng nghĩ vấn đề ở multi-threading, em có thử benchmark với file nhỏ (khoảng 50MB), tốc độ cũng tương tự. Như anh đề cập, nếu chỉ benchmark trên CPU & memory (không ghi xuống file do bottleneck của disks hoặc APIs), encryption speed của openSSL khá cao (4.1GB/s for 8KBs blocks ):

openssl speed -elapsed -evp aes-128-gcm

compiler: clang -I. -I.. -I../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-gcm 403540.92k 1090679.25k 2394208.62k 3332458.84k 4122705.92k

Nhưng benchmark này dựa trên AES-NI của CPU đồng thời cũng chạy multi-threading.
Ngoài ra, em search thấy thư viện crypto++ benchmark cho kết quả nhanh tương tự, khoảng 2.4GB/s https://www.cryptopp.com/benchmarks.html

Em thử wrap encryption operation của Tink (hàm aead.encrypt()) để check encryption time in memory only:

long startTime = System.currentTimeMillis();
byte[] ciphertext = aead.encrypt(plaintext, new byte[0] /* additionalData */);
long stopTime = System.currentTimeMillis();
System.out.println(String.format("Encryption time is %s msecs",(stopTime -startTime)));

Tốc độ cũng không thay đổi nhiều (khoảng 50MB/sec)
./bazel-bin/helloworld/java/helloworld encrypt --keyset test.cfg --in foo.txt --out bar.encrypted
Encryption time is 10189 msecs

Vậy em nghĩ hướng NI-based implementation dựa trên OpenSSL của anh có vẻ hay hơn, đỡ tốn thời gian lo về multi-threading luôn.

Thanks anh,
Trung