szarak
g/Security

http://istruecryptauditedyet.com/

przy okazji dyskusji stąd dodaję ciekawą stronkę podsumowującą postęp audytu truecrypta :)

#
zryty_beret

@szarak: Treściuj ;)

#
akerro

@szarak:

zbyt duży by łatwo stwierdzić co i kto do niego wprowadził. Ponadto wiele popularnych paczek binarnych pochodziło ze źródeł,

fake. Wszystkie paczki, których używa TC na linux są opensource. Zbudowałem TC ze źródeł z identycznymi wersjami programów z jakich zbudowano paczkę binarną tą do pobrania ze strony TC. Paczka po kompilacji miała tą samą sumę MD5. Identycznie zrobił redditowicz na windowsie, również otrzymał taką samą sumę MD5 Jak na stronie TC, więc jak jest backdoor to w mount albo xwdigets ;)

#
szarak

@zryty_beret: myślałem, że ogólnie temat już był na strimoidzie, ale ... coś nie mogę znaleźć ;(

#
szarak

@akerro: czyli sugerujesz, że hoax, tak jak mówił @zryty_beret? :)

W sumie to... przyjmuję do wiadomości, ale i tak rezultat tej sztucznej paniki jest pozytywny. Choćby jeśli miał tylko otworzyć oczy zbyt łatwowiernym fanboyom.

#
akerro

NSA, BOR, czy LPR, bez różnicy; ciężko polegać na bezpieczeństwie czegoś tylko za stwierdzenie "bo kod jest dostępny", podczas gdy nikt nie miał praktycznych możliwości go sprawdzić...

niesprawdzona została również obecna wersja dm-crypt, a encfs przeszedł testy dość negatywnie...

#
akerro

@akerro: czyli sugerujesz, że hoax, tak jak mówił @zryty_beret? :)

raczej przyjmuję do świadomości, że znajdziemy dziesiątki poważnych błędów w openssl niż w TC. jakoś kodu TC jest oceniona na pozytywną oceną, za audyt openssl ani Xorga nikt się przez lata nie chciał wziąć nawet przez to jak wygląda kod. kilkadziesiąt różnych formatów kodu, kilka tysięcy goto:

#
szarak

@akerro: dobrze wytknięte :) Dlatego właśnie uważam, że closed czy open, windows czy openbsd - często dajemy sobie tylko złudzenie bezpieczeństwa, zamiast je sprawdzić, lub przynajmniej rozeznać się w ryzyku i podjąć je świadomie.

P.S.: wołaj za pomocą @, bo mi uciekają Twoje odpowiedzi :)

#
akerro

@szarak: przejrzyj sobie to zrozum jakim śmieciem jest openssl. Caly świat na tym stoi, wszystkie google, facebooki, yahoo, emaile, strimoidy... gnuTLS jest rzadko spotykane raczej.

#
szarak

@akerro: piątek jest, nie dobijaj mnie :(:(:(

#
akerro

@szarak: używasz SSL na IRC? wystarczy, że jedna osoba na kanale nie używa SSLa i wszyscy mogą być łatwo podsłuchiwani ;) - zbiorowa odpowiedzialność, nikt nie jest odpowiedzialny.

#
grzegorz_brzeczyszczykiewicz

@akerro: Kod xorga to az taka kaszna?:D

#
zryty_beret

@grzegorz_brzeczyszczykiewicz: A jak myślisz? Dlaczego piszą Waylanda i piszą? Bo Xorg rozrósł się i tak zestarzał, że wygląda na dwusuwowy silnik w bolidzie F1.

#
akerro

@szarak: Rozumiesz coś z tych przesunięć bitowych? Zostały wywalone z kodu, a projekt nadal się buduje, więc były niepotrzebne w kodzie ;)

@grzegorz_brzeczyszczykiewicz: nie ma błędów w Xorgu. To raczej xorg jest błędem...

#
szarak

@akerro: jak na nie patrzę, to sam nie wiem, czy odpowiedzieć:
- Jestem za głupi
czy
- Jestem zbyt leniwy

#
akerro

@szarak: jak ja na nie patrzę to myślę... ktoś nie chciał, żebym to czytał.

#
gethiox

@akerro: Co do SSL na ircu - jasne, że w przypadku gdy jeden z użytkowników nie ma nawiązanego połączenia SSL to przesyłane i odbierane przez niego dane nie sa szyfrowane (cała komunikacja na jego kanałach), ale chyba nadal nie jesteśmy w stanie podsłuchać klientów połączonych poprzez SSL na poziomie ich transferu danych? Czy mam rozumieć, że w magiczny sposób jego nie SSLowa sesja niweluje moje szyfrowane połączenie? Z tego co się orientuję strukturą IRCa są centralne serwery - od cepa bez SSL do serwera leci plain-text, od serwera do mnie leci encrypted® enigma™ cryptology© algoritm³² connection∞.

#