Norske Jottacloud erklærer seg snokefri

[tole]

Bruker Crashplan, greit nok, serverene der står i USA, men man kan ha en egenvalgt 448bit blowfish nøkkel, holder for meg til normalt bruk.

 

Blowfish er ikke lengre anbefalt, men som du sier bedre enn ingenting. Personlig ville jeg kun brukt asymmetrisk krypto, for selskapet trenger samme nøkkelen både for å kryptere og dekryptere, så i utgangspunktet har du gitt dem en stor tillit.

[JohndoeMAKT]

Er vel bare å tilby kryptert kobling mellom klient og server så kan du hente det ut i Sverige uten at noen andre får lese det. Alternativt kryptere det før du lagrer det, så spiller det ingen rolle om de har tilgang på serverene.

Som jeg prøvde å forklare tidligere i tråden vil ikke det beskytte deg mot stater med tilgang til CA-sertifikater som gjør at de kan sette opp man-in-the-middle-angrep som er usynlig for deg.

 

Vi har allerede mye krypteringsløsninger for bruk til data.

For kryptering av lokale disker som bare skal leses lokalt anbefalers dm-crypt som er block-level-encryption av en hel partisjon. Installerer du via f.eks Ubuntu Alternate/Server CD skal det være et valg om full-disk-kryptering som bruker dm-crypt. Bruker vanlig installasjons-CD får du valg om å kryptere hjemmemappa som bruker eCryptfs som krypterer på filsystemnivå, men resultatet er noe komplekst å synkronisere pga. måten dette låses opp ved boot.

 

For kryptering av innhold som skal synkroniseres mot skytjenester er det kryptering på filsystemnivå som anbefales.

EncFS og eCryptfs er to jeg har brukt til dette som skal fungere fint med hvilken som helst leverandør. EncFS er enklere i bruk, men om jeg husker rett er det noen teoretiske angrepsvinkler for å kunne lese ut originalt filnavn (men ikke innhold), mens eCryptfs er vanskeligere i bruk men uten filnavnproblemet. Jeg bruker noen ganger EncFS rett og slett fordi det er så enkelt. Hele prosessen med å lage en kryptert mappe tar 30 sekunder:

 

 

user@computer:~$ sudo aptitude install encfs
[sudo] password for user:
The following NEW packages will be installed:
encfs libboost-serialization1.49.0{a} libboost-system1.49.0{a} librlog5{a}
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 618 kB of archives. After unpacking 2,828 kB will be used.
Do you want to continue? [Y/n/?] y
Get: 1 http://archive.ubuntu.com/ubuntu/ raring/main libboost-serialization1.49.0 amd64 1.49.0-3.2ubuntu1 [189 kB]
Get: 2 http://archive.ubuntu.com/ubuntu/ raring/main libboost-system1.49.0 amd64 1.49.0-3.2ubuntu1 [14.7 kB]
Get: 3 http://archive.ubuntu.com/ubuntu/ raring/universe librlog5 amd64 1.4-2build1 [22.8 kB]
Get: 4 http://archive.ubuntu.com/ubuntu/ raring/universe encfs amd64 1.7.4-2.4build1 [391 kB]
Fetched 618 kB in 2s (242 kB/s)
Selecting previously unselected package libboost-serialization1.49.0.
(Reading database ... 281180 files and directories currently installed.)
Unpacking libboost-serialization1.49.0 (from .../libboost-serialization1.49.0_1.49.0-3.2ubuntu1_amd64.deb) ...
Selecting previously unselected package libboost-system1.49.0.
Unpacking libboost-system1.49.0 (from .../libboost-system1.49.0_1.49.0-3.2ubuntu1_amd64.deb) ...
Selecting previously unselected package librlog5.
Unpacking librlog5 (from .../librlog5_1.4-2build1_amd64.deb) ...
Selecting previously unselected package encfs.
Unpacking encfs (from .../encfs_1.7.4-2.4build1_amd64.deb) ...
Processing triggers for man-db ...
Setting up libboost-serialization1.49.0 (1.49.0-3.2ubuntu1) ...
Setting up libboost-system1.49.0 (1.49.0-3.2ubuntu1) ...
Setting up librlog5 (1.4-2build1) ...
Setting up encfs (1.7.4-2.4build1) ...
Processing triggers for libc-bin ...
ldconfig deferred processing now taking place

user@computer:~$ encfs ~/encrypted ~/unencrypted
The directory "/home/user/encrypted/" does not exist. Should it be created? (y,n) y
The directory "/home/user/unencrypted" does not exist. Should it be created? (y,n) y
Creating new encrypted volume.
Please choose from one of the following options:
enter "x" for expert configuration mode,
enter "p" for pre-configured paranoia mode,
anything else, or an empty line will select standard mode.
?> p
Paranoia configuration selected.
Configuration finished. The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/aes", version 3:0:2
Filename encoding: "nameio/block", version 3:0:1
Key Size: 256 bits
Block Size: 1024 bytes, including 8 byte MAC header
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File data IV is chained to filename IV.
File holes passed through to ciphertext.
-------------------------- WARNING --------------------------
The external initialization-vector chaining option has been
enabled. This option disables the use of hard links on the
filesystem. Without hard links, some programs may not work.
The programs 'mutt' and 'procmail' are known to fail. For
more information, please see the encfs mailing list.
If you would like to choose another configuration setting,
please press CTRL-C now to abort and start over.
Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism. However, the password can be changed
later using encfsctl.
New Encfs Password:
Verify Encfs Password:
user@computer:~$ echo 'test' > unencrypted/test.txt
user@computer:~$ tree unencrypted/
unencrypted/
└── test.txt
0 directories, 1 file
user@computer:~$ tree encrypted/
encrypted/
└── dFdQpxIIb6VBGeM0WKfVSb2m
0 directories, 1 file
user@computer:~$ cat unencrypted/test.txt
test
user@computer:~$ fusermount -u unencrypted
user@computer:~$ tree unencrypted/
unencrypted/
0 directories, 0 files
user@computer:~$ encfs ~/encrypted ~/unencrypted
EncFS Password:
user@computer:~$ tree unencrypted/
unencrypted/
└── test.txt
0 directories, 1 file

 

~/encrypted kan du da legge til at skal synkroniseres i f.eks Dropbox og ved hver endring i ~/unencrypted vil automatisk den krypterte endringen synkroniseres. Du skal også kunne montere den på flere maskiner samtidig med synkronisering uten at det er et problem.

 

 

 

På 90-tallet var jo PGP en nykommer. Hvor sikker er den i dag?

https://en.wikipedia...ecurity_quality

To the best of publicly available information, there is no known method which will allow a person or group to break PGP encryption by cryptographic or computational means.

[Spoki0]

 

Som jeg prøvde å forklare tidligere i tråden vil ikke det beskytte deg mot stater med tilgang til CA-sertifikater som gjør at de kan sette opp man-in-the-middle-angrep som er usynlig for deg.

 

 

Er alltid mulig å opprette en sikker kobling om en går inn for det, selv om man in the middle brukes for å lytte på samtalen. Eneste er dersom de som lytter har tilgang direkte til serveren og dens data...

 

Begge parter kan eksempelvis autentiseres mot hverandre før en nøkkel opprettes med eks diffie-hellman, og ikke opprette forbindelsen dersom autentiseringen ikke er gyldig.

[JohndoeMAKT]

Klart, jeg tenkte spesifikt mot Jottacloud. Jeg antar at de ikke støtter noe mer kreativt enn vanlig SSL med et CA-signert sertifikat.

[Turgon]

De (eller vi) kan garantere en snokefri tjeneste ved å kryptere dataene som går ut med en nøkkel Jottabyte ikke har. Dersom dette ikke skjer Så har Jottabyte tilgang til dataene, noe som betyr at andre også potensielt kan skaffe seg tilgang til dataene ved å gå via dem.

[Lucifer24]

Er vel bare å tilby kryptert kobling mellom klient og server så kan du hente det ut i Sverige uten at noen andre får lese det. Alternativt kryptere det før du lagrer det, så spiller det ingen rolle om de har tilgang på serverene.

Som jeg prøvde å forklare tidligere i tråden vil ikke det beskytte deg mot stater med tilgang til CA-sertifikater som gjør at de kan sette opp man-in-the-middle-angrep som er usynlig for deg.

Vi har allerede mye krypteringsløsninger for bruk til data.

For kryptering av lokale disker som bare skal leses lokalt anbefalers dm-crypt som er block-level-encryption av en hel partisjon. Installerer du via f.eks Ubuntu Alternate/Server CD skal det være et valg om full-disk-kryptering som bruker dm-crypt. Bruker vanlig installasjons-CD får du valg om å kryptere hjemmemappa som bruker eCryptfs som krypterer på filsystemnivå, men resultatet er noe komplekst å synkronisere pga. måten dette låses opp ved boot.For kryptering av innhold som skal synkroniseres mot skytjenester er det kryptering på filsystemnivå som anbefales.EncFS og eCryptfs er to jeg har brukt til dette som skal fungere fint med hvilken som helst leverandør. EncFS er enklere i bruk, men om jeg husker rett er det noen teoretiske angrepsvinkler for å kunne lese ut originalt filnavn (men ikke innhold), mens eCryptfs er vanskeligere i bruk men uten filnavnproblemet. Jeg bruker noen ganger EncFS rett og slett fordi det er så enkelt. Hele prosessen med å lage en kryptert mappe tar 30 sekunder

 

Ettersom det ser ut som du har greie på dette så må jeg bare spørre.

Hva syns du om Truecrypt til samme formål?

[JohndoeMAKT]

Ettersom det ser ut som du har greie på dette så må jeg bare spørre.

Hva syns du om Truecrypt til samme formål?

Jeg har brukt TC i snart ti år uten problemer og det bruker moderne og effektive algoritmer, alt er transportabelt og systemintegrasjonen er OK.

På Windows er det ganske klart min høyeste anbefaling.

 

I Linux er det derimot et par problemer som starter med at selv om koden er open source og trolig fri programvare er den det under en "Truecrypt license" som jeg antar ikke er kompatibel med GPL som gjør at den ikke er tilgjengelig i standard pakkebrønner som igjen gjør at du må manuelt laste ned, installere og oppdatere programvaren, noe som i GNU/Linux-verden er rett og slett feil. Dersom det i morgen kommer en kritisk sikkerhetsoppdatering kan det ta uker og måneder før jeg blir bevisst på det og oppdaterer manuelt. For GNU/Linux er det andre alternativer som gjør det samme, men er rett og slett mye mer integrert i systemet som dm-crypt og de to jeg nevner i en tidligere post. Jeg stoler rett og slett mer på at andre verktøy holder seg oppdatert, er mer integrert med oppdaterte kernel-moduler for både kryptering og filsystemet, samt har bedre støtte for de vanlige verktøyene for vedlikehold som fsck. Jeg har et "problem" med en TC-disk som roper om at den ikke har fått kjøre fsck på filsystemet på fire-fem år fordi fsck ønsker at jeg monterer filsystemet read-only, noe jeg fant ut at krever innsatsvilje som jeg ikke har i overflod.

[Lucifer24]

Takker for utfyllende svar. Da kan jeg trygt fortsette bruke TC skjønner jeg

[fenele]

Truecrypt er ikke fritt og open source;

 

"The TrueCrypt License has not been officially approved by the Open Source Initiative and is not considered "free" by several major Linux distributions"

src

 

Ingen vet om kildekoden inneholder backdoors eller ikke.

 

/tinfoilhat:

 

 

 

Reasonable paranoia

 

If relying on TrueCrypt encryption for life and death matters, it is worth noting that TrueCrypt (or any other software) is only as trustworthy as the people writing and reviewing the code. Also, when using distributed binaries instead of compiling from the source code, a user may be running code that was inserted during packaging and that is not available in the open source repository (possible backdoors, etc.).

 

The developers of TrueCrypt have been only anonymously referred to on the site as “The TrueCrypt Foundation” since 2010, though there are potentially good reasons related to privacy why they might have chosen to remain thus.

Samme src som over.

 

 

[JohndoeMAKT]

Det er årsak til at jeg skrev "trolig fri". Jeg tar sikkert feil, men om jeg husker rett er det tvetydighet og ordbruk som er problemet med lisensen, ikke nødvendigvis at den er åpent anti-fri.

 

Realiteten er uansett at programvaren ikke er i distro-pakkebrønner.

[anders iver]

Kryptering av hele disken er forresten støttet i den vanlige installeren til ubuntu i 13.04 (lvm også), så ingen grunn til å gå for alternate installer =)

[Twofish]

Dette er intressant for de som hevder at de er utenfor usas rekkevidde.

http://www.journalisten.no/node/40191