eu_tomat

12 минуты назад, HeroBrine1st сказал:

0F = F, нули из начала отсекаются (если я правильно понял).

Ведущий ноль не отсекается. Во-первых, это можно видеть по выводу, выложенному в этом посте, а во-вторых, я сейчас запустил такой же бесконечный цикл, фильтрующий числа короче полного, на выходе ничего не получил.

17 минут назад, HeroBrine1st сказал:

Как-то не понял самой концепции, ведь если битовая длина числа больше битовой длины модуля, то число%модуль будет меньше числа. Тут хоть все нули заменяй единицами, не поможет.

Я про это и говорю: длина шифруемого числа, даже если в нём все биты нулевые, должна быть меньше фактической битовой длины модуля. То есть, длину модуля считаем по самому старшему единичному биту или байту. А длину допустимого к шифрованию числа считаем просто по количеству бит или байт, независимо от содержимого.

24 минуты назад, HeroBrine1st сказал:

В библиотеке так же старший разряд имеет ненулевое значение (а если имеет - попросту игнорируется)

Не уверен, как это понимать. Если под игнорируется имеется в виду "ищется новое значение", то да, это верный вариант. Но в этом случае максимальное количество шифруемых бит всегда должно быть хотя бы на один меньше. То есть, 32-битным ключом не всегда получится успешно зашифровать и расшифровать 32-битные данные.

27 минут назад, HeroBrine1st сказал:

Однако для этого потребуется уведомлять другую сторону о том. что использована кастомная длина блока.

Если алгоритм на обеих сторонах будет одинаковым, то уведомление не потребуется.

27 минут назад, HeroBrine1st сказал:

но не проще ведь просто не использовать ключи менее 32 бит?

Тут, во-первых, и ключ 32 бита не всегда помогает. А во-вторых, при длине ключа 256 бит шифровать блоки по 4 байта попросту неэффективно. Поэтому нужен адаптивный размер блока. А дальше либо подгонять размер блока под фактическую длину N, либо N формировать так, чтобы он был не меньше заданной длины.

Я обратил внимание, как генерирует ключи openssl. Во всех виденных мною ключах всегда есть отличное от нуля число если не в старшем разряде, то в следующем за ним. Разряды там в 16-ричной системе, и двумя разрядами кодируется байт. Получается, что старший байт всегда имеет значение больше нуля. Видимо, так сделано специально. Это позволит, например, при 32-битном ключе гарантированно шифровать блок из 3 байт. Или 15 байт при 128-битном. Возможно, я не видел нулевого старшего байта лишь в силу незначительного шанса на это. Но я запускал на десяток минут бесконечный цикл генерации ключа с фильтрацией по нулю в старшем байте. Всегда старший байт что в модуле, что в закрытой экспоненте имел ненулевое значение.

4 минуты назад, HeroBrine1st сказал:

1. В начало строки добавляется 4 случайных символа - соль
2. Строка делится на блоки по 4 символа, недостающие символы заполняются нулями

Ага, я, кажется, понял, в чём подвох. Деление на блоки происходит фиксированно, без учёта фактической длины N. А я без затей для тестирования шифрования строки выбрал фразу "TEST", как раз 4 символа. Поэтому она не дробилась. А солью с длиной 4 символа по умолчанию как раз получалось два блока.

11 минуту назад, HeroBrine1st сказал:

Разделить число на два.. вполне возможно

Не-не... я предлагаю не блок дробить на два, но адаптивно подбирать размер блока, чтобы его длина всегда была меньше размера N. Самое простое: если фактическая длина N требует для его кодирования 4 байта, то в шифруемый блок можно поместить не более 3 символов. При желании можно и точное количество бит посчитать, но в этом я уже не вижу большого смысла.

33 минуты назад, HeroBrine1st сказал:

Пока библиотека может вычислять ключи до 128 (~30 секунд на сервере) и 256 бит (~3 минуты на моем компьютере в эмуляторе Lua) - этого хватает с головой. Больший размер мне сгенерировать не удалось(

У меня результат заметно хуже, даже на CPU Core i7-4770K. 128-битный ключ генерируется в диапазоне 423-130 секунд. А 256-битный -- 377-895 секунд. Нижняя граница: запущен лишь Майнкрафт. Верхняя: во время активной работы в редакторе и браузере. Генерация 512-битного ключа обрывается по TLWY. Я подсунул ключи от openssl, сообщение было даже успешно зашифровано, но дешифрация также оборвалась по TLWY. Генерацию ключей я не смотрел, но шифрование точно имеет хороший потенциал для оптимизации.

57 минут назад, HeroBrine1st сказал:

Такой изьян системы, тем не менее, в современных реалиях используются ключи в 3072 бит (такой размер дает криптостойкость до 2030 года), а размер блоков гораздо меньше данного.

Мне вот, что непонятно. При шифровании с солью в выходной таблице появляется не одно число, а два. Это разделение на два независимых блока? И если так, то что мешает разделять любое сообщение даже без соли, если его размер превышает N? А если моя догадка неверна, то какую роль играет второе число при шифровании с солью?

27 минут назад, ArtHacker сказал:

Хорошо что переехал от туда)))

Ого! На что только ни идут люди ради комфортной игры в Майнкрафт!

@HeroBrine1st Похоже, в библиотеке есть ошибка. Если исходное число превышает N, то после шифрования и дешифрования сообщение превращается в кашу. Или это так и задумано, и ответственность по выбору длины сообщения лежит на пользователе?

1 час назад, Hikooshi сказал:

имеется в виду, что на одной из кнопок есть функция с вайлом и вот пока этот вайл выполняется, на кнопке который, нужно другие кнопки нажимать

Да, в этом случае нажатия обрабатываются через listener, а внутрь цикла добавляется os.sleep, потому что события обрабатываются внутри него.

27 минут назад, Doob сказал:

Юзаю редактор рептилоидов, кодить могу прямо в майне через IRC бридж. Накидал сниппетов для опенкомпов, настройки покрутил и готов ультра-опен-редахтур-компутерс-луа.

Хотя, мне такие монструзные редакторы не нравятся, но привлекает удобство, которое можно получить, навесив апгрейдов, раскидав щупальца дополнительных плагинов и скриптов поддержки.

К слову, Atom тоже написан на  Node.js/Electron. Всё говорит о том, что автор на верном пути.

@Doob Таковы этапы эволюции:

• Кирилл хочет, чтобы кто-то написал игру для него;
• Артур хочет сам написать OpenComputers Studio для других;
• Игорь уже написал MineCode IDE.

14 часа назад, monkey сказал:

Как считается длина ключа RSA? Он состоит из экспоненты и модуля. Сколько бит под что занято?

В Linux это проверяется так:

создать ключ длиной 1024 бита:

$ ssh-keygen -t rsa -b 1024 -N '' -f tmp-rsa-1024b

вывести содержимое ключа в читаемом виде (длинные строки я обрезал для удобства):

$ openssl asn1parse -in tmp-rsa-1024b
    0:d=0  hl=4 l= 605 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=3 l= 129 prim: INTEGER           :B266CDD0ACA7CDB61DA3852B8E831690DFC36C8425E32C449B79D85AF6...
  139:d=1  hl=2 l=   3 prim: INTEGER           :010001
  144:d=1  hl=3 l= 128 prim: INTEGER           :6901C7DD2EF32A4B2A90E83EA60894CCBB58BCD3DFB5228653795996D9...
  275:d=1  hl=2 l=  65 prim: INTEGER           :E518DC47E852FE31DDDA8DB6A3B4D1D5BE1E7A65D55AFDC1E8D7BDDF98...
  342:d=1  hl=2 l=  65 prim: INTEGER           :C759EDF190F560FA22A4F590888F2FB6077091C18C9EAB6CE3B04D3916...
  409:d=1  hl=2 l=  64 prim: INTEGER           :68D3463FB4C2FCC28E73A9322F97D6078A156205E468DD0173EBFB5A2A...
  475:d=1  hl=2 l=  65 prim: INTEGER           :942F591C943092A1DD56D9E3525F7D8BC603FB94F03E921723394E6DFD...
  542:d=1  hl=2 l=  65 prim: INTEGER           :D8ED49BDBF7135BEC25E68E3762AEEAE997406C8CD91715B44C9A43274...

Сопоставить вывод предыдущей команды с этим документом:

https://tls.mbed.org/kb/cryptography/asn1-key-structures-in-der-and-pem

RSAPrivateKey ::= SEQUENCE {
  version           Version,
  modulus           INTEGER,  -- n
  publicExponent    INTEGER,  -- e
  privateExponent   INTEGER,  -- d
  prime1            INTEGER,  -- p
  prime2            INTEGER,  -- q
  exponent1         INTEGER,  -- d mod (p-1)
  exponent2         INTEGER,  -- d mod (q-1)
  coefficient       INTEGER,  -- (inverse of q) mod p
  otherPrimeInfos   OtherPrimeInfos OPTIONAL
}

Как видно, готовый 1024-битный ключ содержит:

•   модуль длиной длиной 128 байт (1024 бита);
•   открытую экспоненту со стандартным значением, специально выбранным для упрощения вычислений на всякого рода умных кофеварках;
•   закрытую экспоненту длиной 128 байт (1024 бита);

Где-то вместо 128 указано 129 байт и 65 вместо 64. Это связано с тем, что стандарт подразумевает использование целых чисел со знаком, в которых старший бит числа интерпретируется как знак. Чтобы избежать этого, числа с единичным старшим битом расширяются на один байт.

6 часов назад, Doob сказал:

Лучше всего познавать мир на практике - материал на порядки быстрее усваивается.

Вопрос-то заключался не в том, почему умножение или деление на двойку эквивалентно сдвигам в двоичной системе. У школьников есть богатая практика сдвигов по разрядам степеней десяти, что точно таким же образом соответствует умножению и делению, как и двоичной системе.

Вопрос в другом: как ты объяснишь ученику средней школы переход от деления на целевое число, не сводящееся к степеням двойки, к другому числу, позволяющему превратить деления в сдвиги?

2 часа назад, Doob сказал:

Как бы это примитив на уровне средней школы.

Кстати, а ты можешь доступно объяснить, за счёт чего становится возможным получить остаток от деления без, собственно, деления на целевое число, чисто отсечением старших или младших разрядов? Так, чтобы было понятно ученикам средней школы. Про алгоритм Евклида, конечно, все знают, но уже его расширенный вариант для многих неочевиден.

22 минуты назад, Doob сказал:

Т. к. в Lua 5.3 битовые операции хоть и ускорились почти в два раза, но не факт, что они будут быстрее деления. Во многих языках понижение уровня вычислений не ускоряет эти самые вычисления, т. к. на низком уровне разработчики уже накрутили ускоряющей магии.

Это да. По крайней мере, в Lua от OpenComputers нет заметной разницы во времени выполнения операций сложения, умножения, деления или сдвига для числовых типов. И задействование именно битовых операций вряд ли будет существенным.

Но в длинной арифметике количество отдельных операций, необходимых для сложения, умножения, а тем более деления, существенно различается. Например, затраты на сдвиг длинного числа эквивалентны его умножению на короткое число и они меньше затрат на сложение двух длинных чисел.

Умножение Монтгомери заменяет операцию взятия остатка от деления последовательностью более быстрых операций:

• одно сравнение
• одно или два сложения
• два умножения
• одно отсечение младших разрядов
• одно отсечение старших разрядов

В этом весь смысл добавления новых сущностей в старую задачу.

В 23.08.2019 в 21:08, monkey сказал:

Алгоритм Монтгомери вроде бы должен помочь ускорить возведение в степень по модулю. Но мне не удалось понять эту магию. Кто-нибудь здесь может на пальцах объяснить, как это применить?

На пальцах не объясню, но дам намёки.

На Википедии есть статья про умножение Монтгомери. Но она носит справочный характер, а не обучающий. При её чтении надо обратить внимание на следующие моменты:

В статье введено понятие n-остатка. И умножение Монтгомери работает не с исходными числами, и с их n-остатками. То есть, сначала числа преобразуются в их n-остатки, которые затем перемножаются по алгоритму Монтгомери. На выходе процедуры умножения также получается n-остаток. И для последующей работы его требуется преобразовать в исходную форму.

Преобразования чисел требуют дополнительных вычислений, и на отдельно взятом умножении они лишь ухудшат производительность. Но приятная особенность в том, что самые тяжёлые вычисления выполняются на этапе преобразования чисел в n-остатки. Само умножение и обратное преобразование выполняются заметно быстрее за счёт замены операций деления сдвигами (битовыми в случае двоичной системы). Поэтому существенная экономия достигается при возведении числа в степень, где достаточно один раз выполнить преобразование в n-остатки, выполнить серию умножений n-остатков, а к результату применить обратное преобразование.

Обратное преобразование уже присутствует в самой процедуре умножения Монтгомери, и её можно применить для этой цели без изменений, передав в качестве аргументов n-остаток числа и единицу. Результатом умножения будет искомое число.

Самая большая магия (которую я сейчас пояснить не могу) происходит в этой стоке: u = (t+(t*n' % r)*n)/r. После её выполнения, возможно, потребуется выполнить u=u-n. Выглядит сложновато, и в выражении даже присутствуют два деления, но за счёт правильного выбора r операция деления легко заменяется сдвигом разрядов числа.

Набросок алгоритма возведения в степень, приведённый в статье, вроде бы достаточно хорошо иллюстрирует его применение. Для оптимизации шифрования RSA очень пригодится.

6 часов назад, maxutka99 сказал:

Как выяснилось позднее значение 15 это ещё не предел.Данная программа спокойно может отображать до 99 мобов(можно и больше, но значение не влезает в экран)

Неожиданно выяснилось, что плата редстоуна из OC может выдавать и воспринимать сигналы в диапазоне [0..2^31-1]. Я, конечно, не знаю возможностей счётчика мобов из MineFactory Reloaded, но OC точно не будет узким местом. Тут скорее Майнкрафт повиснет от такого обилия скота.

А что будет при  количестве мобов больше 15? Каков максимальный уровень сигнала?

6 минут назад, BrightYC сказал:

Думаю, для того кто мониторит.

Разные игроки мониторят. Это лучше для всех игроков?

7 минут назад, BrightYC сказал:

Я же никого насильно с дулом пистолет не заставляю использовать мониторы, а не таблички=d

Предположим, не заставляешь. Тогда почему составляешь фразу в форме приказа, выраженного в категоричной форме?

1 час назад, BrightYC сказал:

иди в шахту, мониторить тебе явно нечего=d

8 минут назад, BrightYC сказал:

Но раз уж на то пошло - намного лучше посидеть в шахте пол часика и сделать клёвую мониторилку, которую видно хоть из окна соседа

А лучше для кого?

1 минуту назад, BrightYC сказал:

Холивары то поддерживать надо. Кто-то же должен это делать, верно?

Интересный холивар можно и поддержать. Но большинство холиваров уходит в мусорку.

Вот, например, какой смысл в аргументации вида "выброси таблички, иди в шахту"? Разве этот аргумент как-то изменит ценность опубликованной программы?

7 минут назад, BrightYC сказал:

Хоть это и , но мониторить МФСУ(! делается из алмазов - следовательно на 2-3 тир монитор/пк ресурсы есть) на табличках - мазахизм в чистом виде. А если ресурсов нету - иди в шахту, мониторить тебе явно нечего=d

А если аргументов нету, просто скажи — да иди ты в шахту!

В песочницу каждый имеет право играть так, как ему нравится. И что является большим мазохизмом: мониторинг на табличках или же поход в шахту, учёные пока ещё не выяснили. Но радость может приносить и то и другое.

46 минут назад, OldHevy сказал:

Как мне открыть командную строку на готовом компьютере?

Если на компьютере установлена OpenOS, и в автозагрузке ничего не прописано, то сразу после загрузки системы появится приглашение командной строки.

42 минуты назад, aMax сказал:

Допустип мне ножно управлять роботом с помощью планшета, в свою очередь планшет с графическим интерфейсом. Мне нужны кнопки для удобного управлением робота, и его доп. функциями, а графика для их удобного оформления.

Если цель стоит именно в управлении роботом, то удобнее будет сделать управление клавишами клавиатуры, а не кликать мышью по графическим кнопкам. А на экран вывести подсказки по этим кнопкам. Такое управление не только более удобно, оно ещё и быстро обрабатывается. Причём, независимо от картинки на экране, что позволяет, например, уменьшать размер экрана до одного символа и получить более широкий обзор движений робота или дрона. На форуме есть примеры таких решений.

Если же очень хочется именно GUI и мышкотыканья, то доступные символы можно посмотреть здесь:

Шрифт в OC

Символы. Lua

Ссылки на графически библиотеки кидать не буду, их довольно много, и найти их не сложно. Например, так:

https://lmgtfy.com/?q=графическая+библиотека+site%3Acomputercraft.ru

20 минут назад, aMax сказал:

Не вижу ничего непонятного.

Я тоже плохо понял вопрос.

В 09.08.2019 в 22:41, aMax сказал:

А можно ли сделать хоть простую графическую кнопку?!?

Ответ на этот единственный вопрос однозначен: Можно.

В 09.08.2019 в 22:41, aMax сказал:

Но мне важно узнать самые оптимальные, отзывчивые, простые варианты исполнения данной проблемы штуки от разных людей с +-опытом.

Вопрос имеет довольно общий, неконкретный характер. И ответ тоже будет общим. Надеюсь, он будет полезен.

Самый простой вариант: создать таблицу с координатами прямоугольников и текстом для их заполнения. Возможно, и с цветами тоже. Также таблица должна содержать ссылки на обработчики этих кнопок. Далее, все эти кнопки отрисовываются на экране. Поймав событие клика мыши, алгоритм последовательно обходит весь массив прямоугольников, и сравнивает координаты клика с координатами границ кнопок. При обнаружении совпадения клика с некоторой кнопкой управление передаётся соответствующему ей обработчику. Также все кнопки можно обрабатывать в одном обработчике, тогда в таблице можно хранить идентификаторы кнопок. А можно хранить одновременно как обработчики, так и их параметры. Эти вариации не сильно изменят итоговый алгоритм.

Самый быстрый вариант: формировать образ экрана вместе со всеми кнопками, и выводить их минимальным количеством операций, как это сделано, например в библиотеке DoubleBuffering от @ECS. Также можно заранее просчитать и заполнить массив всех возможных координат для кликов мыши и назначить каждой точке свой обработчик. При клике мыши останется лишь по координатам клика вытащить из таблицы нужный обработчик. Но на хранение таблицы придётся потратить память. При желании и образ экрана и таблицу с координатами кликов можно формировать заранее, до запуска программы пользователем. Эта вариация будет работать ещё быстрее.

Самый оптимальный вариант: это вообще что-то неведомое. Оптимум всегда зависит от целей. В каком-то случае можно жертвовать памятью, в другом быстродействием, а в третьем простотой. На этот вопрос не существует абстрактного ответа. Нужно знать все условия задачи, тогда можно будет говорить о поиске оптимума. И тоже не факт, что его удастся определить теоретически. Скорее всего, оптимум придётся искать экспериментально. Тот же @ECS тоже не сразу нашёл оптимальные решения для своих библиотек. И оптимум он искал под свою систему MineOS, балансируя между лимитами памяти и быстродействия.

Если речь идёт о пяти кнопках, то нет смысла морочить себе голову темой быстродействия. Если же количество кнопок измеряется сотнями, то имеет смысл найти закономерности и уже с их помощью оптимизировать поиск кнопки, на которой выполнен клик. Закономерности будут зависеть от условий задачи. Некоторые слишком жёсткие условия иногда можно скорректировать таким образом, чтобы создать закономерности для оптимизации.

При каком количестве кнопок надо задумываться об оптимизации, тоже решается индивидуально. Для получения опыта можно упарываться и на простых задачах. Но это занятие довольно быстро наскучит. Поэтому большинство программистов вспоминают про оптимизацию, когда их не устраивает быстродействие их программы. А это субъективный параметр. Часто оптимизация проходит по линии между дискомфортом от тормозов GUI и ленью программиста.

2 часа назад, ECS сказал:

@BrightYC угу, но лень-матушка в приоритете

Угу, и труд-батюшка тоже не всегда позволяет в Майнкрафте прогать.