6 risposte a questa discussione

[Signor D]

Novità da Google.

We are thrilled to announce the open source release of Cauliflower Vest, a solution that we’ve developed to automate enabling FileVault 2 and escrowing recovery tokens.

Come fa un amministratore di sistema a costringere tanti utenti a fare una salvaguardia cifrata dei loro dati? Google mette a disposizione Cauliflower Vest, che fa una copia sullo spazio Google Apps

FileVault 2 is a major, welcome addition to Mac OS X starting with Lion, as full disk encryption is an important part of securing your computer and its data. While the new FileVault 2 offering is very well suited to consumers, some enterprises may require additional features that are not provided out of the box. For example, FileVault 2 encryption is initiated voluntarily by users, lacks enforcement, and, by default, escrows recovery keys to Apple’s central server. It also relies on individual Apple IDs, which cannot be managed as a group.

Cauliflower Vest bridges these feature gaps by allowing enterprise Mac admins to:

• Forcibly enable FileVault 2 encryption.
• Automatically escrow recovery keys to a secure Google App Engine server.
• Securely access recovery keys so that volumes may be unlocked or reverted.

This release includes a GUI client to easily enable encryption, an escrow service, and a web UI for management. Also provided is a standalone CLI tool to automatically initiate encryption and generate a recovery key without requiring any user actions.

For more information, please visit the

Cauliflower Vest project page

and join the

discussion list

.

Ma dopo la perdita di credibilità che sta subendo Google ultimamente... vi fidate ancora a sufficienza di Google?

D

Messaggio modificato da Signor D, 18 maggio 2012 - 15:54

[volkov]

Ma io non so proprio cosa dire, nonostante la discutibile credibilità di google vi sono comunque dei casi in cui quando è criptato è criptato, e nemmeno se sei inaffidabile è tecnicamente possibile decifrarlo. E' chiaro che bisogna prestare attenzione alla complessità delle password usate. Inoltre (parlando di filevault 2) ci sono cose poco chiare. Secondo la mia logica, forse un po' primitiva, se il livello di crittazione è sceso da 256 a 128 bit (è giusto?) dovrebbe essersi indebolita la sicurezza. Che poi mi si venga a dire che è per una questione di usabilità, per me è molto più usabile SL con la crittazione a 256 che Lion a 128, comunque mi piacerebbe che qualcuno mi spiegasse come fa filevault 2 ad essere più sicuro (o ugualmente sicuro) di filevault 1, perché è una cosa che mi sfugge, visto che si abbassa il logaritmo.

[Pike]

Una googlata veloce...
Leggete qui, se l'inglese non vi infastidisce.
A mia personale opinione, non sono i bit che fanno la validità di una crittazione, quanto l'algoritmo.
E sinora, ancora non ho visto nulla di altrettanto efficace quanto Blowfish. Che non è usato da molti prodotti...

Leggendo qualche riga mi sono domandato... I backup di un volume crittato Filevault... Non sono crittati. O ho capito male io?

Messaggio modificato da Pike, 01 marzo 2012 - 13:51

[Vladimiro Paglianti]

A mia personale opinione, non sono i bit che fanno la validità di una crittazione, quanto l'algoritmo.
E sinora, ancora non ho visto nulla di altrettanto efficace quanto Blowfish. Che non è usato da molti prodotti...

Non è una tua personale opinione, ma la realtà dei fatti. Nello specifico, un algoritmo è sicuro se è lento. bcrypt (che utilizza blowfish) è considerato sicuro perchè è molto lento. sha nelle sue varianti è veloce, quindi non adatto per criptare una password, ma ottimo per fare dei checksum di file.

[volkov]

Una googlata veloce...
Leggete qui, se l'inglese non vi infastidisce.

in Italiano: http://it.wikipedia....eVault#Security
Comunque grazie ad entrambi, io infatti non ho affermato nulla, finalmente mi è chiara la storia... Grazie!

[Pike]

Non è una tua personale opinione, ma la realtà dei fatti. Nello specifico, un algoritmo è sicuro se è lento. bcrypt (che utilizza blowfish) è considerato sicuro perchè è molto lento. sha nelle sue varianti è veloce, quindi non adatto per criptare una password, ma ottimo per fare dei checksum di file.

Vladimiro perdonami ma non concordo in tutto.
Sul discorso di SHA, niente da dire; come MD5, è perfetto per valutare i checksum dei file.
Sul discorso lento=sicuro non mi trovi molto d'accordo. Non intendo mettere in dubbio la qualità di bcrypt, strumento che non conosco, ma un ragionamento di fondo... Ovvero che è la qualità dell'algoritmo a decretarne la sicurezza, e non la velocità di esecuzione.
A parte Gutmann che ha detto peste e corna di Blowfish (e secondo qualcuno più esperto di me, parecchio a sproposito), a pari potenza di calcolo è ancora più veloce di Rijndael (base di AES), Twofish e Serpent. DES era/è un macigno, ma era bucabile. Ed era un difetto dell'algoritmo, non della sua pesantezza, visto che era necessario aggiungere a volte schede "acceleratrici" di crittografia.
Talmente tanto bucabile che si parlava di triplicarlo (possibilmente con chiavi diverse) ad ogni passo...

in Italiano: http://it.wikipedia....eVault#Security
Comunque grazie ad entrambi, io infatti non ho affermato nulla, finalmente mi è chiara la storia... Grazie!

Volkov, ho citato quella in inglese in quanto aveva più dettagli tecnici sulla crittografia e come era implementata. La voce italiana non è tanto ricca.

Messaggio modificato da Pike, 01 marzo 2012 - 19:08

[volkov]

Non è una tua personale opinione, ma la realtà dei fatti. Nello specifico, un algoritmo è sicuro se è lento. bcrypt (che utilizza blowfish) è considerato sicuro perchè è molto lento. sha nelle sue varianti è veloce, quindi non adatto per criptare una password, ma ottimo per fare dei checksum di file.

Vladimiro perdonami ma non concordo in tutto.
Sul discorso di SHA, niente da dire; come MD5, è perfetto per valutare i checksum dei file.
Sul discorso lento=sicuro non mi trovi molto d'accordo. Non intendo mettere in dubbio la qualità di bcrypt, strumento che non conosco, ma un ragionamento di fondo... Ovvero che è la qualità dell'algoritmo a decretarne la sicurezza, e non la velocità di esecuzione.
A parte Gutmann che ha detto peste e corna di Blowfish (e secondo qualcuno più esperto di me, parecchio a sproposito), a pari potenza di calcolo è ancora più veloce di Rijndael (base di AES), Twofish e Serpent. DES era/è un macigno, ma era bucabile. Ed era un difetto dell'algoritmo, non della sua pesantezza, visto che era necessario aggiungere a volte schede "acceleratrici" di crittografia.
Talmente tanto bucabile che si parlava di triplicarlo (possibilmente con chiavi diverse) ad ogni passo...

in Italiano: http://it.wikipedia....eVault#Security
Comunque grazie ad entrambi, io infatti non ho affermato nulla, finalmente mi è chiara la storia... Grazie!

Volkov, ho citato quella in inglese in quanto aveva più dettagli tecnici sulla crittografia e come era implementata. La voce italiana non è tanto ricca.

Comunque è molto più leggero il processo di crittaggio, e i tempi di boot sono ottimi...