Szyfrowany pad, w Javascripcie.
https://github.com/cjdelisle/cryptpad
Świeży nius - repozytorium z GitHuba utworzone dopiero 20 godzin temu, ale kod jest z 19 października. Wygląda ciekawie zwłaszcza, że na liście pojawia się czasami "zakładanie pada".
2014-11-01 12:30 GMT+01:00 Marek Marecki marekjm@ozro.pw:
Szyfrowany pad, w Javascripcie.
https://github.com/cjdelisle/cryptpad
Świeży nius - repozytorium z GitHuba utworzone dopiero 20 godzin temu, ale kod jest z 19 października. Wygląda ciekawie zwłaszcza, że na liście pojawia się czasami "zakładanie pada".
"(…) Encryption carried out in your web browser protects the data from the server, the cloud and the NSA. (…)" Znów ktoś crypto w js robi? A jak gwarantują to, że serwer nie wyśle "trefnego" skryptu deszyfrującego?
On 11/01/2014 12:40 PM, Robert Sebastian Gerus wrote:
"(…) Encryption carried out in your web browser protects the data from the server, the cloud and the NSA. (…)" Znów ktoś crypto w js robi? A jak gwarantują to, że serwer nie wyśle "trefnego" skryptu deszyfrującego
Podejrzewam, że nie zagwarantują. Ale jeśli to JS to znaczy, że można pewnie na sztywno w przeglądarce uruchomić swoją lokalną (na-pewno-bezpieczną) wersję. To jest argument, który pojawia się (prawie) zawsze. Ale to tak jak z resztą softu: jak zagwarantujesz, że twój package maintainer nie dorzucił nic od siebie do kodu? Podobna sytuacja.
Correct me if I'm wrong.
BTW: da się ładować JS lokalnie? Powiedzmy, że instalujemy statycznie jQuery u siebie i to będzie wersja używana w skryptach? Skoro i tak wszystko ściąga klient to powinno chyba to być możliwe.
On Sat, Nov 01, 2014 at 01:03:14PM +0100, Marek Marecki wrote:
BTW: da się ładować JS lokalnie? Powiedzmy, że instalujemy statycznie jQuery u siebie i to będzie wersja używana w skryptach? Skoro i tak wszystko ściąga klient to powinno chyba to być możliwe.
Brzmi jak greasemonkey. Kwestia tylko samego odwoływania się. jquery każda strona wskazuje samodzielnie skąd ma być brany, i próba przechwycenia tego przez przeglądarkę i zaserwowanie wersji lokalnej może się dziwnie skończyć. Bo wersja niekompatybilna, bo developer pozmieniał coś w jquery, bo radośnie zupełnie inną bibliotekę umieścił w pliku o nazwie jquery.js
Natomiast tak jak pisałem, zadziałanie na zasadzie greasemonkey (o, mam stronę X, to puszczę na niej ustalony skrypt który jest zainstalowany lokalnie) jest w praktyce stosowane.
W dniu 1 listopada 2014 12:40 użytkownik Robert Sebastian Gerus < ar@bash.org.pl> napisał:
Znów ktoś crypto w js robi?
Ej, ale czemu nie? Ja wiem, że to mało wydajne i że język według wielu jest brzydki, ale to chyba nie jest na tyle istotne, co? W JS-ie da się zrobić tak samo skuteczne krypto jak wszędzie indziej.
2 lis 2014 02:46 "Kuba Niewiarowski" marsjaninzmarsa@gmail.com napisał(a):
W dniu 1 listopada 2014 12:40 użytkownik Robert Sebastian Gerus <
ar@bash.org.pl> napisał:
Znów ktoś crypto w js robi?
Ej, ale czemu nie? Ja wiem, że to mało wydajne i że język według wielu
jest brzydki, ale to chyba nie jest na tyle istotne, co? W JS-ie da się zrobić tak samo skuteczne krypto jak wszędzie indziej.
Patrz wyżej; Nie chodzi o wydajność, tylko bezpieczeństwo tego rozwiązania.
- P
W dniu 2 listopada 2014 03:32 użytkownik Patryk Jakuszew < patryk.jakuszew@gmail.com> napisał:
Patrz wyżej; Nie chodzi o wydajność, tylko bezpieczeństwo tego rozwiązania.
No jasne, ktoś Ci może podmienić w locie skrypt krypto. Ale Ty możesz trzymać swój lokalnie w Greasmonkey.
Z drugiej strony jak już hostujesz swój, to możesz równie dobrze odpalić binarkę. A argument o tym, że tak, ale tak możesz po prostu wejść na linka i mieć bezpieczeństwo, a lepiej mieć jakiekolwiek bezpieczeństwo, niż żadne zbijam tym, że lepsza świadomość braku bezpieczeństwa niż złudne poczucie bezpieczeństwa...
Z trzeciej strony pokażcie mi projekt szyfrowanego pada napisany w nie-jsie. Żeby móc odpalić binarkę trzeba najpierw mieć jakąś binarkę do odpalenia. :P
Niniejszym podsumowując powyższą dyskusję (samego ze sobą) stwierdzam, że to przedni pomysł i że jeśli połączyć to z hostowaniem js-a po swojej stronie (żeby mieć pewność że ktoś nie podmieni Ci go na serwerze / w locie na taki, który wysyła deszyfrowaną kopię na serwery Hydry) to i bezpieczny pomysł. Nie wiem jak z realizacją, nie znam się. :P
2014-11-02 2:44 GMT+01:00 Kuba Niewiarowski marsjaninzmarsa@gmail.com:
W dniu 1 listopada 2014 12:40 użytkownik Robert Sebastian Gerus ar@bash.org.pl napisał:
Znów ktoś crypto w js robi?
Ej, ale czemu nie? Ja wiem, że to mało wydajne i że język według wielu jest brzydki, ale to chyba nie jest na tyle istotne, co? W JS-ie da się zrobić tak samo skuteczne krypto jak wszędzie indziej.
Nie, nie da się. Ten język (a przynajmniej użyty w przeglądarce) nie zapewnia Tobie podstawowych funkcjonalności do poprawnego zaimplementowania kryptografii. http://matasano.com/articles/javascript-cryptography/ http://tonyarcieri.com/whats-wrong-with-webcrypto
W dniu 2 listopada 2014 06:17 użytkownik Robert Sebastian Gerus < ar@bash.org.pl> napisał:
Nie, nie da się. Ten język (a przynajmniej użyty w przeglądarce) nie zapewnia Tobie podstawowych funkcjonalności do poprawnego zaimplementowania kryptografii. http://matasano.com/articles/javascript-cryptography/ http://tonyarcieri.com/whats-wrong-with-webcrypto
Całość mógłbyś streścić w jednym, krótkim "problemy z uzyskaniem wysokiej jakości losowego szumu" (bo inne zarzuty już chyba zostały omówione wyżej, nie?). Niemniej artykuły fajne, dzięki, przynajmniej pierwszy (drugi poszedł do Pocketa) był przyjemnym odświeżeniem i częściowo uzupełnieniem prezentacji z ostatniego SBS'a[1], a przede wszystkim dyskusji o niej. :)
W każdym razie i losowość w browserowym dżejesie ma szanse na poprawę, bo JS uzyskuje dostęp do coraz większej liczby czynników zewnętrznych - są API do przechwytywania dźwięku, dostępu do akcelerometru, wreszcie można kazać użytkownikowi ruszać losowo myszą po ekranie[2], miejsc z którego można uzyskać przyzwoitej jakości szum pojawia się coraz więcej. Racja jednak, że dopóki nie pojawią się API dające dostęp do naprawdę niskopoziomowej pseudolosowości na poziomie jądra, to to wszystko będą półśrodki.
Ale czy serio te półśrodki nie są *close enough*? Serio to nie jest już wystarczająco trudne do złamania?
[1] inb4 źli-hakierzy-włamali-się-mojej-dziewczynie-do-laptopa-z-nieaktualizowanym-windowsem-bez-antywirusa-na-konferencji-o-bezpieczeństwie-jak-mogli-to-na-pewno-był-pehat-gate i zły-pehat-używał-wiresharka-gate. [2] <suchar>albo (przy założeniu, że użytkownik jest nietechniczny), skompilować vima do emscripten i kazać mu z niego wyjść</suchar>
2014-11-02 7:14 GMT+01:00 Kuba Niewiarowski marsjaninzmarsa@gmail.com:
W każdym razie i losowość w browserowym dżejesie ma szanse na poprawę, bo JS uzyskuje dostęp do coraz większej liczby czynników zewnętrznych - są API do przechwytywania dźwięku, dostępu do akcelerometru, wreszcie można kazać użytkownikowi ruszać losowo myszą po ekranie[2], miejsc z którego można uzyskać przyzwoitej jakości szum pojawia się coraz więcej. Racja jednak, że dopóki nie pojawią się API dające dostęp do naprawdę niskopoziomowej pseudolosowości na poziomie jądra, to to wszystko będą półśrodki.
Ale czy serio te półśrodki nie są close enough?
Półśrodki mają to do siebie, że da się ich źle użyć. A skoro czegoś da się źle użyć, to znaczy, że pół świata to zrobi źle (pragnę w tym miejscu zauważyć, że "desktopowych" bibliotek do kryptografii również to dotyczy…). Zbieranie entropii czy implementacja algorytmów kryptograficznych to nie jest problem który powinien być rozwiązywany w "aplikacjach końcowych".
I trochę zbaczając z tematu: przez zadowalanie się "close enough" czy "good enough" mamy kernelowe api które nie dotykają sprzętu i zawierają "maybe" i/lub "probably" w dokumentacji zachowania. Żeby daleko nie szukać, epoll(7).
Serio to nie jest już wystarczająco trudne do złamania?
ITT, gadanie o crypto w sytuacji kiedy nie ma nawet bezpiecznego systemu na którym można zrobić deployment, i jest niemalże 100% szansa że więcej niż jeden użytkownik mający dostęp do szyfrowanego datasetu będzie compromised, in b4 human factor.
Srsly guise, you should know better. Siła zabezpiczenia determinowana jest siłą adwersarza. Do casual crypto ten pad wystarczy.
Jeśli jako adekwatnego adwersarza traktujesz kogoś słabszego niż script kiddie, to tak. Ja tam bym się nie ograniczał do zabezpieczeń działających tylko na małe dzieci.
R.
W dniu 2014-11-02 08:19, Robert Sebastian Gerus pisze:
Zbieranie entropii czy implementacja algorytmów kryptograficznych to nie jest problem który powinien być rozwiązywany w "aplikacjach końcowych"
Brzmi jak zachęta do "lets make low level Crypto API for Firefox" :) W sumie skoro są jakieś BatteryAPI, MobileAPI i inne jestem-zajebistą-nazwą-API....
-- BoBsoN
-
Kuba Niewiarowski -
Marek Marecki -
Patryk Jakuszew -
Piotr Pies Ostrowski -
Radoslaw Szkodzinski -
Robert Partyka -
Robert Sebastian Gerus -
spin＠hackerspace.pl