To zakłada, że normalnie Keepass używa wszystkich rdzeni. Mi się wydaje, że używa tylko jednego.
Po co te liczby po przecinku? Tylko utrudniają odczytanie.
Po co szyfrowanie z pustym hasłem, zamiast zwykłego archiwum?
Postautor: pm7 » piątek, 30 grudnia 2016, 20:10
To zakłada, że normalnie Keepass używa wszystkich rdzeni. Mi się wydaje, że używa tylko jednego.
Po co te liczby po przecinku? Tylko utrudniają odczytanie.
Po co szyfrowanie z pustym hasłem, zamiast zwykłego archiwum?
pm7
Postautor: The Real McCoin » sobota, 31 grudnia 2016, 17:42
Zwiększyłem liczbę iteracji tak żeby procek liczył przez minutę i rzeczywiście teraz widzę, że na 8 procesorów logicznych tylko dwa chodzą na 100% (Windows 10 64-bitowy).
Wyedytuję później mój poradnik bo przy takich rozważaniach lepiej brać gorsze scenariusze, a przy jednym rdzeniu użytkownika czasy superkomputera się skrócą 4-krotnie.KeePass uses multithreading to compute the transformations (the master key is split up to two parts of 128 bits, which is the AES block size). On dual/multi core processors, the computation can be twice as fast as on a single core processor.
On Windows Vista and higher, KeePass can use Windows' CNG/BCrypt API for the key transformations, which is about 50% faster than the KeePass built-in key transformation code.
Żywcem wklejałem z kalkulatora jakby ktoś chciał sprawdzić wyniki poszczególnych etapów obliczeń.
Żeby bardziej zaciemnić. 7zip na końcu daje nagłówek z jawną unikodową nazwą pliku, długościami, itp. Pseudolosowa sieczka lepiej wygląda i komponuje się z resztą jpega, a 7zip ma opcję szyfrowania nagłówków.
The Real McCoin
Postautor: pm7 » sobota, 31 grudnia 2016, 17:49
Nie robiłem żadnych testów, tylko podałem, co pamiętałem, bo typowo takie zadania się nie dają rozkładać na wiele rdzeni. Pomijając oczywiście sytuacje gdy próbujemy złamał hasło i testujemy wiele rozwiązań na raz
To jest niezły argument, o ile przy pustym haśle następuje szyfrowanie. Sprawdzałeś?
Ukryj plik Keepass w najmniej znaczących bitach koloru
pm7
Postautor: powered » sobota, 31 grudnia 2016, 18:07
Te hostingi obrazków zniszczą każdą informację. Tam obrazki podlegają kompresji już w momencie wysyłania pliku.
powered
Postautor: The Real McCoin » sobota, 31 grudnia 2016, 18:34
Sprawdzałem w GUI i nie następuje, dlatego w poradniku musiałem użyć wiersza polecenia - wtedy szyfruje.
Tylko przed czy po kompresji jpg?
Dlatego pochwalmy hosting https://postimg.org za tolerancyjność i uszanowanie każdego bitu użytkownika.
The Real McCoin
Postautor: pm7 » sobota, 31 grudnia 2016, 20:14
Po. Nie pamiętam szczegółów, ale były gotowe programy, które były w stanie chować dane w jpg w ten sposób. Nie zaproponowałem tego dla steganografii, tylko żeby więcej hostingów zaakceptowało dodatkowe dane. Tak, jeżeli hosting ponownie kompresuje plik, stracimy dane, ale to można sprawdzić, a na pewno żaden nie odrzuci jpg.The Real McCoin pisze: Tylko przed czy po kompresji jpg?
Jak przed to w trakcie kompresji raczej znikną.
A po to już mamy tylko zakodowane bezstratnie skwantowane współczynniki DTC luminancji i chrominancji.
Pewnie można by użyć jakiegoś bardziej standardowego bloku jpeg albo nawet niestandardowego, który powinien zostać zignorowany, ale agresywne hostingi mogłyby go i tak odfiltrować... no i ze steganografią czy plausible deniability też nie miałoby to wiele wspólnego.
pm7
Postautor: The Real McCoin » wtorek, 17 stycznia 2017, 20:46
No i proszę... w zeszłym tygodniu wyszła nowa wersja KeePassa z algorytmem Argon2.
The Real McCoin
Postautor: akos » czwartek, 20 kwietnia 2017, 00:30
Kod: Zaznacz cały
Alamakotaakotma1234nogi
Kod: Zaznacz cały
0, 3, 5, 8, 13, 21
A l a m a k o t a a k o t m a 1 2 3 4 n o g i 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Kod: Zaznacz cały
Ala, ma, kot, aakot, ma1234no, gi
import itertools def get_nth_perm(perm_base, index): p = itertools.permutations(perm_base) i = 0 for pitem in p: if i == index: result = "" for part in pitem: result += part return result i += 1 return "invalid input" print get_nth_perm(["Ala", "ma", "kot", "aakot", "ma1234no", "gi"], 4)
Kod: Zaznacz cały
python perms.py
Kod: Zaznacz cały
Alamakotgiaakotma1234no
Kod: Zaznacz cały
13xqo2apvbvff9vQaN6iRLcTiPsxFNYhd3
5KHT6nVE4kQUPAQr9Fobt38z4DChofD8D5Mz5WXBExw3e5KCcwt
akos
Postautor: The Real McCoin » czwartek, 20 kwietnia 2017, 08:30
The Real McCoin
Postautor: rav3n_pl » czwartek, 20 kwietnia 2017, 10:23
rav3n_pl
Postautor: akos » czwartek, 20 kwietnia 2017, 13:28
akos
Postautor: rav3n_pl » czwartek, 20 kwietnia 2017, 14:48
rav3n_pl
akos
Postautor: rav3n_pl » czwartek, 20 kwietnia 2017, 16:53
rav3n_pl
Postautor: Fred Onizuka » czwartek, 20 kwietnia 2017, 21:32
Obawiam się, że już samo przeliczenie "ręczne" priv_key -> pub_key jest praktycznie niewykonalne.
Fred Onizuka
Postautor: akos » czwartek, 20 kwietnia 2017, 21:48
akos
Postautor: Bit-els » czwartek, 20 kwietnia 2017, 22:00
Bit-els
Postautor: Fred Onizuka » czwartek, 20 kwietnia 2017, 22:17
Ja to napisałem jako ciekawostkę, na wypadek, gdyby ktoś to próbował (np. dla zabawy) policzyć ręcznie
Fred Onizuka
Postautor: akos » sobota, 22 kwietnia 2017, 16:57
akos
Postautor: Bit-els » sobota, 22 kwietnia 2017, 17:22
Bit-els
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 5 gości
Polskie Forum Bitcoin skupia miłośników Bitcoina w Polsce. Tu możesz zadać pytania odnośnie Bitoina lub podyskutować na ciekawe tematy.
Treści na tym forum mają charakter wyłącznie informacyjno-edukacyjny, a posty są wyrazem osobistych poglądów ich autorów. Treśći na forum ani w całości ani w części nie stanowią "rekomendacji" w rozumieniu przepisów Rozporządzenia Ministra Finansów z dnia 19 października 2005 r. w sprawie informacji stanowiących rekomendacje dotyczące instrumentów finansowych, lub ich emitentów (Dz.U. z 2005 r. Nr 206, poz. 1715).