PCUSER.2

09 Oct 1992 - 19 Feb 1994

Messages - zastita

zastita.213 dejanr,
U današnjoj "porciji" vesti sa BIX-a pročitaćete nekoliko vrlo zanimljivih tekstova o kriptografskoj zaštiti podataka. Pre svega o starim i novim tehnikama koje se koriste, a zatim i o raznim pokušajima FBI-ja i sličnih biroa da nateraju autore šifara da obezbede i "zadnja vrata" koja bi, pod određenim uslovima, omogućila policiji da počita svaku šifrovanu poruku. Pogledajte NOVOSTI/microb 4.205, 4.220, 4.227, 4.228, 4.229, 4.230 i 4.231.
zastita.214 dejanr,
David Kahn, autor slavne knjige "The Codebrakers", kaže da je u toku "rat" na polju kriptografije. Na istoj konferenciji, Ross Stapleton, analitičar CIA-e, kaže da je "država oduvek želela da kontroliše protok informacija; uz nove komunikacione alate, ona je u tome onemogućena. NOVOSTI/microb 4.503.
zastita.215 dejanr,
Evo jedne kratke a relativno kompletne priče o vrlinama i manama šifrovanja javnom šifrom, npr. pomoću programa PGP čiju smo novu verziju pre par dana dobili. ========== security/encryption #601, from rfm, 1888 chars, Tue Jun 22 12:49:04 1993 Comment to 600. Comment(s). ---------- Some observations on the last batch of messages: 1. Public key systems do not remove the need for secure key distribution. Sure, I can post my public key somewhere without fear of someone else decrypting messages encrypted with it, but how do you know that the public key you get off the bulletin board is really mine? A bad guy could replace my public key with his, intercept the messages, read them, re-encrypt with my public key, and forward them. The usual way to solve this is to have "trusted" key distributors, but that basically works out to having secure key distribution for the public key for the key distributor. (It's a slightly different kind of secure distribution -- must be secure against interception and injection, but not just reading.) 2. Even if factoring is NP complete (which I haven't heard) that would only mean that there's no quick algorithm for factoring *all* numbers. That doesn't prevent someone from constructing algorithms that quickly factor *some* numbers. Indeed, people have lots of these. A baddie could collect lots of these algorithms and run them on your public key. It might not work all the time but it might work sometime. The only way to be secure against this is to have a complete collection of all known quick algorithms and test your key pair with them before publishing the public key.... 3. If I know you've reused the same segment of your XOR key even just twice, all I have to do is XOR the two corresponding message segments and I have the key. If I don't know what segment was reused, if I have three texts encrypted all I have to do is XOR two of them at all offsets and decrypt the third with the result. This runs in O(n**3) time, which for reasonable size messages would be real quick on a fast machine... Rich
zastita.216 dejanr,
>Date: 25 Jun 93 13:48:26 GMT >From: Niels Ferguson <Niels.Ferguson@cwi.nl> >Newsgroups: alt.privacy,comp.society.privacy,alt.security, >comp.security.announce,comp.security.misc,sci.crypt >Subject: new Electronic Cash scheme: technical report available >Organization: Computer Privacy Digest >Approved: comp-privacy@pica.army.mil >Lines: 58 New electronic cash system: report available by FTP. --------------------------------------------------- Electronic cash is the equivalent of paper cash in an electronic form. It has all the same basic properties as ordinary cash: It carries value, can be used to pay other people without contacting any central organization and is completely anonymous. Recent work at the CWI has resulted in significantly improved protocols for electronic cash. The following CWI technical report is now available by FTP: Title: Single Term Off-Line Coins Author: Niels Ferguson Report: CS-R9318 Site: ftp.cwi.nl directory:/pub/CWIreports/AA file: CS-R9318.ps.Z (compressed PostScript file) Abstract -------- We present a new construction for off-line electronic coins that is both far more efficient and much simpler than previous systems. Instead of using many terms, each for a single bit of the challenge, our system uses a single term for a large number of possible challenges. The withdrawal protocol does not use a cut-and-choose methodology as with earlier systems, but uses a direct construction. This report is slightly more extensive than the version that appeared in the pre-proceedings of EuroCrypt '93. If you are interested in this report, you might also be interested in a report by my colleague Stefan Brands entitled "An Efficient Off-line Electronic Cash System based on the Representation Problem". It can be found under the name "CS-R9323.ps.Z" in the same directory. Note: Followup set to sci.crypt Niels
zastita.217 prvul, -> #216, dejanr
ŮTitle: Single Term Off-Line Coins ŮAuthor: Niels Ferguson ŮReport: CS-R9318 ŮSite: ftp.cwi.nl Ůdirectory:/pub/CWIreports/AA Ůfile: CS-R9318.ps.Z (compressed PostScript file) Ů▄▄ Ovo izgleda jako interesantno... ako fajl nije odvratno dugačak, hajde neka ga neka dobra duša skine :)
zastita.218 dejanr,
Novell "izaziva" vlasti po pitanju šifrovanja. NOVOSTI/microb 4.835 i 4.863.
zastita.219 dejanr,
========== security/encryption #616, from gnikoloff, 1798 chars, Sun Jul 25 22:07:12 1993 Comment(s). ---------- TITLE: possible new encryption method. IMHO, this may be a possible new encryption method. Then again, it may well not be. There exist infinitely many large primes whose decimal expansion of their reciprocals has billions of digits before repeating. For example, there are primes less than 2^32 which have a couple of billion digits in their decimal expansion. A formula for determining suitable prime candidates was mentioned recently in an issue of New Scientist. In this letter, the author mentioned the use of such primes in connection with the generation of pseudo-random sequences, and indicated that the decimal (or binary) expansion of the reciprocal when used as a pseudo-random sequence, passed the usual tests for randomness (see Knuth vol 2). I propose (if, as I said, this has not already been mentioned in the literature), that a possible use of this property is to encrypt a message. Simply (a) choose a suitable prime as a key (say 20-50 digits, or more). (b) commence calculating the reciprocal, and XOR each byte with the message successively. Decryption is obviously the identical process. The advantage, if this method is secure, is that calculating the reciprocal is quite quick and only as many bytes of the binary expansion are needed as there are message bytes (we throw away the leading zeroes of the reciprocal i.e normalize it, of course). I would surmise that the only attack on the encrypted code could be made by trying all possible candidates for a key, but there are infinitely many suitable primes, especially at a key length of 50 digits or more. If this IS a new method of encryption (which I doubt, but who knows), then with the publication of this message, I place this algorithm in the public domain, with no restrictions. I do not like software patents. ========== security/encryption #617, from roedy, 117 chars, Sun Jul 25 23:14:17 1993 Comment to 616. ---------- I wonder how long that would take to compute, compared with some of the other transformations currently in use. -30- ========== security/encryption #618, from charliemerritt, 314 chars, Mon Jul 26 21:11:05 1993 Comment to 616. Comment(s). More refs to 616. ---------- I passed your inverse prime idea to Phillip Zimmermann (PGP). His response: Charlie, if the attacker can discover the first 100 bytes of plaintext, he can derive the 1st 100 bytes of the recipricol, and then invert it to compute the exact prime, and reinvert that to derive the rest of the key stream. Cracked! ========== security/encryption #619, from hshubs, 4 chars, Mon Jul 26 23:01:29 1993 Comment to 618. ---------- Ow. ========== security/encryption #620, from eks, 1008 chars, Tue Jul 27 01:05:05 1993 Comment to 616. Comment(s). ---------- I've already seen the comments about this inverse-prime algorithm's (lack of) usefulness. But a tangential point needs to be made: > ... I place this algorithm in the public > domain, with no restrictions. I do not like software patents. Um, you've just given away all claim to the algorithm. Now I can patent it! Isn't that what happened with RSA? I don't recall having seen the names Rivest, Shamir, or Adelman associated with that company (whose name I forget) that's been much flamed here of late for harrassing RSA users. Seems to me that what you'd have to do is the equivalent in the patent domain of the FSF's "copyleft", ie. patent the algorithm, then explicitly let anyone use it at no charge, with appropriate restrictions. I suspect it would cost a lot of money to do this, unfortunately -- legal fees, etc. -- to get the patent in the first place. Not nearly as easy as simply saying "Copyright (C) 1993 by me. Abides by the terms of the GNU General Public Licence.", more's the pity. ========== security/encryption #621, from peabo, 419 chars, Tue Jul 27 01:47:31 1993 Comment to 620. Comment(s). More refs to 620. ---------- Well, patent lawyers may argue about it, but you can't patent something which is "prior art". So, if someone describes it adequately and releases it to the public domain, it is not patentable. The hitch is "describes it adequately", which may require actually building the thing, not just saying "this is how you would do it" (i.e., reducing it to practice, as would be required of a real patent application). peter ========== security/encryption #622, from kparker, 268 chars, Tue Jul 27 02:20:32 1993 Comment to 621. Comment(s). More refs to 621. ---------- > actually building the thing So how do you *actually build* an algorithm, a thing which is, by definition, an abstraction description? Don't tell me 'a few lines of code...', that would only be an *implementation* of the algorithm, not the algorithm itself. -Kirk ========== security/encryption #623, from charliemerritt, 209 chars, Tue Jul 27 19:55:14 19 93 Comment to 620. More refs to 620. ---------- The company you refer to is PKP aka Public Key Partners. The partners are R,S & A plus a few others. You will also see RSADSI that is R,S & A Data Security Inc. PKP does the "marketing", positive & negative. ========== security/encryption #624, from rfm, 635 chars, Tue Jul 27 22:49:37 1993 Comment to 622. More refs to 622. ---------- To count as prior art, you just have to present the idea in a way such that "one practiced in the art" (in this case, any competent programmer) could implement it without needing to invent anything. So a few lines of code, if understandable, would work. Flowcharts are traditional. BTW, Gnu zealots often trot out this argument about not putting things in the public domain because "software hoarders" might sieze them and claim copyright. This has, as far as I know, never happened. There are a few cases where the original author has put out a new version and claimed copyright on it, but the "copyleft" would not prevent that. ========== security/encryption #625, from john.r.strohm, 412 chars, Tue Jul 27 23:11:31 1993 Comment to 620. ---------- No. Once an invention is placed in the public domain, it is there forever and cannot be appropriated. You may, if you wish, file your patent claim. You might even get a patent issued. When and if you sue someone for infringement, he is going to produce a dated copy of that release to P.D., and your patent is going to vanish in an even smaller puff of orange smoke than Cinderella's coach made at midnight. ========== security/encryption #626, from john.r.strohm, 383 chars, Tue Jul 27 23:13:38 1993 Comment to 621. Comment(s). ---------- No, it is not necessary to "reduce something to practice" in order to patent it. Look at the patent on the single-chip microcomputer that currently has a whole bunch of the big boys's legal departments furious. The guy described how such a device might be built, using technology that was available at the time. Bit-serial ALU, for one thing, because of the limits on gates/chip. ========== security/encryption #627, from peabo, 196 chars, Wed Jul 28 01:22:49 1993 Comment to 622. ---------- How about a mathematical verification? In the case a hand, no math was done to demonstrate the strength of the algorithm (and as Phil Zimmerman pointed out, there was a significant flaw). peter ========== security/encryption #628, from gnikoloff, 1781 chars, Wed Jul 28 02:46:25 1993 Comment(s). ---------- I do not think the attack is quite that easy. You do not know the magnitude of the prime number as the leading zeroes in the reciprocal were not included in the encryption. They were discarded to normalise the reciprocal. You will therefore always get a value which is out by 20-50 digits, and you don't know how many there were. Assuming that you knew 100 bytes of the plaintext, you will get back 100 bytes of the reciprocal. So now you take the reciprocal of that. You have not cracked it. All the remaining digits 101 onwards of your approximation to the reciprocal are zeroes!. Tangentially, an interesting point arose with regard to the use of the term 'in the public domain'. To make my intention quite clear:- IF this is an original idea (I do not know or assert that this is so) then, without condition, I make this idea freely available with the express intention that no-one shall patent any algorithm based on this idea, and that publication of this notice shall constitute 'prior art' as understood in patent law. I would loathe the thought of someone being able to exploit ideas in the public domain by patenting them. I'd be very keen to know if this algorithm is, indeed, secure, but I lack the math to do it. I intend to implement the algorithm just out of curiosity; this requires extended-precision arithmetic but Knuth vol.2 has some code for this including specific and fast cases for reciprocals. This method looks attractive because, superficially at least, it is very computationally quick to encrypt/decrypt messages Of course, this could be a flaw as many keys can be tried relatively cheaply. Still, as many people have pointed out, compressing your message prior to encryption complicates matters for the decryptor and simple permutations even more so. ========== security/encryption #629, from peabo, 336 chars, Wed Jul 28 13:31:21 1993 Comment to 628. ---------- If it's just leading zeros missing from the reciprocal, you can keep prefixing zeros one at a time until you get a plausible reciprocal. Would this be hundreds of tries? Doesn't sound too hard to do. If it's millions, then there is lots more crunching, though still not very much compared to trying to break a DES (my guess!) peter ========== security/encryption #630, from rfm, 881 chars, Wed Jul 28 13:56:33 1993 Comment to 626. Comment(s). ---------- "reduce to practice" doesn't mean you have to actually build one, you just have to describe in sufficient detail that building one would not be a creative act. This guy's microprocessor patent is an interesting case because the patent office bounced it back a few times saying he hadn't sufficiently reduced it to practice -- essentially he had said "I got this idea -- put a computer on a chip!" without saying *how*. Eventually he added enough detail (like the bit-serial ALU stuff) to convince the PO that it was "reduced to practice" [even though he never really built one] and they issued the patent, effectively "backdated" to his first application. However, during this long process, technology was progressing; it's not clear to me how one could determine that he knew the stuff he was adding back at the start. I believe TI is challenging the patent on this basis... ========== security/encryption #631, from gnikoloff, 2254 chars, Wed Jul 28 17:40:27 1993 ---------- TITLE: further thoughts on reciprocals I have been thinking about possible weaknesses with this idea, and accordingly, I propose a couple of small changes. 1. Normalise the reciprocal and then throw away the first n digits of it where n is the length of the prime. This gets you well into the pseudo-random sequence without any clues as to the most significant digits. I cannot see how anyone would then be able to find the original number, it would be like being given a random piece of the digit sequence from pi and being able to deduce that it was part of pi (I know that particular problem is solvable with brute force, but what if I gave you a digit sequence and said that it was from some real number, perhaps e or gamma or something, and asked you to determine which real number it was). 2. Because this is a pseudo-random sequence, it will contain runs of repeating digits. To avoid exposing the plain-text, I propose throwing away any repeated digits, thus, a sequence 1655436 would become 165436. According to the letter in New Scientist, suitable numbers are given by the formula q=40k+7 or q=40k+19 or q=40k-17 where (q-1)/2 is prime and q is prime. a small example is 999998383,the reciprocal of which has a digit sequence with a repeat length of nearly 2 billion. The first part of the reciprocal is .00000000100000161700261469 and by modification 1 above, we would throw away all the leading zeroes, and then a further 9 digits, meaning that we would have 700261469 as our starting digits. Furthermore, we'd throw away the second zero so the first digits are 70261469.... Now, can anyone see how this might be cracked? By the way, this looks like one example of a whole series of encryption method based around pseudo-random sequences. For example, one could use a linear congruential generator to generate the encryption sequence. The challenge would then be that given the plaintext, and thus the encryption sequence, deduce the parameters of the generator that produced it. This is necessary to extrapolate the next value that would be output. I think this is a trapdoor function, but Knuth doesn't discuss this area and I don't know too much about cryptography, presumably this is a well-known problem. ========== security/encryption #632, from john.r.strohm, 316 chars, Wed Jul 28 22:36:03 199 3 Comment to 630. ---------- Texas Instruments holds a similar patent, based on calculator technology, that dates from the first single-chip calculator. This other guy's patent would predate the TI patent, and invalidate it. Last I heard, TI had filed a VERY specialized technical challenge to the patent, and the wheels are quietly grinding. ========== security/encryption #633, from rfm, 398 chars, Thu Jul 29 20:10:46 1993 Comment to 631. Comment(s). ---------- I was never a number theorist, but it sure seems to me that if you give one of those number theory folks what amounts to an indefinite number of equations N MOD 10**K = a N MOD 10**K+1 = b N MOD 10**N+2 = c it wouldn't take long for them to figure out N. Since you have Knuth out, read about the Chinese Remainder Theorem... I don't recall it exactly but I think it talks about things like this. ========== security/encryption #634, from hshubs, 119 chars, Thu Jul 29 20:24:09 1993 Comment to 633. Comment(s). ---------- Seems to me that if you perform his algorithm in binary, you always get the same answer: 1010101010101010101010101... ========== security/encryption #635, from charliemerritt, 67 chars, Thu Jul 29 23:01:50 1993 Comment to 634. ---------- Yes, you would using the no digit repeat rule of obfuscation(sp?).
zastita.220 zddb,
Zna li neko da li postoji novija verzija programa COPYIIPC? Naime, verzija koju ja imam ne može da radi sa HD disketama.
zastita.221 dikla, -> #220, zddb
> Zna li neko da li postoji novija verzija programa COPYIIPC? Naime, > verzija koju ja imam ne moze da radi sa HD disketama. Moja, koliko se secam radi, ali nemam pojma koja je ver. !
zastita.222 dejanr,
Ako neko namerava da februara sledeće godine trkne na simpozijum o sigurnosti mreža i distribuiranih sistema, evo programa tog skupa. Održava se u San Dijegu. simpoz.zip
zastita.223 dejanr,
========== security/encryption #658, from peace, 3094 chars, Wed Nov 3 23:46:53 1993 ---------- TITLE: fwd message on ViaCrypt PGP Forwarded Message -------------- ViaCrypt, Inc., will begin shipping ViaCrypt PGP on Monday, 1 November 1993. ViaCrypt PGP is a commercial public-key encryption package which is based on, and virtually identical with, the freeware program known as PGP, or `Pretty Good Privacy.' (The source code is in fact identical to that of the freeware version 2.3A of PGP, with the exception of the RSA encryption module, which is one ViaCrypt developed in-house after acquiring a license for the algorithm from PKPartners. In addition, ViaCrypt incorporates a few quite minor bug fixes. The private-key crypto algorithm is IDEA, as in freeware PGP, for which ViaCrypt has obtained a license from Ascom-Tech AG of Zurich.) Output is byte-for-byte identical with that of freeware PGP 2.3A, except that the `Version' header atop the message body reads "Version: 2.4" instead of "Version: 2.3A". Keys, signature certificates, binary or ASCII-armored ciphertexts, produced by one program will be identical to, and transparently handled by, the other. ViaCrypt PGP will (for now) be available in the US and Canada only, pending revision of the ITAR statutes. The ViaCrypt PGP package will include program disks (executables only, no source code), manual, and individual user license. The current release will be for the MS-DOS OS only; ViaCrypt plans to ship a UNIX version soon. Cost of a single user package is US$100. (For purchases of 20 units or more, a substantial discount -- price drops to about US$41 per user -- is available.) To purchase ViaCrypt PGP or to find out more about it, you can contact them as follows: ViaCrypt 2104 W. Peoria Ave. Phoenix, AZ 85029 USA 602-944-0773 (Voice) 602-943-2601 (FAX) 70304.41@compuserve.com (Netmail) I have no connection with ViaCrypt, commercial or otherwise. Indeed, I disagree in principle with the concept of algorithm patents. I think, though, that the net, and particularly users and admirers of the PGP PK cryptosystem, deserve to hear about this. Because ViaCrypt paid PKP for a license, users of ViaCrypt can now utilize PGP with absolutely no fear of prosecution for patent infringement. Since ViaCrypt will ship only in USA/Canada, ITAR violations also need not be feared. This will enable the PGP PK cryptosystem, with its decentralized distributed-trust key management, to achieve crucial penetration into the corporate marketplace. This will speed its acceptance as the de facto PK standard, as opposed to other centralized or key-escrow schemes, like RIPEM or Clipper. And ViaCrypt will enable U.S. users to communicate completely legally with non- U.S. users of PGP 2.3A. In short, even though I oppose algorithm & software patents, in purely practical and political terms I think this is A Good Thing! -- Hugh Miller | Asst. Prof. of Philosophy | Loyola University Chicago FAX: 312-508-2292 | Voice: 312-508-2727 | hmiller@lucpul.it.luc.edu PGP 2.3A Key fingerprint: FF 67 57 CC 0C 91 12 7D 89 21 C7 12 F7 CF C5 7E
zastita.224 spantic, -> #223, dejanr
> ViaCrypt will enable U.S. users to communicate completely legally with non- > U.S. users of PGP 2.3A. Šta mislite, kolika je verovatnoća da su ugradili tajna vrata?
zastita.225 niklaus, -> #224, spantic
(:>> ViaCrypt will enable U.S. users to communicate completely legally (:>> with non- U.S. users of PGP 2.3A. (:> (:> Šta mislite, kolika je verovatnoća da su ugradili tajna vrata? Pa to se ne bi svodilo na verovatnoća je p=0.002, nego da li su ili nisu. Kako vidim da je patentiran algoritam (ili ceo softverski paket), ne bi trebalo da postoji back-door. Kako se, i da li se zavod za patente (ili kako li mu je ime u USA) obezbeđuje da autori algoritama/softvera ne zloupotrebe namenu sopstvenog softvera, koji je nesumnjivo nekima potreban kao potpuno bezbedan (dobro, pomalo poznavajući zakon verovatnoće, reći ću samo "izuzetno pouzdan")? (:niklaus:)
zastita.226 spantic, -> #225, niklaus
> Kako vidim da je patentiran algoritam (ili ceo softverski paket), ne > bi trebalo da postoji back-door. Problem je što je firma koja drži patent tesno povezana sa US vladom. Bilo je o tome ovde povodom problema autora PGP-a sa njima. > Kako se, i da li se zavod za patente (ili kako li mu je ime u USA) > obezbeđuje da autori algoritama/softvera ne zloupotrebe namenu sopstvenog > softvera, koji je nesumnjivo nekima potreban kao potpuno bezbedan (dobro, > pomalo poznavajući zakon verovatnoće, reći ću samo "izuzetno pouzdan")? Uzimajući u obzir da su vladine agencije uradile i rade sve od sebe da bi omogućile kontrolu širokog, pučkog kriptovanja, ne bih se u to kladio. I DES algoritam je stalno pod sumnjom zbog učešća ( zapravo tuče ;) NSA da nametne svoj algoritam.
zastita.227 zddb,
Zna li neko da li postoji novija verzija programa COPYIIPC ili sličnog programa? Naime, verzija koju ja imam ne može da radi sa HD disketama. * S
zastita.228 ognjen, -> #224, spantic
)-> Šta mislite, kolika je verovatnoća da su ugradili tajna )-> vrata? 100% :)
zastita.229 kale, -> #228, ognjen
>> )-> Šta mislite, kolika je verovatnoća da su ugradili tajna >> )-> vrata? >> 100% :) Meni ohrabrujuće deluje to što su kodiranje/dekodiranje binarno kompatibilni sa PGP.
zastita.230 dejanr,
Ako vas zanima šifrovanje javnim ključem (ne samo RSA algoritmom!), pročitajte tri teksta iz današnje "porcije" NOVOSTI/microb. Poruka 4.822 opisuje jedan od algoritama za šifrovanje, 4.823 opisuje kako se generišu VELIKI prosti brojevi a 4.824 ukratko pominje "neizbežni" RSA.
zastita.231 ndragan, -> #229, kale
/ Meni ohrabrujuće deluje to što su kodiranje/dekodiranje binarno / kompatibilni sa PGP. Mož' da bidne i ne mora da znači. Da sam na njihovom mestu, nove tekstove bih kriptovao sa sve zadnjim vratima, a one kriptovane sa bez njih bih nastavio da čitam i ćutao bih ko buba. Moguće je da su zadnja vrata napravljena jednostavnim filtriranjem tabela - za pisanje koristim samo one koje ih imaju, a za čitanje koristim koje god treba. Niko ništa ne primećuje, a i ne treba da primeti :)
zastita.232 dejanr,
Veliki broj američkih firmi koje "drže" baze podataka anketirano je o problemima sa sigurnošću i kompjuterskim krađama. 25% anketiranih imalo je problema, često veoma ozbiljnih. Najčešće su stradali od bivših i sadašnjih službenika koji su provaljivali u sisteme da bi krali, a ima i onih koje najviše muče tinejdžeri koji zovu modemom i provaljuju u sisteme. Izgleda da je postojeća tehnologija zaštite podataka dovoljna - problem je u ljudima koji tu tehnologiju ne koriste ili je nepravilno koriste. NOVOSTI/microb 4.85.
zastita.233 djelovic, -> #232, dejanr
> Veliki broj američkih firmi koje "drže" baze podataka anketirano je > o problemima sa sigurnošću i kompjuterskim krađama. 25% anketiranih > imalo je problema, često veoma ozbiljnih. Pazi ovo: U skoroj anketi koju je sproveo Macworld, 21% firmi elektronski "priskuškuje" svoje zaposlene. Od toga, 74% čita tuđe fajlove, 42% elektronsku poštu, a 15% voice poštu.
zastita.235 kriss,
Pitanje u vezi PGP-a: Koju vremensku zonu treba da stavim u envajorment tz da bi sve bilo ok? :)
zastita.236 nemo, -> #235, kriss
==> Koju vremensku zonu treba da stavim u envajorment tz da bi sve ==> bilo ok? :) pored SET PGPPATH=D:ĐTĐPGP, treba i: SET TZ=MET-1DST (Middle European Time - 1 Daylight Savings Time) le cap
zastita.237 mjova, -> #235, kriss
> Koju vremensku zonu treba da stavim u envajorment tz da bi > sve bilo ok? :) set tz=MET-1DST