ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Тяпничный криптунЪ и редукция
90 сообщений из 90, показаны все 4 страниц
  все  
Тяпничный криптунЪ и редукция
    #39906262
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Камрады привет. С пятницей. Дима. Илья. Сидоров. Сова. Сибиряков. И все-все-все. Пытаюсь осилить статью Making a Faster Cryptanalytic Time-Memory Trade-Off Вобщем вопрос первый пока. Что за функция редукции и как ее разработать? Из текста я понял только требования.
  • Она должна на выходе иметь тот-же алфавит что и на вход функции хеширования. И одинаковой длины.
  • На различных таблицах могут быть применены разные функции редукции
Непонятна связь между хешированием и редукцией. Второе зависит от первого? Другие вопросы еще не сварились в моей голове. Но будут по мере сил... Линки по теме.
...
Рейтинг: 0 / 0
20.12.2019, 17:10
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39906544
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Update.

Поисковые сети нам сообщают примерчик.
Код: sql
1.
2.
H(nus)=0e23df0
R(0e23df0)=wef


Цепочка хешей и редукций
Код: sql
1.
2.
     H             R        H           R
nus ---> 0e23df0 --> wef ---> a3bc8aa ---> ytr
...
Рейтинг: 0 / 0
21.12.2019, 20:33
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39906596
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Если внутри другой chain, появляется pwd=nus, то цепочка частично повторяется.

Код: sql
1.
2.
nus ---> 0e23df0 --> wef ---> a3bc8aa ---> ytr ---> becd2a4 ---> mng
trf ---> b983ff3 --> nus ---> 0e23df0 ---> wef ---> a3bc8aa ---> ytr
...
Рейтинг: 0 / 0
21.12.2019, 23:28
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39906597
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Если одну функцию редукции R заменить на набор различных функций R1,R2,R3...
то коллизий в цепочках не будет.
...
Рейтинг: 0 / 0
21.12.2019, 23:31
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39906747
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Кроме статей Филиппа Ошлина - практически ничего нет. Видео-материалы по теме на 99%
состоят либо из практического руководства по установке или использованию rt-gen, либо
из докладов Индусов которые рисуют корявые картинки на тему самих основ.
...
Рейтинг: 0 / 0
22.12.2019, 22:09
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39906832
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
С английским у меня не очень, поэтому сначала опишу как я понял принцип работы.

Подготовка
1. Выстраивается цепочка N пар Ключ-Шифр, типа
Код: sql
1.
Ключ1 -> Шифр1 -> Ключ2 -> Шифр2 -> ... -> КлючN -> ШифрN


где Шифр1 это какой-то постоянный текст зашифрованный с помощью Ключ1
Ключ2 генерируется из Шифр1 алгоритмом редукции.

2. Заполнение таблицы. Генерим цепочку для каждого значения ключа и если внутри цепочки ни один Шифр i не присутствует в таблице, то пара {Ключ1, ШифрN} добавляются в таблицу.

Таким образом происходит сжатие таблицы всех возможных пар {Ключ, Шифр} в N раз, где N длина цепочки.

Использование : берем какой-то ШифрХ и гоним его по цепочке пока не получим известный нам ШифрN из таблицы. Затем берем Ключ1 и по цепочке получаем КлючХ


Выводы
Как я понимаю задача функции редукции генерация Ключ i+1 из Шифр i .
Т.е. функция редукции может делать что угодно, например посчитать хэш/CRC/AES/XOR и привести к требуемому алфавиту ключа.
Основное требование к функции это сгенерить как можно меньше зацикленных и вырождающихся (уходящих в другую) цепочек, т.е. в идеале из каждого уникального Шифр i должен получаться уникальный Ключ i+1 . Ну и желательно чтобы функция побыстрее работала, т.к. цепочки достаточно длинные.
Я так понимаю автор проблему зацикливания решить не смог, поэтому обошел ее применив две разные функции, надеясь что для каждого конкретного значения шифра найдется цепочка хотя бы в одной таблице.

Приведение к алфавиту ключа не проблема. Легко решается по аналогии с переводом из одной системы счисления в другую. Например Base64.
...
Рейтинг: 0 / 0
23.12.2019, 08:29
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907079
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T, да все норм у тебя с английским. Тут вопрос не в языке а в способности оценить рациональное зерно.

Щас пригоню следующий вопрос.
...
Рейтинг: 0 / 0
23.12.2019, 15:22
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907149
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вот допустим у меня есть следующая (не радужная) табличка

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Ondertrouwd8 ad52bb899f98da83ad1a5ddd6eeae1f210757c1ef27df945f4d264ed29b9f3cd
opengewerkt8 164d5838ac1256405ae040d1f3d7a080d209c7eea87cacd7be7cb7210cfa91fb
i55po8x538if c7813fa89092f8ab358ba72abf40cc269404d5308160796db2a77bcf950b427b
jvvi5m4y36xr 5293a0f9dd3c6c8976cde75fd63b44afb4153bc46fa6fecf5701fc070b43ab70
Jichtpijnen3 65b21f7e3d196574086bdb2e808535af82a1d48e0ae4f56572c535a2c63ccbf6
j43sci9x03j3 f08604216a9950afee43a865d338bc08e69b957d152c479d35230ce9b0d2e331
hrd78ub12o2a d18ed9f7b176edefed01baacb144067fe0376de005d4cdae859ad66b0f0669e2
utkarshhanam 6b6319a93b0fae6b5a471b2beafdb09904403e5d95df7eb77768fa6c3c0d5f54



И я хочу применить данный метод. Слева - ключ (12 символов). Справа дайджест типа SHA1. Почему SHA1? Потому-что он мне нужен.
Он - меня интересует. Далее я хочу сформировать функцию редукции с учотом алфавита. Альфа-нумерик + верхний
и нижний кейс. Возьму Base64. Она - подходит. 12 символов кратно 3 и 4 тоесть отображается на base64 идеально
без padding.

И дальше ... - меня терзают смутные сомнения. Что-то здесь не то в моих рассуждениях.

 

Ключи это все 12-символьные слова которые я взял из нашего 1.2млрд текстового
файлика который использовался в топиках толстой сортировки.
...
Рейтинг: 0 / 0
23.12.2019, 17:01
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907172
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Литература по теме.

(Имена файлов - не оригинальные. Я переименовывал для своего удобства. Но легко гуглятся.)

Cryptoanalytic.Time-Memory.Tradeoff.for.Password.Hashing.Schemes.pdf
Making.a.Faster.Cryptoanalytic.Time-Memory.Trade-Off.pdf
Rainbow.Tables.explained.pdf
Reducing.Time.Complexity.in.RFID.Systems.pdf
Time-Memory.Trade-Offs.False.Alarm.Detection.Using.Checkpoints.pdf
...
Рейтинг: 0 / 0
23.12.2019, 17:24
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907230
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Твоя задача не решается этим методом. 64^12 примерно 10^21 паролей. Прикинь сколько времени уйдет на полный перебор для построения таблицы.

PS Пишу с телефона, подробности позже
...
Рейтинг: 0 / 0
23.12.2019, 18:56
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907231
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вот такая вот туфта получается. Ну и где тут экономия? Какой болт мне с таких редукций?
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Ondertrouwd8 --> rVK7iZ+Y2oOtGl3dburh8hB1fB7yfflF9NJk7Sm5880= --> rVK7iZ+Y2oOt --> BNkMNQC1RjQfhHqypziEyQbo1rEJ8ZrEvKgWGlBZ7HY= --> BNkMNQC1RjQf --> PwMeGzPPJmZjtIR+GnUxfJWfMf2Fdecl389+1hPNTZY= --> PwMeGzPPJmZj
opengewerkt8 --> Fk1YOKwSVkBa4EDR89eggNIJx+6ofKzXvny3IQz6kfs= --> Fk1YOKwSVkBa --> 8am0ewI3QtPeJAtR3X9n6rLjRz/ymVO3Ej/BoWpztDw= --> 8am0ewI3QtPe --> EwYnLJPzRxY8VTfCA7VwuwcwjAddQYeGiRP5IljrMzY= --> EwYnLJPzRxY8
i55po8x538if --> x4E/qJCS+Ks1i6cqv0DMJpQE1TCBYHltsqd7z5ULQns= --> x4E/qJCS+Ks1 --> pqegxH1QZhSQ3ejEpHcfhEp18ouDLrbT7WoHxfCEpa4= --> pqegxH1QZhSQ --> Bo1E1K3WHBj15kHI6qlukNoQnZjO9kFn2E40TSL3yGU= --> Bo1E1K3WHBj1
jvvi5m4y36xr --> UpOg+d08bIl2zedf1jtEr7QVO8Rvpv7PVwH8BwtDq3A= --> UpOg+d08bIl2 --> 3umAPYI28DnUqk486TDC6ocfyu6ihgm3nlDBBzKXRQo= --> 3umAPYI28DnU --> SVdwyTfmrNoU8MUIKo7zyBROgjNpgdr0r2rffEdwfSw= --> SVdwyTfmrNoU
Jichtpijnen3 --> ZbIffj0ZZXQIa9sugIU1r4Kh1I4K5PVlcsU1osY8y/Y= --> ZbIffj0ZZXQI --> 3rZenHYQuJA8P4+4FGgvrJAzlGmbWDr+trusIl1z2xg= --> 3rZenHYQuJA8 --> XJc2EF8LGdzoJVy8E73wLJ8shf7n2ajXC55b72dEftI= --> XJc2EF8LGdzo
j43sci9x03j3 --> 8IYEIWqZUK/uQ6hl0zi8COablX0VLEedNSMM6bDS4zE= --> 8IYEIWqZUK/u --> Z7TwKfWTt9j6nj9Lh1GKcFoilX+TArO6bLVmpQPZoPI= --> Z7TwKfWTt9j6 --> L8jJpZURw+UA5rIv0jFux3F/4Q+jW3dIT7nGxxHgQVI= --> L8jJpZURw+UA
hrd78ub12o2a --> 0Y7Z97F27e/tAbqssUQGf+A3beAF1M2uhZrWaw8GaeI= --> 0Y7Z97F27e/t --> zLn+viyMF4eOgYA7gZO6wa218Tbfgx4TPRHugikkL3I= --> zLn+viyMF4eO --> n5VIeAcRXDUtlgQ5Vx6nK7h5RGphs61oAQt3j1BzyCI= --> n5VIeAcRXDUt
utkarshhanam --> a2MZqTsPrmtaRxsr6v2wmQRAPl2V3363d2j6bDwNX1Q= --> a2MZqTsPrmta --> Q0CtMITCEjiMw1mnKtM1uZ4tccvbiHCQhuSdPiM2R/Q= --> Q0CtMITCEjiM --> tCm9zGawH4IXgAKi66f+CDM0sihofnnUoaYXFmnwyk8= --> tCm9zGawH4IX
j52604s03l0f --> 7NNMNKfLkUA62I7DmHXRUp+OqbSnWGSqKOo9rv82p54= --> 7NNMNKfLkUA6 --> 81z5nmk+0yV4nRU17wzO7OI3DtqlChrNHRwYJ5FOIz0= --> 81z5nmk+0yV4 --> 8X9GAyWFc4Q2eOBwxVEjEa6IoMdzE+TylNtXJnGJfwY= --> 8X9GAyWFc4Q2
gccxu98o9ag8 --> Yx0MA5tFxW9GNhmr4XC2TpVuRLz/dJBQQTuYKmlIAGs= --> Yx0MA5tFxW9G --> qGzY7UK5ZHfXsNaVWqypB2XCqI5KIDZUZ6gcbFx9q48= --> qGzY7UK5ZHfX --> To9WowujkJ8zJRn7DQzgEisswQn5604SkNclUyqnEWo= --> To9WowujkJ8z
kj8i6i4pe4y4 --> 6LiBLP54S3YBCIiR1qOYYGNIi3WA1/ZuDfPx7LzanuQ= --> 6LiBLP54S3YB --> 8BlsQPZtDPWmxF9pqm7wssx9jQ5R9PWrZTRLIcFoaIk= --> 8BlsQPZtDPWm --> M9bTudPa7DtCgZYOku3Xgcu60qt7ZUW7Z51f8xp8jt4= --> M9bTudPa7DtC
h7d49lc5m71f --> 2PHKUEk0MGIDR7C/Rs2wYsWKnQ9YY1GaZj5Y88yVpNc= --> 2PHKUEk0MGID --> mqAfdJhdLIKf/5ak8Q3kbhTtEQ2FTw/jqtqj1k1byN4= --> mqAfdJhdLIKf --> QxBZvzvhIimnNMwVI6djEY+/m5DHR61JNld5l+JwpUE= --> QxBZvzvhIimn
Arcticdrizzt --> noOMKjVrR+KFvrR3yN15goTysh8dzi9NnkvkRXvfIpw= --> noOMKjVrR+KF --> fZjVGMVqOwH7xdWlD0tQveNqwqh9uhsl4nTyPwfhxd4= --> fZjVGMVqOwH7 --> /BBkBz8IyXYBFvKmVRij9kYh58AysOaeSTkj7cxam40= --> /BBkBz8IyXYB
Aarontrident --> PMRQGuCB91eXMMLJk/5goWGR1NuOzK+5+URdUaRLL4o= --> PMRQGuCB91eX --> q6AmPK0tlC5RqNhv2WHzy44F936xIODTi2+yMlhb1Ng= --> q6AmPK0tlC5R --> UDCBFxAlGMhxyEkXga5mY6HUZ/LF0VWcrpuK8K6Lazs= --> UDCBFxAlGMhx
unanimityses --> yUEwVhTuCa7jm2FvZCiIbD/W+pdQ4om1PoLEEi6ya10= --> yUEwVhTuCa7j --> Ak7ai1HiWw72sVcj22Rpw2qvZ04toqr/HcO0BKxsk20= --> Ak7ai1HiWw72 --> MiL6drJJElxzFlrkcsZFPECg5NHfHBeTCX3Mvp3EEO8= --> MiL6drJJElxz
yticangupped --> re53JBaQa2XOCSYLxc+RNnniawVNJmCwrCcPATxGbH8= --> re53JBaQa2XO --> YbqNEA6mqmEhenOk//0TwqMZSya1oS6BOvsLJwSxFkk= --> YbqNEA6mqmEh --> w/68YAtORyQ6Gm5r16roXpspg54mu4RuNSm8X2Xz/sU= --> w/68YAtORyQ6


Пока я только проиграл в размере.

Я так понимаю что самый правый редукт (в последней колонке) должен оказать мне помощь в поиске keys?
Но как? На вход поступает к примеру хешик UDCBFxAlGMhxyEkXga5mY6HUZ/LF0VWcrpuK8K6Lazs=.
Что дальше? Какова логика поиска?

Кому интересно поломать дальше - вот сорц.

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

 
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
import org.apache.commons.codec.binary.Base64;
import org.apache.commons.codec.binary.Hex;

import java.io.FileInputStream;

import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.MessageDigest;
import java.util.Arrays;
import java.util.Properties;
import java.util.stream.Stream;
import static mayton.crypto.Utils.*;

public class RainbowGen {

    public static void main(String[] args) throws Exception {
        int t = 7; // Chain length
        int m = 16; // Chains in table
        int pwdLength = 12; // chars (by modulo 3)
        int limitHash = 3 * pwdLength / 4; // (by modulo 4)
        Properties properties = new Properties();
        properties.load(new FileInputStream("sensitive.properties"));
        String pwds = properties.getProperty("pwds");
        try (Stream<String> stream = Files.lines(Paths.get(pwds))) {
            stream.limit(m).forEach(line -> {
                print(line);
                print(" --> ");
                byte[] hash = getShaFromLine(line);
                for (int i = 0; i < ( t / 2 ); i++) {
                    //print(Hex.encodeHexString(hash));
                    print(Utils.encodeBase64(hash));
                    print(" --> ");
                    String reduct = Utils.encodeBase64(subArray(hash, 0, limitHash));
                    print(reduct);
                    if (i < t / 2 - 1) {
                        print(" --> ");
                        hash = getShaFromLine(reduct);
                    }
                }
                print("\n");
            });
        }
    }

}


Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
import org.apache.commons.codec.binary.Base64;
import org.jetbrains.annotations.NotNull;
import javax.annotation.concurrent.NotThreadSafe;
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.Arrays;

@NotThreadSafe
public class Utils {

    static MessageDigest messageDigest = null;
    static Base64 base64encoder = new Base64();

    static {
        try {
            messageDigest = MessageDigest.getInstance("SHA-256");
        } catch (NoSuchAlgorithmException ex) {
            throw new RuntimeException(ex);
        }
    }

    private Utils() {}

    @NotNull
    public static byte[] subArray(byte[] array, int beg, int end) {
        return Arrays.copyOfRange(array, beg, end);
    }

    public static void print(@NotNull String arg) {
        System.out.print(arg);
    }

    @NotNull
    public static byte[] getShaFromLine(@NotNull String line) {
        messageDigest.reset();
        messageDigest.update(line.getBytes(StandardCharsets.UTF_8));
        return messageDigest.digest();
    }

    @NotNull
    public static String encodeBase64(@NotNull byte[] arr) {
        return base64encoder.encodeAsString(arr);
    }

}

...
Рейтинг: 0 / 0
23.12.2019, 19:01
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907247
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ага. Сам допёр. Тоесть если их так расписать. И потом развернуть левое и правое и проиндексировать.

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
j43sci9x03j3 -->  L8jJpZURw+UA
hrd78ub12o2a -->  n5VIeAcRXDUt
utkarshhanam -->  tCm9zGawH4IX
j52604s03l0f -->  8X9GAyWFc4Q2
gccxu98o9ag8 -->  To9WowujkJ8z
kj8i6i4pe4y4 -->  M9bTudPa7DtC
h7d49lc5m71f -->  QxBZvzvhIimn
Arcticdrizzt -->  /BBkBz8IyXYB
Aarontrident -->  UDCBFxAlGMhx
unanimityses -->  MiL6drJJElxz
yticangupped -->  w/68YAtORyQ6



Тогда подсвеченное - и будет искомой строкой.
...
Рейтинг: 0 / 0
23.12.2019, 19:13
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907249
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
А с этим как быть?

Код: sql
1.
Fk1YOKwSVkBa4EDR89eggNIJx+6ofKzXvny3IQz6kfs=



Маги и колдуны. Помогайте.
...
Рейтинг: 0 / 0
23.12.2019, 19:14
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907296
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Этот инструмент тут не подходит. Это алгоритм ускорения массового подбора паролей. Тут это запрещено обсуждать, но тема тупиковая, поэтому продолжим. Этот алгоритм оптимизирует подбор конкретного пароля, у автора ускорилось в 7 раз по сравнению с тупым перебором, но перебор не исчез, просто перебор происходит заранее, но в более тяжелой форме для построения таблицы цепочек 22046586 , т.е. польза будет если только массово подбирать, получить один пароль перебором будет быстрее.

У тебя 10 21 вариантов паролей, лень считать точно, но прикинув на глаз могу сказать что построение таблицы может занять годы, а может и десятилетия, может еще больше...
...
Рейтинг: 0 / 0
23.12.2019, 20:57
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907298
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Я не хочу обсуждать такие темы как перебор паролей. Поэтому в дальнейшем я буду использовать такие
термины как ключ. И хеш.

И применение я искал не в атаках на несчастных владельцев Windows а для других задач. Хотя-бы для подписывания
блоков блокчейна. Как вариант. Да. Вот тема топика. Оптимизация подписывания блокчейна. За это и буду топить.

А таблицы эти уже построены. Проект называется http://project-rainbowcrack.com/

Поэтому к той теме я ничего нового не добавлю. Просто сижу. Разбираюсь.
...
Рейтинг: 0 / 0
23.12.2019, 21:04
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907301
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Я не хочу обсуждать такие темы как перебор паролей.

Зачем тогда ее поднял?

Ничего криминального тут нет, раз все обсуждают, то почему нам не обсудить? Эта тема старье и об этом давно всем известно, в т.ч. тебе, т.к. ты не спроста сделал 12 символов в пароле.
...
Рейтинг: 0 / 0
23.12.2019, 21:19
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907303
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Ну. Дык. Где рациональное зерно? Радужка оптимизирует хранение за счет более медленного доступа.
По сути это торговля. Мы продаем диск. Но покупаем CPU. Вместо верчения циклом - итеративный
поиск по дисковому файлу.

Я так перевожу себе trace-off. Как сделка. Обмен. Торг.

А где в моём случае сделка? Редукция? Да работает. А как двигаться по чейну справа налево? Я не знаю.
...
Рейтинг: 0 / 0
23.12.2019, 21:29
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907304
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Ну. Дык. Где рациональное зерно?

Нет его тут, совсем.
...
Рейтинг: 0 / 0
23.12.2019, 21:31
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907307
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton, подробнее свою задачу опиши, может я вижу совсем не то что тебе надо
...
Рейтинг: 0 / 0
23.12.2019, 21:34
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907309
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Представь что я ищу ключ по SHA1. Обратная операция по отношению к хешированию.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Ondertrouwd8 ad52bb899f98da83ad1a5ddd6eeae1f210757c1ef27df945f4d264ed29b9f3cd
opengewerkt8 164d5838ac1256405ae040d1f3d7a080d209c7eea87cacd7be7cb7210cfa91fb
i55po8x538if c7813fa89092f8ab358ba72abf40cc269404d5308160796db2a77bcf950b427b
jvvi5m4y36xr 5293a0f9dd3c6c8976cde75fd63b44afb4153bc46fa6fecf5701fc070b43ab70
Jichtpijnen3 65b21f7e3d196574086bdb2e808535af82a1d48e0ae4f56572c535a2c63ccbf6
j43sci9x03j3 f08604216a9950afee43a865d338bc08e69b957d152c479d35230ce9b0d2e331
hrd78ub12o2a d18ed9f7b176edefed01baacb144067fe0376de005d4cdae859ad66b0f0669e2
utkarshhanam 6b6319a93b0fae6b5a471b2beafdb09904403e5d95df7eb77768fa6c3c0d5f54



По сути мне надо найти любую символьную последовательность которая удовлетворяет первому
хешу ad52bb899f98da83ad1a5ddd6eeae1f210757c1ef27df945f4d264ed29b9f3cd. Не обязательно она должна
быть ключом Ondertrouwd8. Это может быть любая другая последовательность. Не суть.

Я хочу сэкономить. Я не хочу вращать циклы. Я заранее знаю формулу которая порождает ключи.
Например ключи - это всегда даты 2015-01-01. Или некие комбинации даты и суммы.

Я хочу выиграть время. Я хочу находить ключ менее чем за 10 минут. Большее время - я потерял деньги.
Уложился в 9 минут - заработал.

Я могу использовать железо на базе видеокарт. Но я ищу альтернативные векторы развития.
Зачем вкладываться только в вычислительные модули? Когда есть модули хранения которые
дешевы и их много. И есть принцип memory trade-off о котором так долго пишет несчастный французик.

Впрочем всё это поток моего сознания.

Можете критиковать.
...
Рейтинг: 0 / 0
23.12.2019, 21:49
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907329
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
И функции редукции у меня неправильные. Одинаковые.
...
Рейтинг: 0 / 0
24.12.2019, 00:21
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907347
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
mayton
Я заранее знаю формулу которая порождает ключи.
Например ключи - это всегда даты 2015-01-01. Или некие комбинации даты и суммы.
За использование "осмысленного" ключевого материала полагается расстрел из рогатки.
Ключ должен быть (псевдо)случайным "и здесь нет темы для обсуждения".
Как надёжно зашифровать ключ на коротком пароле - отдельная тема.
...
Рейтинг: 0 / 0
24.12.2019, 07:02
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907364
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
По сути мне надо найти любую символьную последовательность которая удовлетворяет первому
хешу ad52bb899f98da83ad1a5ddd6eeae1f210757c1ef27df945f4d264ed29b9f3cd. Не обязательно она должна
быть ключом Ondertrouwd8. Это может быть любая другая последовательность. Не суть.

Я хочу сэкономить. Я не хочу вращать циклы. Я заранее знаю формулу которая порождает ключи.
Например ключи - это всегда даты 2015-01-01. Или некие комбинации даты и суммы.

Тут ты сам себе противоречишь. Или у тебя хэш от 12 символов любых буквоцифр или дата. В первом случае 64^12 вариантов, во втором 737 300 (365*2020). Второй элементарно перебирается без всяких оптимизаций.

mayton
Я заранее знаю формулу которая порождает ключи.

Если ее знаешь, то хэш обратим и проблемы нет, взял и посчитал по формуле, получил ключ.

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

mayton
Я хочу выиграть время. Я хочу находить ключ менее чем за 10 минут. Большее время - я потерял деньги.
Уложился в 9 минут - заработал.

Считаем:

Размер одной записи таблицы 9 (ключ) + 32 (хэш) = 43 байта
Допустим таблица 4.3 Тб (4.3*10 12 ), т.е. 10 11 записей
Всего у тебя 4.7*10 21 (64 12 ) вариантов ключа, следовательно в одной записи цепочка из 4.7*10 10 пар {ключ, хэш}

Для получения ключа по хэшу требуется пройти всю цепочку (движение возможно только слева направо, а надо сделать шаг назад), поэтому прикидываем минимальную скорость: 4.7*10 10 / 600 сек. = 78 млн. раз в секунду делать редукцию и считать хэш. Плюс по-началу еще надо каждый хэш искать в таблице пока не найдем.

В принципе скорость 7.8*10 7 вполне достижимая, т.е. можно получить ключ менее чем за 10 минут, но давай прикинем время построения таблицы с такой же скоростью. Допустим мы изобрели супер оптимальный алгоритм когда хэш каждого ключа считается однократно: 4.7*10 21 / 7.8*10 7 = 6*10 13 секунд = 694.4 млн дней = 1.9 млн лет. И это идеальный алгоритм, реальный будет намного хуже, т.к. потребует повторных рассчетов, кроме того при распараллеливании Закон Амдала сработает.
...
Рейтинг: 0 / 0
24.12.2019, 08:56
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907366
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Нужен перерыв.
...
Рейтинг: 0 / 0
24.12.2019, 09:07
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907406
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Пока надо отъехать назад. Короткий брейншторм.

Alpha-num - множество символов латиницы + цифры. 26 + 26 + 10 = 62

Пишу на псевдо-языке.

Код: sql
1.
2.
3.
$ alpha-num-generator length=6 >> alphanum-keys.csv

$ select column(1) from csvfile(alphanum-keys.csv) order by SHA1(column(1)) >> alphanum-keys-ordered-sha1.csv


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

Длина файла:

Код: sql
1.
62^6 = 56 800 235 584 ~ 52Гб.



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

Теперь - размер. Для 6 символьных ключей - да. Еще можно понять. Но для 12 символьных размер
этого файла получается неподъемным.
...
Рейтинг: 0 / 0
24.12.2019, 11:09
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907407
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
В то-же время для md5_mixalpha-numeric-space#1-8_0 радужная табличка занимает 51.64Gb.
Хм... при таком пространстве ключей места для них - не хватит физически. Что-же они делают
с ключами? Тоже подвергают редукции?

1-8 это я так понимаю все ключи диапазона до 8 символов. Даже больше. Тк. надо учесть еще
и все 7 символьные и 6 символьные и так далее.
...
Рейтинг: 0 / 0
24.12.2019, 11:14
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907436
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Пока надо отъехать назад. Короткий брейншторм.

Alpha-num - множество символов латиницы + цифры. 26 + 26 + 10 = 62

Пишу на псевдо-языке.

Код: sql
1.
2.
3.
$ alpha-num-generator length=6 >> alphanum-keys.csv

$ select column(1) from csvfile(alphanum-keys.csv) order by SHA1(column(1)) >> alphanum-keys-ordered-sha1.csv


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

Длина файла:

Код: sql
1.
62^6 = 56 800 235 584 ~ 52Гб.



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

Неправильно посчитал. 62^6 это количество ключей, а одна запись в файле {ключ, хэш} это минимум 43 байта, т.е. умножай на 43 и будет ~2 Тб.
...
Рейтинг: 0 / 0
24.12.2019, 12:17
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907437
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T,

спасибо. Вот как полезен взгляд со стороны.
...
Рейтинг: 0 / 0
24.12.2019, 12:19
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907439
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
А таблицы эти уже построены. Проект называется http://project-rainbowcrack.com/

Поэтому к той теме я ничего нового не добавлю. Просто сижу. Разбираюсь.

Заглянул туда, там самая большая таблица на 1.3*10 16 ключей, а ты замахнулся на 3.2*10 21 (это 62 12 ), оно больше в 246000 раз.
...
Рейтинг: 0 / 0
24.12.2019, 12:27
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907443
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Насколько я понимаю… механика memory trade-off это есть некий ползунок который позволяет
нам самим решать сколько выделить под хранение и сколько под поиски нашего ключа.

Статья Ошлина декларирует параметры

int t = 7; // Chain length
int m = 16; // Chains in table

Это две оси измерений. И есть еще длина ключа. Или сет длин ключей если я хочу вариативный режим.
...
Рейтинг: 0 / 0
24.12.2019, 12:37
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907459
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Насколько я понимаю… механика memory trade-off это есть некий ползунок который позволяет
нам самим решать сколько выделить под хранение и сколько под поиски нашего ключа.

Да, как я понимаю. Например у тебя полная таблица 2 Тб, ты хочешь ужать до 2 Гб, т.е. в 1024 раза, просто делаешь размер цепочки 1024 и генеришь под нее таблицу, размер записи не меняется, сама запись состоит из {ключ первого в цепочке, хэш последнего}.

mayton
И есть еще длина ключа. Или сет длин ключей если я хочу вариативный режим.

Удобнее несколько таблиц взять, чем сделать одну для ключей переменной длины. Ключ переменной длины займет дополнительное место, запись переменной длины создаст проблемы при поиске.
...
Рейтинг: 0 / 0
24.12.2019, 13:01
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907467
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Кроме статей Филиппа Ошлина - практически ничего нет. Видео-материалы по теме на 99%
состоят либо из практического руководства по установке или использованию rt-gen, либо
из докладов Индусов которые рисуют корявые картинки на тему самих основ.

Я так понимаю тема не сильно популярная, поэтому берут готовый софт и таблицы качают.

Я немного поразмышлял над генератором таблиц - задача непростая. Непонятно как запараллелить.

Например имеем последовательность делим ее на цепочки по 3
Код: sql
1.
k1 -> h1 -> k147 -> h147 -> k15 -> h15 -> k92 -> h92 ...


Если тупо считать от каждого ключа, то таблица не уменьшится, т.к. получим избыточные цепочки от каждого ключа
Код: sql
1.
2.
3.
k1 -> h1 -> k147 -> h147 -> k15 -> h15
k147 -> h147 -> k15 -> h15 -> k92 -> h92
k15 -> h15 -> k92 -> h92 ...


Т.е. дополнительно надо как-то проверять что промежуточные ключи (или их хэши) не присутствуют в цепочке.
Допустим один поток считает от k1
Код: sql
1.
k1 -> h1 -> k147 -> h147 -> k15 -> h15


В это время другому потоку выдали k15, но т.к. первый не досчитал, то в таблице этого ключа нет. Если создать централизованное хранилище обработанных ключей, то будут тормоза из-за доступа к нему.
...
Рейтинг: 0 / 0
24.12.2019, 13:24
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907503
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T

mayton
И есть еще длина ключа. Или сет длин ключей если я хочу вариативный режим.

Удобнее несколько таблиц взять, чем сделать одну для ключей переменной длины. Ключ переменной длины займет дополнительное место, запись переменной длины создаст проблемы при поиске.

Да. Они предполагают что у нас нет вариативной длины ключа.
Просто тупо разделяют таблицы по длинам. Для каждой длины - своя таблица.
Это удобно для навигации по бинарному файлу. Записи - фиксированной длины.
...
Рейтинг: 0 / 0
24.12.2019, 14:26
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907574
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T

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

Да я тоже об этом думал. Если у нас - возможны коллизии ключей в процессе построения цепочки
то надо как-то их детектировать. Хеш-мапа? Дерево? А как с параллелизмом?
...
Рейтинг: 0 / 0
24.12.2019, 16:58
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907656
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Dima T

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

Да я тоже об этом думал. Если у нас - возможны коллизии ключей в процессе построения цепочки
то надо как-то их детектировать. Хеш-мапа? Дерево? А как с параллелизмом?

Как вариант: битмап для первого миллиарда ключей, займет памяти всего 128 Мб, а дальше каждый поток стартует с очередного ключа (1,2,3 и т.д.) и пилит свою последовательность разрубая ее на цепочки нужной длины, как наткнулся на ключ меньше лярда - проверка по битмапу - не посчитано ли дальше другим потоком, т.е. синхронная проверка очень малого количества ключей. Но тут еще надо добавить контроль зацикливания и перетекания в другую цепочку, а может и не надо, хз сколько это добавит лишнего.
...
Рейтинг: 0 / 0
24.12.2019, 20:37
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907680
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Самый лучший параллелизм - это shared nothing. Если запускать процессы формирования таблиц
для 12,11,10 ... e,t.c символьных ключей раздельно то у них не будет коллизий вообще.

Правда мне кажется диск может стать узким местом. Тут нужна какая-то механика буферизации I/O
и сортировка дисковых записей.
...
Рейтинг: 0 / 0
24.12.2019, 22:59
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907683
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вот специально для такого любопытного как я, сделали формулы https://www.tobtu.com/rtformulas.php
...
Рейтинг: 0 / 0
24.12.2019, 23:19
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907716
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Самый лучший параллелизм - это shared nothing. Если запускать процессы формирования таблиц
для 12,11,10 ... e,t.c символьных ключей раздельно то у них не будет коллизий вообще.

Нет гарантии что цепочки не сольются и разные потоки начнут считать одно и то же. Например
Код: sql
1.
2.
k1 -> h1 -> k147 -> h147 -> k15 -> h15 -> k92 -> h92 ...
k2 -> h2 -> k317 -> h317 -> k92 -> h92 ...


mayton
Правда мне кажется диск может стать узким местом. Тут нужна какая-то механика буферизации I/O
и сортировка дисковых записей.

I/O тут очень мало, в основном расчеты. Цепочка из миллионов пар записывается в 40 байт, а считается она от секунды до нескольких минут. С сортировкой проблему можно порешать хранением в несколько файлов: накопил в map миллион записей - сбросил в файл в сортированном виде и т.д. в конце смержил все файлы в один. Или организовать файл постранично в виде дерева, как SQL-сервера хранят кластерный индекс.

Я придумал алгоритм распараллеливания:
Делаем битмап на первый миллиард ключей, очередь заданий на продолжение, очередь результатов.
Создаем пул потоков считателей, каждый поток получает задание (ключ - начало цепочки), обсчитывает цепочку, помещает в очередь результатов. При получении ключей присутствующих в битмапе - пометка в битмапе как обработанных. Если ключ в битмапе уже помечен обработаным, то остановка расчета цепочки, возврат посчитанного.
Из посчитанной цепочки проверяется хэш последнего на присутствие в базе, если отсутствует, то формируется задание от ключа (редукции хэша), т.е. расчет цепочки следующей за этой. Результат в любом случае записывается в таблицу.
Получение задания на расчет: извлекаем из очереди заданий, если там пусто, то из битмапа очередной не обсчитанный. Если в битмапе все помечены, то завершение.

Таким образом будут обсчитаны все последовательности для ключей до миллиарда и перекрытие цепочек будет незначительное.
Но непонятным остается вопрос: сколько дыр осталось? Т.е. сколько ключей не попало ни в одну из цепочек.
Приблизительно покрытие можно прикинуть посчитав общее количество ключей в обсчитанных цепочках.

Узкое место это проверка хэша из результата в таблице из ранее посчитанного. Это займет большее время чем сам расчет цепочки.
...
Рейтинг: 0 / 0
25.12.2019, 08:08
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907855
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
Самый лучший параллелизм - это shared nothing. Если запускать процессы формирования таблиц
для 12,11,10 ... e,t.c символьных ключей раздельно то у них не будет коллизий вообще.

Нет гарантии что цепочки не сольются и разные потоки начнут считать одно и то же. Например
Код: sql
1.
2.
k1 -> h1 -> k147 -> h147 -> k15 -> h15 -> k92 -> h92 ...
k2 -> h2 -> k317 -> h317 -> k92 -> h92 ...


А как ты себе понял выбор вот этого параметра? Он также есть в статье.
Код: sql
1.
int t = 7; // Chain length



Для меня пока он - вообще не очевиден. Я его взял с потолка.
...
Рейтинг: 0 / 0
25.12.2019, 12:52
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907863
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T

I/O тут очень мало, в основном расчеты. Цепочка из миллионов пар записывается в 40 байт, а считается она от секунды до нескольких минут. С сортировкой проблему можно порешать хранением в несколько файлов: накопил в map миллион записей - сбросил в файл в сортированном виде и т.д. в конце смержил все файлы в один. Или организовать файл постранично в виде дерева, как SQL-сервера хранят кластерный индекс.

Самое лучшее распараллеливание - это на уровне входных данных. Например. Если ключи у нас - даты c префиксом вида
от Berlin-1939-01-01 до Berlin-2020-01-01 то мы их можем разделить по модулю 4 к примеру и раздать в виде задания
на 4 worker-threads. Но в процессе генерации хешей и свёрток мы должны контролировать появление уже расчитанной
свёртки иначе мы зацикливается на расчете того что уже было расчитанно. Но если коллизия и проверка по хешу (который
будет разделяемым объектом между 4 потоками) слишком дорого стоит то мы можем на нее забить болт и спокойно
досчитать цепочку до величины t. Это даст возможность worker-thread работать на его крейсерной скорости.
А уже после окончательного формирования таблицы для всего диапазона Berlin-* можно прогнать либо sort либо
unique просто одним потоком по большому файлу.

Кстати у меня - дежавю. Мне кажется где-то мы обсуждали unique несколько лет назад и даже писали код.
...
Рейтинг: 0 / 0
25.12.2019, 13:02
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907864
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
А как ты себе понял выбор вот этого параметра? Он также есть в статье.
Код: sql
1.
int t = 7; // Chain length



Для меня пока он - вообще не очевиден. Я его взял с потолка.

Это длина одной цепочки. За счет нее получается сжатие, т.е. экономия памяти, но увеличение времени расчета. Читай алгоритм 22046586 , я там это число назвал N.

Выбор конкретного значения зависит от размера ключа и желаемого размера таблицы. Пример расчета я тоже давал
Dima T
Размер одной записи таблицы 9 (ключ) + 32 (хэш) = 43 байта
Допустим таблица 4.3 Тб (4.3*10 12 ), т.е. 10 11 записей
Всего у тебя 4.7*10 21 (64 12 ) вариантов ключа, следовательно в одной записи цепочка из 4.7*10 10 пар {ключ, хэш}

Т.е. для того случая t = 4.7*10 10
...
Рейтинг: 0 / 0
25.12.2019, 13:06
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907870
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
А как ты себе понял выбор вот этого параметра? Он также есть в статье.
Код: sql
1.
int t = 7; // Chain length



Для меня пока он - вообще не очевиден. Я его взял с потолка.

Это длина одной цепочки. За счет нее получается сжатие, т.е. экономия памяти, но увеличение времени расчета. Читай алгоритм 22046586 , я там это число назвал N.

Выбор конкретного значения зависит от размера ключа и желаемого размера таблицы. Пример расчета я тоже давал

Все равно не понимаю.

Для моего случая. Я начинаю симуляцию в 1 поток. 17-символьные ключи. Алфавит малый. Хеш-короткий. t=5
Код: sql
1.
2.
3.
Berlin-1939-01-01 --> 028934752893 --> 0130540-B--01 --> 028934752893 --> 199933333999
Berlin-1939-01-02 --> 029834795729 --> 0130540-B--01 --> 028934752893 --> BBBeeeerliiin
Berlin-1939-01-03 --> 111122233333 --> [Berlin-1939-01-02]


Где здесь экономия? Я мог просто сохранить первые 2 столбца таблицы.

Код: sql
1.
2.
Berlin-1939-01-01 --> 028934752893
Berlin-1939-01-02 --> 029834795729


Да могли произойти совпадения на Berlin-1939-01-02 который случайно возник после редукции. Но разве это будет системным?
Настолько системным чтобы выборосить целую цепочку второй строки?
...
Рейтинг: 0 / 0
25.12.2019, 13:21
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39907903
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Кстати у меня - дежавю. Мне кажется где-то мы обсуждали unique несколько лет назад и даже писали код.

Писали, но задача была другая: выбрать уникальные строки из большого текстового файла.
mayton
Все равно не понимаю.

Для моего случая. Я начинаю симуляцию в 1 поток. 17-символьные ключи. Алфавит малый. Хеш-короткий. t=5
Код: sql
1.
2.
3.
Berlin-1939-01-01 --> 028934752893 --> 0130540-B--01 --> 028934752893 --> 199933333999
Berlin-1939-01-02 --> 029834795729 --> 0130540-B--01 --> 028934752893 --> BBBeeeerliiin
Berlin-1939-01-03 --> 111122233333 --> [Berlin-1939-01-02]


Где здесь экономия? Я мог просто сохранить первые 2 столбца таблицы.

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

Давай на примере: есть последовательность
Код: sql
1.
k1 -> h1 -> k147 -> h147 -> k15 -> h15 -> k92 -> h92


т.е. взяли первый ключ, самый маленький, Berlin-1939-01-01. Посчитали его хэш (h1), затем посчитали редукцию h1 и получили какой-то ключ, например k147. Мы заранее не знаем какой ключ получим, узнаем только посчитав, но знаем что результат неизменен, т.е. редукция h1 всегда выдает k147. Затем считаем хэш k147 (h147) и т.д. у нас выстраивается цепочка нужной длины.

Пусть t=4, приведенная цепочка записывается в таблицу как {k1, h92}, ключ первого и хэш последнего, остальные три пары никуда не пишем потому что взяв k1 восстановим всю цепочку, отсюда сжатие в 4 раза.

mayton
Самое лучшее распараллеливание - это на уровне входных данных. Например. Если ключи у нас - даты c префиксом вида от Berlin-1939-01-01 до Berlin-2020-01-01 то мы их можем разделить по модулю 4 к примеру и раздать в виде задания
на 4 worker-threads.

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

Хранить обработанные ключи мы не можем даже биткартой из-за их огромного количества.
...
Рейтинг: 0 / 0
25.12.2019, 14:27
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908010
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T

Давай на примере: есть последовательность
Код: sql
1.
k1 -> h1 -> k147 -> h147 -> k15 -> h15 -> k92 -> h92



А почему ты остановил цепочку на хеше? Нужен-же ключ. Хеш - толстый. 160 бит. 256 бит. Вся суть в том
что хеши мы не храним.

Я как себе понимаю. Мы должны начать с чего угодно. Но в конце цепочки должен стоять известный ключ.
Тогда для
Код: sql
1.
k1 -> h1 -> k147 -> h147 -> k15 -> h15 -> k92


Выкидываем хеши.

Остается k1 и k92. И мы заранее знаем длину цепочки (по определению) 8 элементов. Или точно вычислим что в ней
было не более чем 3 хеш преобразования.
Код: sql
1.
k1 -> .... -> k92


И тогде для данного искомого хеша h1, мы делаем как в рекурсии Reduct(h1) и ищем среди всех правых ячеек.
Потом еще раз Reduct(Hash(Reduct(h1))) и еще раз ищем.
И потом еще раз Reduct(Hash(Reduct(Hash(Reduct(h1)))) и если не нашли то уже 100% нету такого
у нас в базе.

Верно?
...
Рейтинг: 0 / 0
25.12.2019, 18:30
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908027
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Верно?

Поздравляю, ты усовершенствовал исходный алгоритм ))

Храня цепочку как {ключ первый, ключ последний} при 12 символах ключа мы займем 18 байт против 43-х, т.е. запись будет в 2.4 раза компактней.

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

Автор алгоритма скорее всего не стал заморачиваться на возможно повторяющиеся конечные ключи, а просто взял уникальный хэш как ключ для поиска (коллизия терминологий), который не должен повторяться к таблице.
...
Рейтинг: 0 / 0
25.12.2019, 19:27
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908031
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
Верно?

Поздравляю, ты усовершенствовал исходный алгоритм ))

Храня цепочку как {ключ первый, ключ последний} при 12 символах ключа мы займем 18 байт против 43-х, т.е. запись будет в 2.4 раза компактней.

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

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

Я сильно сомневаюсь что я смог что-то улучшить в проекте http://project-rainbowcrack.com/
Я занимаюсь им только 5 дней. А ребята - много лет. Я просто хочу идеи сжатия толстых поисковых таблиц
применить на практике но в другой области.

Блокчейн. Базы данных. Биг-дата.
...
Рейтинг: 0 / 0
25.12.2019, 19:35
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908047
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Я сильно сомневаюсь что я смог что-то улучшить в проекте http://project-rainbowcrack.com/
Я занимаюсь им только 5 дней. А ребята - много лет.

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

Блокчейн. Базы данных. Биг-дата.

Сомневаюсь что получится. Там ключ большой, как следствие гигантское количество вариантов ключа такого размера. 12 символов это всего ничего, но уже дофига для данного алгоритма 22047496

PS Я вижу только одно применение данному алгоритму, но тут это запрещено обсуждать. И примеры на радужном сайте как раз про это.
...
Рейтинг: 0 / 0
25.12.2019, 20:08
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908060
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Приведу цитату с Биткоин вики

https://ru.bitcoinwiki.org/wiki/Майнинг Работа майнеров заключается в подборе правильного хэша, который подойдет ко всем транзакциям, находящимся в сети, и обеспечит получение секретного ключа. Возможных комбинаций – миллионы, поэтому процесс, как правило, занимает много времени и требует наличия мощного оборудования.

Hash Rate — скорость, с которой решается математическая задача. Измеряется параметром «хэш в секунду» (H/s).

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

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

Разные криптовалюты используют разные алгоритмы POW или той самой безсмысленной работы.
SHA1 кажется релевантна к биткоину. Эфириум например здесь не подходит. У него какая-то другая функция POW.

Моя идея была еще в том чтобы разбалансировать майнинг с GPU/ASIC на рабочие станции с дисковой стойкой.
Но это - мечты и идеи которые надо просто проверять. Пока - вопрос о принципиальной возможности.
...
Рейтинг: 0 / 0
25.12.2019, 20:32
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908071
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Пока - вопрос о принципиальной возможности.

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

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

PS Получается что у майнеров всего 2 32 вариантов хэшей и не факт что есть хоть один, который даст требуемое количество ноликов на конце, т.е. есть комбинации которые заведомо невозможно намайнить.
...
Рейтинг: 0 / 0
25.12.2019, 20:49
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908088
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Да POW создавался с целью гарантии того была проделана работа. Но у нас есть принцип Memory-Trade-Off.
...
Рейтинг: 0 / 0
25.12.2019, 21:31
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908139
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вот пока я исходников майнера не видел. Только частные факты.
Правда или нет я -хз. Но учитывая брейншторм в топике - можно писать что угодно.

Факт с описания Дерева Меркла на википедии

https://ru.wikipedia.org/wiki/Дерево_хешей В биткойне в качестве хеш-функции используется двойное SHA-256, то есть



Впрочем, хеш-функция может быть любой, например Tiger Tree Hash (TTH), используемый в файлообменных p2p-сетях, является деревом Меркла с хеш-функцией Tiger[2].
...
Рейтинг: 0 / 0
25.12.2019, 22:36
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908254
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
mayton
Да POW создавался с целью гарантии того была проделана работа. Но у нас есть принцип Memory-Trade-Off.
Если это будет достаточно выгодно, то будет оптимизирован любой алгоритм любого блокчейна. Это ж, блин, "ничего личного - чистый бизнес".
Как только создание специализированных решений стало оправдано - появились ASIC-фермы для биткоина. Как только курс взлетел до небес - появилась ниша для майнинга на GPU и (опять) её заняли оптимисты разных мастей.
Смысл тратить интеллектуальные усилия на бессмысленную деятельность???
...
Рейтинг: 0 / 0
26.12.2019, 06:01
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908386
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Это-ж тяпничный топик. Поток сознания.
...
Рейтинг: 0 / 0
26.12.2019, 12:39
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908715
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Что поднимем на завтра? SHA? Блокчейны? Различные алгоритмы POW?
...
Рейтинг: 0 / 0
26.12.2019, 21:15
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908867
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Таблички публикуются в формате rti2. Вот его описание
https://freerainbowtables.com/rti2formatspec.pdf

На авторском сайте есть только описание rt, rtc
http://project-rainbowcrack.com/file_format.htm
...
Рейтинг: 0 / 0
27.12.2019, 10:41
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39908887
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
По размерам. Таблички.
Нижний алфавит + цифры. До 8 символов на ключ.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
  71216353  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x11263079_distrrtgen[p][i]_10.rti2'
 424319717  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_00.rti2'
 424326518  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_01.rti2'
 424324519  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_02.rti2'
 424326005  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_03.rti2'
 424326684  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_04.rti2'
 424324925  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_05.rti2'
 424319576  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_06.rti2'
 424325541  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_07.rti2'
 424323985  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_08.rti2'
 424320484  'mysqlsha1_loweralpha-numeric-space#1-8_0_10000x67108864_distrrtgen[p][i]_09.rti2'
      1265   mysqlsha1_loweralpha-numeric-space#1-8_0.md5sums


Занимают 4 гигабайта. Можем сверить наши формулы. Как они вышли на эту величину.
Еще также интересует вероятность промаха. Тоесть когда ключ был но мы его каким-то образом
потеряли. Вследствие свёрток-редукций.
...
Рейтинг: 0 / 0
27.12.2019, 11:12
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909321
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Что поднимем на завтра? SHA? Блокчейны? Различные алгоритмы POW?

ИМХО эти темы завяли уже как несколько лет. Не вижу смысла их трупики тормошить.
...
Рейтинг: 0 / 0
27.12.2019, 21:16
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909334
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вижу ты спешишь закрыть. Ну ок закрывай.
...
Рейтинг: 0 / 0
27.12.2019, 22:36
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909401
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Вижу ты спешишь закрыть. Ну ок закрывай.

Можно дальше пообсуждать. Я к тому что мое личное мнение про блокчейны, майнинги и т.п. всегда было негативное. Это какие-то тупиковые технологии.
...
Рейтинг: 0 / 0
28.12.2019, 11:27
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909415
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Как твой UDP-протокол поживает кстати? Как транспортный.
...
Рейтинг: 0 / 0
28.12.2019, 12:57
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909472
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Как твой UDP-протокол поживает кстати? Как транспортный.

Никак. Я что-то ленивый стал, использую его как для ослика морковку: надо сделать "это" и потом им займусь. Пока "это" делаю появляется надо сделать "то" и т.д. и т.п. В общем это идея-двигатель, помогает сделать "это" и "то", т.к. если заняться UDP-протоколом, то "это" и "то" останутся не сделанными.
...
Рейтинг: 0 / 0
28.12.2019, 18:52
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909564
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
Как твой UDP-протокол поживает кстати? Как транспортный.

Никак. Я что-то ленивый стал, использую его как для ослика морковку: надо сделать "это" и потом им займусь. Пока "это" делаю появляется надо сделать "то" и т.д. и т.п. В общем это идея-двигатель, помогает сделать "это" и "то", т.к. если заняться UDP-протоколом, то "это" и "то" останутся не сделанными.

Меня уже несколько лет интересует идея. Я о ней думаю рассеяно. В перерывах. Между проектами.
DynamicHashTable. Не в части обмена файлами. Это примитивизм и это уже реализовано в eMule/Torrent.
Мне нравится что ты можешь "спросить космос" - есть ли ключ и космос тебе ответит. Но я хотел наполнить
эту таблицу не файловым а другим смыслом. Например вычислительным. Или смыслом поиска записи
в некой распределённой БД.

Имеющиеся протоколы работают всего с 4 командами. PING, STORE, FINDNODE, FINDVALUE и на них можно
построить как файлообменную так и вычислительную сеть. Главное - правильно наполнить смыслом ключ.
И еще преимущество - что не нужна инфраструктура. Тоесть она конечно нужна. Но для ее работы
не нужны сложные централизованные серверы трекинга. И даже не нужен DNS. Нужны только хосты и открытые
порты UDP:4672 и TCP:4662 (только для файлообменных операций). И всё.

И самое интересное что эта вычислительная сеть практически неубиваема.

Я почему вспомнил про твой файлообменник? Мне показалось что у тебя есть наработки в датаграммном протоколе
и есть энтузиазм что-то поделать.

Но это уже в рамках тяпничных топиков на 2020 год.
...
Рейтинг: 0 / 0
29.12.2019, 13:08
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909578
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Тьфу. Не Dynamic.

Distributed Hash Table.
...
Рейтинг: 0 / 0
29.12.2019, 14:16
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909625
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
mayton

Да могли произойти совпадения на Berlin-1939-01-02 который случайно возник после редукции. Но разве это будет системным?
Настолько системным чтобы выборосить целую цепочку второй строки?

Вот Base64 тут вообще не подходит. И Base85. Вообще нужен алфавит. Допустим это альфа-нумерик в разном кейсе. Это 62
символа. Согласно статье Ошлина редукция обязана использовать именно этот алфавит.
Тоесть я должен взять хеш (допустим это 256-битное целое). И перевести его в систему
счисления по основанию 62. Это - циклические деления на 62 и расчет остатка по mod 62.

Само по себе деление это капец какая нудная операция для нагрузки (это краеугольный
камень криптографии). И хотя современные процы имеют MIMD (multiple instruction, multiple data)
это способность за 1 элементарную операцию и разделить и посчитать остаток но
всё таки хотелось-бы это дурацкое деленеи избежать.

Вариант - приводить к любому основанию кратному степени двойки?

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

Еще вариант - забить болт на точность и сделать допущение что например Base64 обладает
алфавитом с повторениями. Тоесть символы с кодами 62 и 63 мы заменим на символы кодов 0 и 1.
Гистограмма изменится.

Как это повлияет на добротность радужной таблицы - ХЗ. Скорее всего увеличит коллизии и повторы.
Но как увеличит? Как сильно?
...
Рейтинг: 0 / 0
29.12.2019, 18:13
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909652
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
И даже не нужен DNS. Нужны только хосты и открытые порты UDP:4672 и TCP:4662 (только для файлообменных операций). И всё.

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

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

Есть непонятные моменты с безопасностью, например чтобы Коля не мог сказать "я Вася", когда Вася сидит без инета.

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

Одна из моих целей была в уменьшении времени отклика, т.е. пакет идет не Вася-Сервер-Петя, а Вася-Петя. Между Васей и Петей 5 км, а до сервера 3000 км, тут уже встает вопрос времени отклика: 5 км это <1 мс, а 3000 это ~50 мс.

Уже придумал применение: замена тимвьюера на VNC. Для VNC что не хватает? Не хватает обратного соединения. Я это обратное соединение легко дам сервером за 3$ в месяц.

PS Скорее всего моя жаба заставит меня закончить, т.к. 3$ в месяц, это меньше чем 300$ в год за тимвьюер.
...
Рейтинг: 0 / 0
29.12.2019, 20:41
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909662
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Вот Base64 тут вообще не подходит. И Base85. Вообще нужен алфавит. Допустим это альфа-нумерик в разном кейсе. Это 62 символа. Согласно статье Ошлина редукция обязана использовать именно этот алфавит.

Не обязана, но он делает ширпотребный продукт (таблицы), поэтому ориентируется на то что массово используется.

В собственной реализации никто тебе не мешает использовать свой алфавит например в 137 символов.

mayton
Тоесть я должен взять хеш (допустим это 256-битное целое). И перевести его в систему
счисления по основанию 62. Это - циклические деления на 62 и расчет остатка по mod 62.

Само по себе деление это капец какая нудная операция для нагрузки (это краеугольный
камень криптографии).

ИМХО тут капец это посчитать хэш, остальное мелочи
...
Рейтинг: 0 / 0
29.12.2019, 21:11
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909664
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
У меня появилась мысль в чем полезен тот радужный проект: они изобрели ГПСЧ близкий к идеальному, их последовательность Ключ-Хэш-Редукция-Ключ2 ... это ГПСЧ для чисел на порядки больше чем 32768. Причем они ищут такую последовательность, которая будет максимально долго генерировать уникальные ключи. Пусть оно не быстро, но непредсказуемо.
...
Рейтинг: 0 / 0
29.12.2019, 21:17
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909708
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Dima T
Не всё. Не нужен DNS и не нужны открытые порты. Моя задумка в том что достаточно представиться "Я Вася, ищу Петю" одному из серверов и он сведет Васю с Петей и дальше они будут общаться напрямую, т.е. сервер поможет пробить NATы при необходимости. Поверх можно любые протоколы уровня приложения реализовывать.
Узнаю ViPNet ИнфоТеКС-а
...
Рейтинг: 0 / 0
30.12.2019, 07:05
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909826
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
Вот Base64 тут вообще не подходит. И Base85. Вообще нужен алфавит. Допустим это альфа-нумерик в разном кейсе. Это 62 символа. Согласно статье Ошлина редукция обязана использовать именно этот алфавит.

Не обязана, но он делает ширпотребный продукт (таблицы), поэтому ориентируется на то что массово используется.

В собственной реализации никто тебе не мешает использовать свой алфавит например в 137 символов.

mayton
Тоесть я должен взять хеш (допустим это 256-битное целое). И перевести его в систему
счисления по основанию 62. Это - циклические деления на 62 и расчет остатка по mod 62.

Само по себе деление это капец какая нудная операция для нагрузки (это краеугольный
камень криптографии).

ИМХО тут капец это посчитать хэш, остальное мелочи

Яж говорю. Собственный алфавит - это перенос из быстрой системы счислений (2ичной или 16 ричной) в небыструю.
137 символов. Офигеть основание. Мне надо сделать кучу операций деления чтоб получить число по основанию 137.

Хеш SHA1 в наше время посчитать уже - не-КАПЕЦ. Это одна из инструкций современного процессора.
https://en.wikipedia.org/wiki/Intel_SHA_extensions

Более того. Если посмотреть структурную схему одного раунда вычисления SHA1 то там в основном в наличии
быстрые операции такие как XOR/AND/SHL/SHR e.t.c. Вобщем ребята из NIST были неглупы и думали наперед
что если функция станет стандартом то она как минимум должна быть легко вычислима. Тоесть без этих
криптографических делений и остатков по модулю.
...
Рейтинг: 0 / 0
30.12.2019, 13:24
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909829
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
И даже не нужен DNS. Нужны только хосты и открытые порты UDP:4672 и TCP:4662 (только для файлообменных операций). И всё.

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

Я понял. Твой протокол включает в себя аутентичность. Для моего - пофиг. Ты когда ищешь инфу в интернете
(последние серии любимого сериала например) - тебе по большему счету все равно кто релизер. Заходишь
на рутрекер и клацаешь на линку. Ты - сам легко оценишь качество как только начнешь смотреть. Никаких
разумеется гарантий тут нету.
...
Рейтинг: 0 / 0
30.12.2019, 13:27
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909830
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
У меня появилась мысль в чем полезен тот радужный проект: они изобрели ГПСЧ близкий к идеальному, их последовательность Ключ-Хэш-Редукция-Ключ2 ... это ГПСЧ для чисел на порядки больше чем 32768. Причем они ищут такую последовательность, которая будет максимально долго генерировать уникальные ключи. Пусть оно не быстро, но непредсказуемо.

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

А ГПСЧ близкие к идеальному - это почти любые криптографические. Которые входят в библиотеки OpenSSL e.t.c.
...
Рейтинг: 0 / 0
30.12.2019, 13:29
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909955
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Яж говорю. Собственный алфавит - это перенос из быстрой системы счислений (2ичной или 16 ричной) в небыструю.
137 символов. Офигеть основание. Мне надо сделать кучу операций деления чтоб получить число по основанию 137.

Хеш SHA1 в наше время посчитать уже - не-КАПЕЦ. Это одна из инструкций современного процессора.
https://en.wikipedia.org/wiki/Intel_SHA_extensions

Более того. Если посмотреть структурную схему одного раунда вычисления SHA1 то там в основном в наличии
быстрые операции такие как XOR/AND/SHL/SHR e.t.c. Вобщем ребята из NIST были неглупы и думали наперед
что если функция станет стандартом то она как минимум должна быть легко вычислима. Тоесть без этих
криптографических делений и остатков по модулю.

Операций не куча, а ровно столько сколько разрядов, т.к. команда процессора DIV дает одновременно частное и остаток.

Можно увеличить основание до ближайшей степени 2. Тогда будет достаточно простых сдвигов.
Для 137 это до 256, т.е. писать как есть. Потери всего 1 байт на 10 символов, т.е. таблица займет на 10% больше места.

Инструкции для SHA1 и SHA256 появились относительно недавно (Intel 2016 год, AMD в 2017) поэтому таких процов относительно немного. Не нагуглил все ли свежие процы эти команды поддерживают.
Подозреваю это был шаг навстречу любителям майнинга.
...
Рейтинг: 0 / 0
30.12.2019, 16:35
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909966
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
Яж говорю. Собственный алфавит - это перенос из быстрой системы счислений (2ичной или 16 ричной) в небыструю.
137 символов. Офигеть основание. Мне надо сделать кучу операций деления чтоб получить число по основанию 137.

Хеш SHA1 в наше время посчитать уже - не-КАПЕЦ. Это одна из инструкций современного процессора.
https://en.wikipedia.org/wiki/Intel_SHA_extensions

Более того. Если посмотреть структурную схему одного раунда вычисления SHA1 то там в основном в наличии
быстрые операции такие как XOR/AND/SHL/SHR e.t.c. Вобщем ребята из NIST были неглупы и думали наперед
что если функция станет стандартом то она как минимум должна быть легко вычислима. Тоесть без этих
криптографических делений и остатков по модулю.

Операций не куча, а ровно столько сколько разрядов, т.к. команда процессора DIV дает одновременно частное и остаток.

Можно увеличить основание до ближайшей степени 2. Тогда будет достаточно простых сдвигов.
Для 137 это до 256, т.е. писать как есть. Потери всего 1 байт на 10 символов, т.е. таблица займет на 10% больше места.

Инструкции для SHA1 и SHA256 появились относительно недавно (Intel 2016 год, AMD в 2017) поэтому таких процов относительно немного. Не нагуглил все ли свежие процы эти команды поддерживают.
Подозреваю это был шаг навстречу любителям майнинга.

Нет. Они майнят на GPU (к примеру) а там степень параллелизма выше разв в 100. Выигрывают
за счет использования легких и туповатых АЛУ которых на графической карте много.

Или на специализированных устройствах которые уже есть в продаже.

На основном CPU уже лет 10 никто не майнит.
...
Рейтинг: 0 / 0
30.12.2019, 16:50
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909968
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T

Операций не куча, а ровно столько сколько разрядов

То что ты сказал - справедливо только для сложения и вычитания. Там - линейная сложность.

Умножение и деление двоичных чисел - имеет примерно от квадрата до икс в степени 1.2 complexity.
...
Рейтинг: 0 / 0
30.12.2019, 16:52
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39909984
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T

Для 137 это до 256, т.е. писать как есть. Потери всего 1 байт на 10 символов, т.е. таблица займет на 10% больше места.

Да я думаю не о потерях 10% а о корректности и о возможных false-positive срабатываниях.
Но если у меня будет алфавит из 129 символов то я точно буду брать расширять до байта.
Делить по модулю 129 мне точно не захочется. Да и медленно.
...
Рейтинг: 0 / 0
30.12.2019, 17:10
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910067
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Dima T

Операций не куча, а ровно столько сколько разрядов

То что ты сказал - справедливо только для сложения и вычитания. Там - линейная сложность.

Умножение и деление двоичных чисел - имеет примерно от квадрата до икс в степени 1.2 complexity.

Ну это же элементарно: для перевода числа в N-разрядность просто делим его на N: остаток это значение разряда, частное это все высшие разряды.

Например 137 переводим в HEX:
137/16 = 8 частное 9 остаток
8 / 16 = 0 частное 8 остаток
Итого 137 = 89h
...
Рейтинг: 0 / 0
30.12.2019, 20:51
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910069
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Dima T

Для 137 это до 256, т.е. писать как есть. Потери всего 1 байт на 10 символов, т.е. таблица займет на 10% больше места.

Да я думаю не о потерях 10% а о корректности и о возможных false-positive срабатываниях.
Но если у меня будет алфавит из 129 символов то я точно буду брать расширять до байта.
Делить по модулю 129 мне точно не захочется. Да и медленно.

Какие ложные срабатывания? Если формат хранения допускает избыточность, то на берегу проверяй соответствие значения формату, т.е. в расчеты должны идти только правильные значения, мусор надо убирать на входе.
...
Рейтинг: 0 / 0
30.12.2019, 20:58
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910122
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Делить не придется, надо будет складывать умножать. Мы же на вход получаем ключ в N-рязрядном представлении и его надо преобразовать в двоичное, т.е. в число, а для этого надо умножать, например 4 разряда:

Код: plaintext
key = ((Р 3 *N + Р 2 )*N + Р 1 )*N + Р 0
...
Рейтинг: 0 / 0
31.12.2019, 09:44
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910231
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Еще подумал, если умножать и складывать так
Код: plaintext
P 0  + P 1 *N + P 2 *N 2  + P 3 *N 3

где N X заранее посчитано, то такая конструкция параллелится процом во время выполнения и займет пару тактов, т.е. не тормоз.
...
Рейтинг: 0 / 0
31.12.2019, 16:49
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910240
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Dima T
mayton
пропущено...

Да я думаю не о потерях 10% а о корректности и о возможных false-positive срабатываниях.
Но если у меня будет алфавит из 129 символов то я точно буду брать расширять до байта.
Делить по модулю 129 мне точно не захочется. Да и медленно.

Какие ложные срабатывания? Если формат хранения допускает избыточность, то на берегу проверяй соответствие значения формату, т.е. в расчеты должны идти только правильные значения, мусор надо убирать на входе.

Давай рассуждать. Существуют ли такие редукты у которых разные хеши?
Ключ (к примеру) имеет длину до 12 символов. Это разумная длина.
Хеш SHA1 имеет длину 160 бит. Мощность множества хешей SHA1 во много
раз превышает мощность множества 12 символьных ключей.

Следовательно по принципу Дирихле существуют. Как 2 кролика в 1 клетке.
Или как следствие из того что хширование - это сурьективная функция.
И редуцирование - тоже сурьективная. Хотя если-бы мы увеличили длину
ключа до 20 символов тогда возможно и редукция стала-бы однозначной.
...
Рейтинг: 0 / 0
31.12.2019, 18:05
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910515
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Ты меня запутал. Похоже мы по-разному понимаем твой пост 22051757
Я так понимаю что речь была о выходе за границы алфавита, т.е. при алфавите в 137 разрядов, чтобы не делить, делаем редукцию в 256, в результате часть разрядов ключа окажется за пределами алфавита, поэтому тут надо изобретать какое-то преобразование к алфавиту ключа. Причем алфавит еще и рваный, т.к. это строка. Можно без деления обойтись, например таблицей.

mayton
Dima T
пропущено...

Какие ложные срабатывания? Если формат хранения допускает избыточность, то на берегу проверяй соответствие значения формату, т.е. в расчеты должны идти только правильные значения, мусор надо убирать на входе.

Давай рассуждать. Существуют ли такие редукты у которых разные хеши?

Ключ (к примеру) имеет длину до 12 символов. Это разумная длина.
Хеш SHA1 имеет длину 160 бит. Мощность множества хешей SHA1 во много
раз превышает мощность множества 12 символьных ключей.

Следовательно по принципу Дирихле существуют. Как 2 кролика в 1 клетке.
Или как следствие из того что хширование - это сурьективная функция.
И редуцирование - тоже сурьективная. Хотя если-бы мы увеличили длину
ключа до 20 символов тогда возможно и редукция стала-бы однозначной.

ИМХО Хэширование не гарантирует что два разных ключах будут иметь одинаковый хэш. Повышая мошность хэша мы снижаем вероятность возникновения такой ситуации, но не исключаем ее. То же с редукцией, обязательно будут разные хэши, которые дадут один и тот же ключ.
Собственно поэтому в статье автор честно предупредил что будут возникать зацикливание и вырождение цепочек.
...
Рейтинг: 0 / 0
03.01.2020, 08:21
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910521
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Как вариант алгоритма быстрой редукции 20 байт хэша в 12 байт алфавита:
1. При старте делаем таблицу 4 Кб (2 12 элементов) , где зациклен алфавит ключа: "1234567890123456....".
2. 12 раз от хэша взять по полтора байта (12 бит), использовать каждый как индекс массива, в итоге получаем разряд ключа.

Никаких делений не надо. Получение элемента по индексу массива легкая операция и плюсом проц запараллелит получение разных разрядов.

ИМХО одного байта для индекса недостаточно, т.к. тогда таблица будет 256 байт и значения будут неравномерно распределены, некоторые один раз, некоторые два, т.е. вероятность получения одних вдвое выше других. При 4 Кб (2 12 ) и алфавите 137 символов повторов будет 29-30, т.е. разброс 3%.
...
Рейтинг: 0 / 0
03.01.2020, 10:03
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910608
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Мне кажется что тема кешей перекликается с этой. Если заниматься глубокой оптимизацией самого
процесса генерации. Например.

1) Фаза №1. Для данного алфавита 8 alpha-numeric (к примеру) генерируем радужку с параметром t=10.
2) Получаем CSV-файл вида. В каждой строке - 10 редукций.

Код: sql
1.
2.
3.
key,reduct10
00000000,as9d8fl4
zzzzzzzz,0df43511


3) Некоторые key избыточны т.к. уже включены в цепочку редукций. Вопрос.
Каким образом их искать? В процессе генерации? Или после? Где их хранить?
База данных? Текстовый файл с сортировкой? Какие-то виды хеш-таблиц на диске?
Специализированные key-value библиотеки. Может в фазе построения - хранить
развёрнутую цепочку? Потом сворачивать после унификации?
...
Рейтинг: 0 / 0
03.01.2020, 16:01
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910614
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Тут маленькая проблема, одна цепочка может быть миллиарды ключей, сохранить в памяти целиком не получится. Думаю надо точечно хранить, например каждую миллионную точку
...
Рейтинг: 0 / 0
03.01.2020, 17:26
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910616
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Да. Так вот вопрос. Как оптимально искать?
...
Рейтинг: 0 / 0
03.01.2020, 17:35
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910644
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Да. Так вот вопрос. Как оптимально искать?

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

Собственно можно уже написать, но зачем? Уже написано.
...
Рейтинг: 0 / 0
03.01.2020, 19:35
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910645
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Вот в смежном топике один господин беспокоился об использовании (утилизации) кешей.

А я вижу в этой задаче краш-тест для кеша. Ну... помнишь по аналогии с CardRaytracer.
Я его специально подбирал чтоб только CPU грузил но память и диск не трогал.

А эта задача - будет шатать L1/L2/L3 с полной амплитудой.
...
Рейтинг: 0 / 0
03.01.2020, 19:41
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910648
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
А эта задача - будет шатать L1/L2/L3 с полной амплитудой.

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

PS Интересно, есть ли управление некэшированием, т.е. дать понять процу не кэшировать то, что заведомо известно в кэше искать не потребуется.
...
Рейтинг: 0 / 0
03.01.2020, 20:24
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910811
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Не знаю. С моей точки зрения уход в своп - это потеря контроля над ситуацией.

Кстати. Знаешь что в Linux (RHEL) существуют весьма скромные рекомендации по формуле
размера своп-диска? Там он не выходит в терабайты.

Смотри https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-swapspace

Для моей конфигурации (не RHEL но похожей), я поставил RAM=8G, Swap=8G.
...
Рейтинг: 0 / 0
04.01.2020, 21:42
| Ответить | Цитировать | Написать  
Тяпничный криптунЪ и редукция
    #39910818
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
mayton
Не знаю. С моей точки зрения уход в своп - это потеря контроля над ситуацией.

Верно, в данной задаче надо просчитывать чтобы не было свопа, а не непопадание в кэши.

mayton
Кстати. Знаешь что в Linux (RHEL) существуют весьма скромные рекомендации по формуле
размера своп-диска? Там он не выходит в терабайты.

Смотри https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/ch-swapspace

Для моей конфигурации (не RHEL но похожей), я поставил RAM=8G, Swap=8G.

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

Например если я воткнул 32 Гб оперативки в свой комп, то я ожидаю что свопа не будет вообще, но виндовс по дефолту займет 48 Гб под своп на моем SSD в 110 Гб (((

Я в виндовсе всегда принудительно выставляю минимальный размер свопа 16 Мб, максимальный - рекомендуемый 1.5 от размера памяти. Еще гибернайт выключаю, т.к. состояние памяти туда скидывается перед усыплением, но по факту он нафиг не нужен, т.к. все ширпотребные проги периодически сохраняют свое несохраненное состояние и при старте после сбоя предлагают к нему вернуться.
Реальный размер свопа у меня обычно 16 Мб, иногда до 1 Гб вырастает на компах где памяти 2-4 Гб.
...
Рейтинг: 0 / 0
04.01.2020, 22:11
| Ответить | Цитировать | Написать  
90 сообщений из 90, показаны все 4 страниц
  все  
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Тяпничный криптунЪ и редукция
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=16&tid=1339856]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 134ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 104ms
get tp. blocked users:
 2ms
others: 12ms
total:  303ms
созд. / загр.: 303ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]