CRC error
pedro.markov at ml1.net
pedro.markov at ml1.net
Tue Jul 29 22:02:39 CEST 2014
On 07/29/2014 08:24 PM, pedro.markov at ml1.net wrote:
>
>
> On 07/29/2014 12:44 AM, flapflap wrote:
>> pedro.markov at ml1.net:
>>> You lost me with the "emails" stuff. ( i don't know what do they have to do
>>> in this topic)
>>>
>>> What I'm saying it is pretty easy, I'm bad with passwords, so i rather
>>> damage the key than remember a password.
>>>
>>> After the answers that people gave me, i improved so much my
>>> method, so this is a step by step.
>>>
>>> 1) Create keypair, and give some hint in the comment,
>>> so you don't forget it for exmple "what was your first girlfriends
>>> name?" or some silly
>>> question. (This is just for extra protection. You could even write the
>>> real password on the comment
>>> but be aware that this will be public on your public key)
>>>
>>> 2) Export the public and secure key.
>>> 3) Remove the keys from keyring, and re-import the public key.
>>> 4) Damage my private key. (Ex: inverse X and X line, Replace X and X
>>> characters, etc.)
>>> 5) Encrypt everything that you have to encrypt with the public key, you
>>> can even make it "Public".
>>>
>>> With this method, the day that you try to decrypt your data you wont
>>> need to remember a password.
>>>
>>> Also, if some Mallory gets in to your computer/server/whatever even if
>>> he gets a copy of your private key he won't
>>> be able to load it and try to use Brute force on it. He will need to
>>> repair the key before ( and good luck for that )
>> I'm pretty sure (though more knowledgeable people should comment on this
>> to clarify) that the changes/"damaging" you do (basically symmetric
>> operations via you keyboard) are much weaker than real cryptographic
>> operations.
>> GnuPG - if you specify a passphrase - stores the secret key encrypted.
>> If an attacker gets his/her hands on the secret key, s/he can do nothing
>> with it. So GnuPG already does what you need/want.
>> I understand that you don't like to remember the passphrase, but it's
>> less secure and convenient to manually fuddle with the keyfile (which is
>> also some kind of "passphrase", but much weaker than using GnuPG).
>>
>> Are you aware ofhttps://xkcd.com/936/ ?
>> It should be pretty easy to get to an easy-to-remember passphrase, just
>> think of some strange situation/image/... that's worth to remember.
>> E.g. "eleven camels climb on mt. everest for skiing"
>> (don't use that one of course as it's public now)
>>> Note. I think that for extra security i will generate the keys in a usb
>>> stick that i'll overwrite
>>> with zeros after corrupting the private key. This will prevent some
>>> smart mallory from using
>>> software as testdisk to recover deleted data.
>> Caution!
>> https://tails.boum.org/doc/encryption_and_privacy/secure_deletion/index.en.html#index2h1
>> Logically overwriting contents on a flash drive does not necessarily
>> overwrite the data on the physical medium. Flash drives use
>> wear-leveling algorithms that map the logical to physical addresses, to
>> limit the damages/wear-out due to writing the same physical locations
>> too often. So if you "overwrite" a logical address, your written data
>> actually goes to another physical cell and the old data is still there.
>> An attacker that just unsolders the flash ICs could read the entire
>> physical data, including what's not visible from the logical/software layer.
>>
>> ~flapflap
> This was very interesting, thanks for the information, i didn't know it!
>>
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140729/54b06b3d/attachment.html>
More information about the Gnupg-users
mailing list