GPG titkosított anyag on-the-fly olvasása + visszaírása jelszó bekérés nélkül

 ( log69 | 2009. január 11., vasárnap - 20:08 )

Üdv,

Régóta tervezem, hogy írok egy script-et vagy keresek valami progit, amivel azt tudnám csinálni, hogy ha bármilyen fájlt titkosítok GPG-vel, akkor az a progi ezt megnyitja és kéri a jelszavam, de a lényeg az lenne, hogy ha mentést nyomok a progiból és kilépek, akkor visszatitkosítódjon anélkül hogy újra berkérné a jelszót (amit már megnyitáshoz beírtam) és hogy fontos nyomokat hagyna.

Egyik ilyen anyagom lenne pl. egy OpenOffice Calc anyag. Habár OpenOffice tud titkosítva elmenteni, utánaolvasva nekem úgy tűnik, hogy az US törvények miatt gyengébb titkosítást használ. De nem csak OO-hoz kellene.

Arra gondoltam, hogy egy script-et indítva bekérem a jelszót cli-ből vagy GUI-ból, mindegy, majd letárolom egy változóba. Ha a progiból kiléptem, akkor meg visszatitkosítom a változó tartalma alapján, a titkosítatlan fájlt meg törlöm. Csak hát ez sok helyen megbukik biztonsági szempontból.. :)

A fájlrendszerem nem titkosított és nem is akarom titkosítani blokk szinten.

Ti milyen megoldást használtok olyan anyagok erősebb titkosítására, amit egy nap pl. 30-szor megnyittok?

Pár darab ilyen anyagom lenne, és jó lenne olyan megoldás, amit könnyen át lehet ültetni másik rendszerre.

Előre is köszi.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

ha ilyen surun hasznalod az adott doksit akkor miert kizaro ok a titkositott blokkeszkoz? az nemjarhato ut hogy csinalsz egy titkositott loopdev-et es azt csatolod be a filerendszerbe amikor kell?

udv Zoli

erre van szükséged,
Encrypted directory with EncFS howto.

Ennél kicsit hordozhatóbb megoldást keresnék ha van rá mód :)

truecrypt? win es lin alatt is mukodik

udv Zoli

+1

Csinálhatsz vele egy hordozható tárolót (1 fájlt tulajdonképpen), amit a nap elején felmountolsz, a végén meg le.

Ennél biztonságosabb szerintem nem nagyon kell. Ha mégis, akkor csinálsz a titkosított tárolón belül egy rejtett, titkosított tárolót :)

akár DVDre is kiírhatod a titkosított könyvtárat. később azt is simán lehet csatolni a jelszó ismeretében. igaz, csak gnu/linuxokon működik, de ma már vannak pendrive linuxdisztribek is. ha nagyon paranoiás vagy, nem használsz zárt forrású programot ilyen célra. létezik egyáltalán linux és windows rendszereken egyaránt használható valódi opensource megoldás fájltitkosításra ?

Egyébként tetszik az általad javasolt megoldás. Most tesztelgetem. Valószínűleg az lesz, hogy nap elején felcsatolom és ok. Az tetszik benne, hogy abszolút beállíthatóak a paraméterek (algo, bit nagyság stb.). Kár hogy a cryptkeeper lerántaná a teljes gnome desktop-ot.

Még a libpam-encfs -t akarom megnézni. Azt írja, hogy login-nal együtt lehet encfs-t mount-olni.

Truecrypt-et meg keresem, de nem találom a debian tárolókban. Mindenképpen olyan megoldást keresek, amely debian tárolóban elérhető.

A TrueCrypt oldalán a letöltéseknél van Ubuntuhoz csomag, a Debian tárolókban én sem találom. Vagy megpróbálod az Ubuntusat (annyiban talán nem tér el egy normál Debian csomagtól), vagy pedig marad a forrásból fordítás.

a truecrypt nem véletlenül nem szerepel, valójában nem tekinthető igazi opensource programnak. ráadásul a JAPhoz hasonlóan bűzlik a piszkosszolgálatok vietnami balzsamos szagától:)
a közzétett forráskód állandó fordításával vesződni pedig, imho felesleges időrablás.

Erről hol találtál infót?

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

infó többek között itt.
le kellene fordítani a truecrypt forráskódot azonos fordítón, a binary kiadással azonos opciókkal, majd össze kellene hasonlítani az eredményt, első körben. továbbá szurkolunk, ha nem nézzük át mi magunk a forrást, hogy a community ne úgy ellenőrizze a truecrypt forrást, mint a debianos opensslt.

Esetleg ugyan ilyen evidence jöhetne TrueCrypt-re is??
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

nyitott kérdések vannak a TCel kapcsolatban, eléggé sok. kik a fejlesztői? esetleg valamelyik országban valóban ilyen neveket adnak, mint syncon meg ennead? és vezetéknevek nélkül? hol van bejegyezve a TrueCrypt Foundation? miért volt eredetileg az Antarktiszra bejegyezve a truecrypt.org? azóta a Network Solutions rejtett domain regisztrációját veszik igénybe. a Truecrypt trademark miért egy magánszemély nevére van bejegyezve, egy prágai panelházba, egy olyan ember nevére aki nem lakik ott? miért alkalmaznak sajátos moderálási elveket a fórumaikon? nem szeretnek bizonyos témákat?
JózsikaBTnél ezek nem jelentenek komoly problémát, de egy bankba sosem kerülhetne be egy ilyen hátterű szoftver.

Mert paranoiásak. Nem kicsit. :)

http://www.truecrypt.org/contact

Address of TrueCrypt Foundation
résznél http://www.truecrypt.org/images/a-s.gif
ami jelenleg azt mondja, hogy

TrueCrypt Foundation
375 N. Stephanie St., Suite 1411
Henderson, NV 89014-8909
United States

szóval most a fagyos Antarktisz után egy nevadai étterem & salátabárba költözött a díszes kompánia. jó helyet találtak, ott van a közelben Las Vegas is, ahol általában nagy lóvék mozognak:)

Azert lassuk be, attol hogy a foldszinten van egy salatabar, attol az irodaepulet tobbi reszeben lehet komoly ceg is. Pl. a magyar IBM altal lakott irodakomplexumnak is van menzaja a foldszinten. Ugyanugy a HP-nek is, szoval ez azert annyira nem feltetlenul kizaro ok.

hát ez a salátabár nem emeletes irodaépületben van.

Wow! Ez igen. Gratulálok! Egy infó-félisten vagy.

+1 :D köszi ismét!

már kezdtem furcsálni, hogy ilyen hamar kiutaztál a kedvemért! =)
tiszta Casino utánérzés, biztos a hátsó raktárba szeletelik az algoritmusokat... ;)
az antarktiszos móka után biztos páran elküldték őket melegebb éghajlatra, így esett a választás Vegászra... =)

(google maps)

Opensource lehetőség: Linuxon LUKS, win-en FreeOTFE írja-olvassa. Arra kell ügyelni, hogy win-en is használható fs legyen a létrehozott LUKS loop-device-on. Persze nem feltétlenül kell loop-device, lehet akár egy teljes drive is, én loop-ként használtam sokat.

Úgy látom a luks hasonló az encfs-hez annyiban hogy azt is fel kellene csatolnom userspace-ben. Akkor már encfs is ok lenne végülis.

Részedre jó lehet, LUKS-FreeOTFE-t lin-win viszonylatban kényelmes használni. Win-en FreeOTFE-t nem is kell installni, van portable lehetőség is.

Köszi mindenkinek az ötleteket.

Végül úgy döntöttem, hogy mégis írok egy scriptet a problémámra, mivel olyan megoldásra van szükségem, ami csak addig bontja ki a fájlomat a titkosított formátumból, amíg szerkesztem (pl. pár percre). Mivel be van kapcsolva a gépem folyamatosan, ezért egy fizikális hozzáférés esetén a blokk illetve userspace filerendszeres titkosítások nem nyújtanak megoldást (legalábbis ezt jobban preferálom).

Ez azért jobb nekem, mert olyan környezetben is biztosítani szeretném magamnak, hogy kényelmesen sokszor megnyithassam a titkosított dokumentumaimat, ahol nem akarok kernel szintű beállításokat végezni. Az encfs-t is fel kellene csatolni minden alkalommal, szóval fél megoldás nekem arra, ahogy szeretném.

Az alábbi módon működik (gpg_writeback.sh nevet adtam neki, de jó lenne valami normális név, amire 1 év múlva is könnyen asszociálok, ötlet?):
--------------------------
script.sh command file

pl:
script.sh gedit jelszavaim.gpg
script.sh vi mylist.gpg

Zenity használatával (és a GUI változó 1-re állításával) grafikusan kéri be a jelszót.

-----------------------------------------------------------
#!/bin/bash

# THIS SCRIPT OPENS A GPG PROTECTED FILE FOR EDITING
# AND THEN ENCRYPTS BACK ITS CONTENT
# WITH THE SAME PASSWORD KEPT IN MEMORY
#
# USAGE: script command filename
# Needed packages: gnupg, zenity
#


GUI=1
TEMP=`mktemp /dev/shm/tmp.XXXXXX`
rm -f $TEMP

HASH=`sha1sum $0`
COMMAND=$1
FILE=$2


# Ensure to remove file even after unexpected terminations
trap "{ rm -f $TEMP; }" 0 1 2 5 15


if [ "$GUI" == "0" ]
then
	echo $HASH
	echo -n "Give me the password to use:"
	read -s PW
	echo
else
	PW=`zenity --entry --hide-text --title="Warning!" --text="Enter password:"`
	#PW=`zenity --entry --hide-text --title="Warning!" --text="$HASH, Enter password:"`
fi


# Decrypt the file
echo $PW | gpg -q --decrypt --passphrase-fd 0 -o $TEMP $FILE &> /dev/null

if [ $? -ne 0 ]
then
	rm -f $TEMP
	echo "Error during decrypting!"
	echo "Exiting."
	echo
	exit 1
else
	# Open file
	$COMMAND $TEMP 2> /dev/null

	# Safety backup and delete (gpg cannot overwrite without confirmation)
	mv $FILE $FILE.bak

	# Encrypt back
	echo $PW | gpg -qc --cipher-algo aes256 --passphrase-fd 0 \
		-o $FILE $TEMP &> /dev/null
fi

rm -f $TEMP
exit

-----------------------------------
Szerk.: közben változtattam 1-2 dolgot amit kihagytam.
Elvileg most már végleges. Néhány hülyeséget kihagytam.

Annyit megjegyeznék, hogy terminálból futtatva ok. Ha GUI alól futtatom (pl. ikonból), akkor a '$?' változó nem jó értéket ad vissza a gpg parancs lefutása után.

Erre esetleg ötleteket szívesen fogadnék.

Egyenlőre megadom az ikonnál, hogy terminálon belül indítsa.

Ezzel van egy kis baj.
Az mktemp 0600 jogokkal hozza létre a $TEMP filet, de azt letörlöd. A gpg-s viszont már a rendes umask-al jön létre, ami akár "world readable" is lehet. (Plusz akár még versenyhelyzetet is okozhat.)
Úgy kéne, hogy a törlést kiveszed az elejéről, és...
# Decrypt the file
echo $PW | gpg -q --decrypt --passphrase-fd 0 $FILE 1>$TEMP 2>/dev/null

Ez tényleg necces. Köszi az észrevételt és nagyon jó megoldás, kijavítottam és működik frankón :)

Végeztem még néhány változtatást, mint pl. a 'gpg' parancs teljes elérési úttal való használata stb. Mivel nem tudom szerkeszteni az előzőt, inkább bedobom mégegyszer:
-----------------------------------------------

#!/bin/bash

# THIS SCRIPT OPENS A GPG PROTECTED FILE FOR EDITING
# AND THEN ENCRYPTS BACK ITS CONTENT
# WITH THE SAME PASSWORD KEPT IN MEMORY
#
# USAGE: script command filename
# Needed packages: gnupg, zenity
#


GUI=1
TEMP=`mktemp /dev/shm/tmp.XXXXXX`
#rm -f $TEMP

HASH=`sha1sum $0`
COMMAND=$1
FILE=$2


# Ensure to remove file even after unexpected terminations
trap "{ rm -f $TEMP; }" 0 1 2 5 15


if [ "$GUI" == "0" ]
then
	echo $HASH
	echo -n "Give me the password to use:"
	read -s PW
	echo
else
	PW=`/usr/bin/zenity --entry --hide-text --title="Warning!" --text="Enter password:"`
	#PW=`/usr/bin/zenity --entry --hide-text --title="Warning!" --text="$HASH, Enter password:"`
fi


# Decrypt the file
#echo $PW | /usr/bin/gpg -q --decrypt --passphrase-fd 0 -o $TEMP $FILE &> /dev/null
echo $PW | /usr/bin/gpg -q --decrypt --passphrase-fd 0 $FILE 1>$TEMP 2>/dev/null

if [ $? -ne 0 ]
then
	rm -f $TEMP
	echo "Error during decrypting!"
	echo "Exiting."
	echo
	exit 1
else
	# Open file
	$COMMAND $TEMP 2> /dev/null

	# Safety backup and delete (gpg cannot overwrite without confirmation)
	mv $FILE $FILE.bak

	# Encrypt back
	echo $PW | /usr/bin/gpg -qc --cipher-algo aes256 --passphrase-fd 0 \
		-o $FILE $TEMP &> /dev/null

	chmod 600 $FILE
	PW=""
fi

rm -f $TEMP
exit

A vim tud vmi hasonlot crypt-tel (sot ha jol emlexem a vi is tud). A gpg-re meg megtanithato: http://vim.wikia.com/wiki/Vim_Gpg

Én gnumeric-hez meg más egyéb GUI-hoz akarom általánosságban használni igazából.

Pl ez:

http://gnupg.org/documentation/manuals/gnupg/Invoking-GPG_002dAGENT.html

Ez egy olyan daemon, amelynek szol a gui program, hogy kerje be a jelszot, a daemon bekeri es memoriaba eltarolja. Igy ha masik program ugyan azt a jelszot akarna kerni, akkor (mivel egyszer mar beirtad) masodszorra mar nem fogja megkerdezni.

Ez jó és kényelmes, ssh agent-et is használok. Jó megoldás, így ha többször nyitom meg, elég 1x megadnom. Habár nem ezzel volt a gondom, hanem az automatikus vissza titkosítással. :)