All streams
Search
Write a publication
Pull to refresh
0
0
Anton Kovalenko @akovalenko

User

Send message

Про base128: у вас, как я понял, семибитный gsm alphabet сейчас используется, можно взять бинарный payload и распилить его по семибитным границам. Получится те же 140 байт, которые получились бы с TP-DCS 8-bit. Это лишние телодвижения, которые могут быть оправданы, когда например модем с какой-то стороны не умеет SMS PDU MODE.

Как я понял, при передаче по DTMF вы уже полученное семибитное пакуете в base12. Но ведь точно так же вы могли бы и 8bit бинарное паковать!

Так что правильный ответ на «почему не protobuf» всё же скорее «мне весело было придумать CJON» (и ничего в этом плохого не вижу), чем «protobuf не влезает в 8bit, а protobuf+base64 неэкономно)

А в контексте вашей задачи точно нельзя передавать бинарные данные в SMS? Ставите в TP-DCS 8-bit data и вперёд, 140 полновесных байт.

Ну и если вдруг нельзя, то логичнее base128 организовать на базе 7-bit GSM alphabet, всё ж поэкономнее.

А в бинарном пейлоуде тогда можно будет и protobuf, и cbor, и компрессию...

Да, свою ошибку с cmdline уже осознал.

По поводу риска временных засветов остаюсь при своём мнении.

Совет про переменную окружения удивил. Секрет пропадает из /proc/PID/cmdline, но появляется в /proc/PID/environ, и чего мы этим добились?

По трюку с перезапуском и изменением cmdline -- мы на мгновение всё-таки засветим секрет в списке процессов, а это обычно нежелательно, атакующему может повести. Ну и когда на файл с паролем вы делаете chmod 600, это обычно означает, что файл уже полежал с неправильными правами, и пароль лучше сменить. Вместо chmod я бы советовал umask на процессе, или каталог с правами 0700 (chmod на пустой файл до добавления туда пароля — нерабочий вариант, атакующий мог бы открыть этот файл заранее и прочитать после chmod'а)

Information

Rating
Does not participate
Registered
Activity