Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 12 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 9 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days, 6 hrs ago - more...
 |
|
2010-01-13
, 12:33
|
|
Administrator |
Posts: 1,036 |
Thanked: 2,019 times |
Joined on Sep 2009
@ Germany
|
#12
|
please have a look at this brainstorm http://talk.maemo.org/showthread.php?t=34563
__________________
useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, FAQ
useful links for newcomers: New members say hello, New users start here, Community subforum, Beginners' wiki page, Maemo5 101, FAQ
|
|
2010-01-13
, 12:44
|
|
Posts: 355 |
Thanked: 566 times |
Joined on Nov 2009
@ Redstone Canyon, Colorado
|
#13
|
Originally Posted by niekt0
You have something else going on unrelated then. I have been using the camera a lot in the past week (and in the past day) and it's going fine.
cryptsetup seems to work fine,
but with your kernel cameras are not working.
(mplayer show only green screen, build-in camera tool
report "failed to start")
|
|
2010-01-13
, 12:57
|
|
Posts: 1,224 |
Thanked: 1,763 times |
Joined on Jul 2007
|
#14
|
Overwriting the file with urandom is unnecessary and not really helpful. The underlying device uses wear leveling, so your data remains on the physical device. What yoou gain is that the data is not accessible by simply reading blocks of the mmc. But you gain this, no matter what you write, even all zeros. It is actually best to write all ones, as that requires no write to flash (only erase), so causes the least wear for the device. If the mmc controller is smart, it might even improve the chance that it will erase the actual nand sectors that contain the data you want to wipe.
In short - write /dev/zero or all ones, but don't use /dev/urandom, it is a waste of good entropy.
In short - write /dev/zero or all ones, but don't use /dev/urandom, it is a waste of good entropy.
| The Following User Says Thank You to Matan For This Useful Post: | ||
|
|
2010-01-13
, 13:02
|
|
Posts: 355 |
Thanked: 566 times |
Joined on Nov 2009
@ Redstone Canyon, Colorado
|
#15
|
Originally Posted by Matan
Nothing is being overwritten. We're not trying to erase anything here, this is before data has been written. The idea is to make it so it can't be seen how much data has been written to the filesystem. In other words, if you have a 100 meg filesystem with 99 megs of zeros, it's known there is 1 meg of data that needs to get cracked. If it's all filled with random/encrypted data, then the attacker doesn't know how much real data is there.
Overwriting the file with urandom is unnecessary and not really helpful.
| The Following User Says Thank You to jebba For This Useful Post: | ||
|
|
2010-05-17
, 13:50
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#16
|
Originally Posted by jebba
Could you please supply an argument for why an attacker would care about the size of data stored on the encrypted device? No matter the amount of data, it's still encrypted and if you picked good enough a passphrase and enough bits in the key, it will still take as much time to crack, no matter what the attacker knows.
Nothing is being overwritten. We're not trying to erase anything here, this is before data has been written. The idea is to make it so it can't be seen how much data has been written to the filesystem. In other words, if you have a 100 meg filesystem with 99 megs of zeros, it's known there is 1 meg of data that needs to get cracked. If it's all filled with random/encrypted data, then the attacker doesn't know how much real data is there.
Or have I completely misunderstood what one does when mounting and supplying the passphrase/key?
Last edited by Joorin; 2010-05-17 at 13:52. Reason: Typo
|
|
2010-05-17
, 14:55
|
|
Posts: 292 |
Thanked: 131 times |
Joined on Dec 2009
|
#17
|
Originally Posted by Joorin
First, there are situations where just knowing that something is there is equally as good (or as bad) as knowing what is there.
Could you please supply an argument for why an attacker would care about the size of data stored on the encrypted device? No matter the amount of data, it's still encrypted and if you picked good enough a passphrase and enough bits in the key, it will still take as much time to crack, no matter what the attacker knows.
Second, by analyzing the exact size it is possible to help to infer what kind of information is there.
Third, it is a lot easier to perform cryptanalysis when the exact size is known.
|
|
2010-05-17
, 15:01
|
|
Posts: 292 |
Thanked: 131 times |
Joined on Dec 2009
|
#18
|
@jebba
Did you try to store N900 personal data in the encrypted file? In other words, did you try to encrypt the partition that N900 stores personal information?
My idea is simple. I want my personal info (contacts, alarms, emails, pins, etc) to be unavailable if my device is stolen or lost.
Since there is nothing big deal (I just don't want my pictures, PINs and contacts being posted to the Internet or to credit card scammers), i could use a really fast but not so state of the art encryption...
Did you try to store N900 personal data in the encrypted file? In other words, did you try to encrypt the partition that N900 stores personal information?
My idea is simple. I want my personal info (contacts, alarms, emails, pins, etc) to be unavailable if my device is stolen or lost.
Since there is nothing big deal (I just don't want my pictures, PINs and contacts being posted to the Internet or to credit card scammers), i could use a really fast but not so state of the art encryption...
| The Following User Says Thank You to soeiro For This Useful Post: | ||
|
|
2010-05-17
, 15:10
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#19
|
Originally Posted by soeiro
So, you're thinking about "plausible deniability"? If you get pulled over in customs and have your phone device searched, you want to be able to deny that there's anything on it without them being able to find out?
First, there are situations where just knowing that something is there is equally as good (or as bad) as knowing what is there.
I understand the need in that situation, but it's not related to actually finding out what's stored on the device.
Second, by analyzing the exact size it is possible to help to infer what kind of information is there.
I'd say that it's very hard to find "the exact size" without actually reading the file system which requires decryption.
Third, it is a lot easier to perform cryptanalysis when the exact size is known.
|
|
2010-05-18
, 02:55
|
|
Posts: 355 |
Thanked: 566 times |
Joined on Nov 2009
@ Redstone Canyon, Colorado
|
#20
|
Originally Posted by soeiro
I haven't really used this on my N900 except a month ago or so and just that "it works". I do use something similar on my laptop for years for the reasons you describe above.
@jebba
Did you try to store N900 personal data in the encrypted file? In other words, did you try to encrypt the partition that N900 stores personal information?
My idea is simple. I want my personal info (contacts, alarms, emails, pins, etc) to be unavailable if my device is stolen or lost.
Since there is nothing big deal (I just don't want my pictures, PINs and contacts being posted to the Internet or to credit card scammers), i could use a really fast but not so state of the art encryption...
cryptsetup seems to work fine,
but with your kernel cameras are not working.
(mplayer show only green screen, build-in camera tool
report "failed to start")
n.