Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?
maybe offtopic On Tue, 1 Oct 2013, someone who (if I've unwrapped the nested quoting correctly) might have been Jerry Leichter wrote: There are three levels of construction. If you're putting together a small garden shed, it looks right is generally enough - at least if it's someone with sufficient experience. If you're talking non-load-bearing walls, or even some that bear fairly small loads, you follow standards - use 2x4's, space them 36 apart, [[...]] Standard construction in US Canada uses 2/4's on 16 (repeat: 16) centers. Perhaps there's a lesson here: leave carpentry to people who are experts at carpentry. /maybe offtopic And leave crypto to people who are experts at crypto. -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Functional specification for email client?
On Fri, 30 Aug 2013, Ray Dillinger wrote: 3. When an email user gets an email, s/he is absolutely sure that it comes from the person who holds the email address listed in its from line. S/he may or may not have any clue who that person is. S/he is also sure that no one else has seen the contents of the email. This probably needs amending to deal with messages addressed to multiple recipients (either cc:, bcc:, or simply multiple to: addresses). -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Email and IM are ideal candidates for mix networks
On Wed, 28 Aug 2013, Jerry Leichter wrote: On the underlying matter of changing my public key: *Why* would I have to change it? It's not, as today, because I've changed my ISP or employer or some other random bit of routing information - presumably it's because my public key has been compromised. Maybe it's because you've forgotten the passphrase guarding the corresponding private key? Or because you'd like to do the electronic equivalent of change my name, start [this facet of] my electronic life over? -- -- Jonathan Thornburg jth...@astro.indiana.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Implementations, attacks on DHTs, Mix Nets?
On Tue, 27 Aug 2013, Perry E. Metzger wrote: Say that you want to distribute a database table consisting of human readable IDs, cryptographic keys and network endpoints for some reason. Say you want it to scale to hundreds of millions of users. This sounds remarkably like a description of DNSSEC. Assuming it were widely deployed, would DNSSEC-for-key-distribution be a reasonable way to store email_address -- public_key mappings? -- -- Jonathan Thornburg jth...@astro.indiana.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. -- George Orwell, 1984 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Formal notice given of rearrangement of deck chairs on RMS PKItanic
On Wed, 6 Oct 2010, Matt Crawford wrote: [[...]] I found it amusing that this message was accompanied by an S/MIME certificate which my mail client (alpine) was unable to verify, resulting in the error messages [Couldn't verify S/MIME signature: certificate verify error] [ This message was cryptographically signed but the signature ] [ could not be verified. ] ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
deliberately crashing ancient computers (was: Re: A mighty fortress is our PKI)
On Tue, 27 Jul 2010, Jack Lloyd suggested: http://www.crashie.com/ - if you're feeling malicious, just include the one line JavaScript that will make IE6 crash, maybe eventually the user will figure it out. (Or maybe not). Please stop and think about the consequences before using something like this! People who are still using IE6, Windows 95, etc, are usually doing so for reasons which make sense in their lives, things like (a) very low computer literacy (b) slow/unreliable internet connections (dialup?) (c) old/small/slow computer ( lack of money to buy a better one) (d) English not her/his native language (to read your how-to-upgrade msg) (e) that's what all their friends professional colleagues use These people are unlikely to change just because your site makes their computer crash. (They're also unlikely to distinguish between IE6 crashed and the computer crashed, and yes, they're likely to blame your website for the problem.) I too would love to see IE6 die. Ditto Windows 95. But I don't think actively trying to crash my colleague Professor X's computer is either ethical or an appropriate solution to her ancient computer environment. (She is elderly, retired, lives in a very poor country in South America, and has only dialup internet. The local computer shops/geeks where she lives usually recommend Windows 95 for upgrades/reinstalls. I don't know what web browser they pitch...) Ultimately though, the only thing that's going to get some people off IE6 is the machines they are running it off of finally dying, either due to hardware failure or being so badly owned by worms that the machine becomes inoperable, at which point it goes into the trash and they buy a new one. Yup. -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: [TIME_WARP] 1280-Bit RSA
The following usenet posting from 1993 provides an interesting bit (no pun itended) of history on RSA key sizes. The key passage is the last paragraph, asserting that 1024-bit keys should be ok (safe from key-factoring attacks) for a few decades. We're currently just under 1.75 decades on from that message. I think the take-home lesson is that forecasting progress in factoring is hard, so it's useful to add a safety margin... From: p...@ox.ac.uk (Paul C Leyland) Newsgroups: sci.crypt Subject: Re: Questions about RSA. Message-ID: pcl.93feb16102...@rhodium.ox.ac.uk Date: 16 Feb 93 10:26:11 GMT References: 1993feb10.183246.29...@ee.ubc.ca Distribution: sci.crypt, alt.security Organization: Oxford University Computing Services, 13 Banbury Rd Oxford OX2 6NN Lines: 59 In-reply-to: jrusm...@ee.ubc.ca's message of 10 Feb 93 18:32:46 GMT In article 1993feb10.183246.29...@ee.ubc.ca jrusm...@ee.ubc.ca (RUSMISEL JASON DIRK) writes: ... 1) The article suggests that the length of 'n', (where n is the product of two large primes p and q, and n is the modulus used with the encryption and decrytion keys to decode and encode) be 200 digits. [page 125, top right] 200 digits base 10 is about 664 binary digits. Now, to the question. The program PGP provides various levels of key length, 384 bits, 512 bits and 1024 bits. How were these numbers decided on? I The PGP values are round numbers (3/8, 1/2 and 1) in kilobits. They are (handwaving furiously here) about the right size for testing, routine use and archival security. The RSA values are about the right size for routine use. realize that the state of computer technology at the time the RSA article was written was very different than it is now, but have there been significant advances in crypto breaking since 1978 that would make factoring such large numbers much easier? (Perhaps the Connection Machine.) Really I'm interested in a discussion of the design decisions/tradeoffs here. Let me try to justify the armwaving a little. First, we must realise that the larger the keys, the greater the run-time of the encryption and decryption process. Purists may nit pick, but roughly speaking doubling the number of digits in the key increases the run time eightfold. [Purists: I'm assuming a n-squared multiplication routine and the simple binary method of exponentiation]. So small moduli are good. So far as is known, the only way to find the RSA secret key (other than espionage, bribery, extortion, etc) is to factorize the modulus. Here large moduli are good. Roughly speaking *adding* a few bits to the length of the modulus raises the factorizing cost eightfold. Compare this to the encryption, where *doubling* costs us that much. The meaning of a few bits can also be argued over, but it is around 20 bits, depending on methods and the size of the number. Current state of the art described in the open literature factorizes 120-digit numbers in a time of order one year, using machines of order 1000mips performance. Again, purists can post better numbers if they wish. 384 bits is 116 digits so the PGP test keys can, with sufficient effort, be cracked with today's technology. 512 bits is well beyond current technology (155 digits) but *might* be accessible in a few years with better algorithms and faster machines and more of them working in parallel and ... (I'm handwaving again). 1024-bits, so far as is known should be ok for a few decades. I'd be happy to be proved wrong, as there's lots of other numbers I'd like to be able to factorize. Paul -- Paul Leyland p...@oxford.ac.uk | Hanging on in quiet desperation is Oxford University Computing Service | the English way. 13 Banbury Road, Oxford, OX2 6NN, UK | The time is come, the song is over. Tel: +44-865-273200 Fax: +44-865-273275 | Thought I'd something more to say. Finger p...@black.ox.ac.uk for PGP key| -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: SHA-1 and Git (was Re: [tahoe-dev] Tahoe-LAFS key management, part 2: Tahoe-LAFS is like encrypted git)
On Tue, 25 Aug 2009, Ben Laurie wrote: In order to roll out a new crypto algorithm, you have to roll out new software. So, why is anything needed for pluggability beyond versioning? If active attackers are part of the threat model, then you need to worry about version-rollback attacks for as long as in-the-field software still groks the old (now-insecure) versions, so versioning is actually more like Byzantine versioning. -- -- Jonathan Thornburg jth...@astro.indiana.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: CSPRNG algorithms
On Sat, Mar 14, 2009 at 3:16 AM, Travis travis+ml-cryptogra...@subspacefield.org wrote: I have never seen a good catalog of computationally-strong pseudo-random number generators. It seems that everyone tries to roll their own in whatever application they are using, and I bet there's a lot of waste and inefficiency and re-inventing the wheel involved. If this true, or is there a survey somewhere? If not, would people like to help me create one by emailing me references to extant PRNG definitions? There's a nice survey, with some advice on how to construct a good PRNG, at J. Kelsey, B. Schneier, D. Wagner, and C. Hall Cryptanalytic Attacks on Pseudorandom Number Generators Fast Software Encryption, Fifth International Workshop Proceedings (March 1998), Springer-Verlag, 1998, pp. 168-188. http://www.schneier.com/paper-prngs.html ABSTRACT: In this paper we discuss PRNGs: the mechanisms used by real-world secure systems to generate cryptographic keys, initialization vectors, random nonces, and other values assumed to be random. We argue that PRNGs are their own unique type of cryptographic primitive, and should be analyzed as such. We propose a model for PRNGs, discuss possible attacks against this model, and demonstrate the applicability of this model (and our attacks) to four real-world PRNGs. We close with a discussion of lessons learned about PRNG design and use, and a few open questions. The authors' reputations suggest their advice is probably excellent... ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA C++ is to programming as sex is to reproduction. Better ways might technically exist but they're not nearly as much fun. -- Nikolai Irgens
Re: full-disk subversion standards released
I wrote: | Indeed, the classic question is I've just bought this new computer | which claims to have full-disk encryption. Is there any practical | way I can assure myself that there are (likely) no backdoors in/around | the encryption? | | For open-source software encryption (be it swap-space, file-system, | and/or full-disk), the answer is yes: I can assess the developers' | reputations, I can read the source code, and/or I can take note of | what other people say who've read the source code. On Fri, 30 Jan 2009, Brian Gladman asked: But, unless you are doing it with a pencil and paper, your encryption is still being done in hardware even if you write it yourself. For example, why would you trust an Intel processor given that Intel is one of the founding members of the TCG and is a major player in its activities? It's instructive to the distinction between data in motion encryption (for example, a network-encryption-box (NEB) and data at rest encryption (for example, a cryptographic filesystem): A network-encryption box: computer#1 NEB#1 ((network)) NEB#2 computer#2 plaintextciphertext ciphertext plaintext As described by Henry Spencer in http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html it's perfectly practical for (say) the NSA to arrange for a backdoor in each NEB which occasionally leaks the keystream into the network, in a way that's very unlikely to be caught in testing, but would make it easy for an eavesdropper on the network to recover the plaintext. A cryptographic filesystem: I could imagine the NSA having arranged to plant some sort of microcode backdoor in the Pentium III processor in my laptop. (The hardest part would probably be persuading all the Intel employees involved that it wouldn't be a PR disaster for Intel if the news leaked out.) In the context of my original message, the backdoor would have to recognize the binary code sequence of the OpenBSD AES routines when invoked by the encrypting-filesystem vnode layer, and somehow compromise the security (maybe arrange to leak keystream bits into free disk sectors??). That's a tricky technical job, but I could imagine it being done, and if it's all in processor microcode, I could even imagine it having stayed a secret. But that's not good enough: What about Matt Blaze's Cryptographic File System? What about all the people using the various Linux encrypting file systems? The backdoor(s) need to cover them, too. And the MacOS ones (if there's not a software backdoor there). And all the other open-source-crypto systems. And the backdoors have to do this without compromising interoperability -- I have CFS directory trees which I created on an old Sparc that I now use on my laptop. But I think the hardest part of all is that the backdoor has to still still recognize the various crypto binary-code-sequences even when the relevant software is recompiled with a newer compiler using a different global optimizer, even though that newer compiler might not even have existed when the backdoor was inserted. It's this variety of different software encryption schemes -- and compilers to turn them into binary code (which is what the NSA/Intel backdoor ultimately has to key on) that, I think, makes it so much harder for a hardware backdoor to work (i.e. to subvert software encryption) in this context. -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: full-disk subversion standards released
On Thu, 29 Jan 2009, John Gilmore wrote: If it comes from the Trusted Computing Group, you can pretty much assume that it will make your computer *less* trustworthy. Their idea of a trusted computer is one that random unrelated third parties can trust to subvert the will of the computer's owner. Indeed, the classic question is I've just bought this new computer which claims to have full-disk encryption. Is there any practical way I can assure myself that there are (likely) no backdoors in/around the encryption? For open-source software encryption (be it swap-space, file-system, and/or full-disk), the answer is yes: I can assess the developers' reputations, I can read the source code, and/or I can take note of what other people say who've read the source code. Alas, I can think of no practical way to get a yes answer to my question if the encryption is done in hardware, disk-drive firmware, or indeed anywhere except software that I fully control. -- -- Jonathan Thornburg jth...@astro.indiana.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bitcoin v0.1 released
On Sat, 17 Jan 2009, Satoshi Nakamoto wrote: [[various possible uses of Bitcoin et al]] Once it gets bootstrapped, there are so many applications if you could effortlessly pay a few cents to a website as easily as dropping coins in a vending machine. In the modern world, no major government wants to allow untracable international financial transactions above some fairly modest size thresholds. (The usual catch-phrases are things like laundering drug money, tax evasion, and/or financing terrorist groups.) To this end, electronic financial transactions are currently monitored by various governments their agencies, and any but the smallest of transactions now come with various ID requirements for the humans on each end. But if each machine in a million-node botnet sends 10 cents to a randomly chosen machine in another botnet on the other side of the world, you've just moved $100K, in a way that seems very hard to trace. To me, this means that no major government is likely to allow Bitcoin in its present form to operate on a large scale. I also worry about other domestic ways nasty people could exploit a widespread Bitcoin deployment: * Spammer botnets could burn through pay-per-send email filters trivially (as usual, the costs would fall on people other than the botnet herders spammers). * If each machine in a botnet sends 1 cent to a herder, that can add up to a significant amount of money. In other words, Bitcoin would make botnet herding and the assorted malware industry even more profitable than it already is. Is there something obvious I've missed? Is there a clever aspect of the design which prevents botnets from exploiting the system? Is there a way for every major government to monitor all Bitcoin transactions to watch for botnet-to-botnet sending? -- -- From: Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: defending against evil in all layers of hardware and software
On Tue, 29 Apr 2008, Ivan Krsti?~G wrote: On Apr 28, 2008, at 12:58 PM, John Denker wrote: Of course we should insist on an open-source boot ROM code: The boot ROM should check the pgp signature of each PCI card's BIOS code before letting it get control. And then it should check the pgp signature of the operating system before booting it. I don't know of any machine that actually does this The OLPC XO-1 laptop has an open-source bootloader (Open Firmware) which checks the operating system signature before passing control to it. If the bootloader is running on malicious hardware I don't think that test can be trusted. :( -- Jonathan Thornburg (remove -animal to reply) [EMAIL PROTECTED] School of Mathematics, U of Southampton, England C++ is to programming as sex is to reproduction. Better ways might technically exist but they're not nearly as much fun. -- Nikolai Irgens
Re: Death of antivirus software imminent
Alex Alten wrote: Generally any standard encrypted protocols will probably eventually have to support some sort of CALEA capability. For example, using a Verisign ICA certificate to do MITM of SSL, or possibly requiring Ebay to provide some sort of legal access to Skype private keys. I can certainly imagine various countries legislating such backdoors, and other countries quietly installing them (assuming they aren't already there for Skype). And that will certainly help in catching some fraction of unsophisticated crooks. But botnets-for-rent are currently making pretty substantial amounts of money (eg for sending spam, or ddos attacks, or as phishing hosts), and are increasingly using professionally written malware. (http://www.cs.auckland.ac.nz/~pgut001/pubs/malware_biz.pdf) Given the lure of this much easy money, I think it's much more likely that the cleverer bad guys will just wrap an un-backdoored ssh or ssl or ipsec or other good crypto protocol that's already widely available layer inside the backdoored one(s), giving them (continued) full security. For better or worse, I think the bad buys can use strong crypto horse left the barn a long time ago. In a more recent message, Alex Alten wrote: the criminals have to design their security system with severe disadvantages; they don't own the machines they attack/take over so they can't control its software/hardware contents easily I don't see your point -- surely once a machine is recruited into a botnet, the botnet herder can and does load any software s/he wants onto the new recruit. they can't screw around too much with the IP protocol headers or they lose communications with them, and they don't have physical access to the slave/owned machines. In what way has this stopped (or even slowed) the Storm worm, to name one notorious example? -- -- Jonathan Thornburg (remove -animal to reply) [EMAIL PROTECTED] School of Mathematics, U of Southampton, England Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: *AEI-SPAM-MARK* Re: Governance of anonymous financial services
On Fri, 30 Mar 2007, Ian G wrote: The reserve assets' location(s) is fairly important from a customer trust perspective. People look at the overall safety and make their own judgements. One person might decide that New York is safe and another will find that a horrible thought (for those who follow this arcane field, there was a big bust of a dodgy operator in NY some months back). Having said that, once a system is up and running, and is robust, it seems that moving the assets from one continent to another has not been a source of concern to many users. The issuer himself is pretty important. His physical location isn't so important -- everyone flies around these days -- but nobody has ever been able to gain trust in a system to date without reference to a real meatspace hook. And for good reason ... how do you take him to court? (And if you are thinking of extra-jurisdictional transactions, how do you beat him to a pulp with a baseball bat?) There's another point: Suppose you come up with an ideal system which preserves secrecy in the way you'd like. How are you going to convince assorted government agencies (eg the US Treasury Dept and its kin in other countries) that your System won't be used for money laundering, terrorist financing, or other nefarious purposes? [N.b. I am *not* trying to start a flame war here, and in particular I am *not* accusing anyone on this mailing list of nefarious purposes. Rather, I'm asking a serious question about the practicality of anonymous (crypto-enabled) financial services in the 21st century, namely, will governments be willing to allow them to operate?] ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] School of Mathematics, U of Southampton, England Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Fri, 19 Jan 2007, Bill Stewart wrote: Obviously if you're trying to protect against KGB-skilled attacks on stolen/confiscated hardware, you'd like to have the swap partition encrypted as well as any user data partitions, though you may not care whether your read-only utility software was protected (e.g. your Knoppix disk or vanilla shared /usr/ or whatever.) [[...]] On the other hand, if you're trying to protect against lower-skilled attackers, e.g. laptop thieves who are reselling disks to the Nigerians and other hardware on eBay, you want to protect your file systems, but probably don't need to protect your swap. It's certainly nice to do that, of course, and might be a Good Thing for Linux and ***BSD to include in their standard swap drivers, OpenBSD has had swap-space encryption for some years, and recent versions turn it on in the default install. I don't know what the other BSDs or various Linuxen do by default. OpenBSD's swap encryption uses Rajndael/AES implemented in software. The performance hit is small on modern hardware, and still acceptable even on slow hardware (I haven't seen any problems on an old 486/33 laptop I'm using as a home firewall/router). For laptops (where physical theft is major concern), I think the combination of an encrypting file system and swap encryption gives a pretty good -- and readily configurable -- security/performance tradeoff. ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Mon, 15 Jan 2007 08:39:18 -0800 Saqib Ali [EMAIL PROTECTED] wrote: An article on how to use freely available Full Disk Encryption (FDE) products to protect the secrecy of the data on your laptops. FDE solutions helps to prevent data leaks in case the laptop is stolen or goes missing. The article includes a brief intro, benefits, drawbacks, some tips, and a complete list of FDE solutions in the market. http://www.full-disk-encryption.net/intro.php On Tue, 16 Jan 2007, Steven M. Bellovin wrote: I'll turn it around -- why should you use it? In most situations, disk encryption is useless and probably harmful. [[cogent arguments snipped]] A further point: Do you really want the granularity of your encryption to be one key per disk? I much prefer a cryptographic file system which lets me have separate keys for separate categories of information (eg one key for my tax forms, a different key for company-confidential project stuff, a different key for old love letters, still another one for My Secret Plan For World Domination, etc etc). These might all live on the same laptop, but they probably need quite different key policies. ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
On Tue, 16 Jan 2007, Steven M. Bellovin wrote: [[about full-disk encryption]] In most situations, disk encryption is useless and probably harmful. It's useless because you're still relying on the OS to prevent access to the cleartext through the file system, and if the OS can do that it can do that with an unencrypted disk. Yes, encrypted disks aren't much good unless the OS also encrypts (at least) swap space. I note that OpenBSD ships with swap-space encryption turned on by default. The encryption is done in software using Rijndael. On modern hardware the performance hit is minimal (compared to the cost of the disk access). See http://www.openbsd.org/papers/swapencrypt.ps for a discussion of the security model. ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Thu, 2 Nov 2006, Alexander Klimov wrote: I guess many people here have tried full disk encryption for themselves, do you notice any difference in performance or not? I've been using Matt Blaze's CFS (cryptographic file system) to encrypt personal E-mail archives since 1994 or so. CFS is about the slowest cryptographic file system around: it's implemented outside the kernel (via an NFS loopback mount), so there are lots of userland -- kernel transitions and data copies going on. And it uses 3DES, which is a lot slower than (eg) AES. Despite all that, CFS performance is just fine. Back when I started using CFS, on a 33 MHz SPARC, the performance hit was noticable but tolerable. Now, when multi-GHz laptops abound, the CFS performance hit is really a drop in the bucket for normal interactive use on moderate-sized files. As a test, I just tried time dd if=/dev/arandom bs=65536 count=512 of=32m (to time writing 32 MB of random data to disk) on my laptop (Lenovo/IBM Thinkpad T43P, OpenBSD 3.9-stable). I ran the command three times (with different file names each time) on each of: (a) a CFS directory backed by my laptop's /home file system, (b) my laptop's /home file system (BSD FFS with soft dependencies), and (c) my laptop's /tmp file system (a memory file system) I was careless/lazy, so these trials all started with the system at its idling clock rate (600 MHz), and let the system ramp up the clock rate as needed once it noticed the CPU usage. The times (wall-clock seconds from the 'time' command) were pretty consistent for each of the 3 trials: (a) 10.33 10.75 9.69 (b) 2.12 2.08 2.05 (c) 1.84 1.89 1.85 So... even for 32-MB files, CFS only takes about 8 seconds for the encryption. For smaller files the hit is truly negligible -- when I tried this test on 64K files there was no difference in times between (a), (b), and (c) within the timing noise. ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: thoughts on one time pads
Two other problems with using a CD for OTP key material: 1. How to insure physical security for the N years between when you exchange CDs and the use of a given chunk of keying material? The single CD system is brittle -- a single black-bag burglary to copy the CD, and poof, the adversary has all your keys for the next N years. 2. How to securely destroy it after use, to prevent retrospective dumpster-diving? Nothing short of physical destruction will stop a determined adversary... and physical destruction is *hard*: Smashing the CD with a hammer leaves individual fragments which can still be read with a microscope. (That would yield some key bits; a serious adversary could drag these across archived encrypted-traffic to find the position which decrypts to something that's statistically plaintext.) Melting the CD should work... but in practice that takes a specialized oven (I seriously doubt my home oven gets hot enough), and is likely to produce toxic fumes, and leave behind a sticky mess (stuck to the surface of the specialized oven). ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [spam]::Re: [Clips] Banks Seek Better Online-Security Tools
In an earlier message, I wrote I would never use online banking, and I advise all my friends and colleagues (particularly those who _aren't_ computer-security-geeks) to avoid it. Jason Axley asked Why do you not use OLB? Basically, so far as I know the fine print in online bank service agreements basically says you (the customer) are responsible for any transactions we receive with your username and pin, and our electronic records are the final word on this. Thus if there is an a false transaction on my account, i.e. one which I did not intend to authorize (whether this happened due to insider fraud in the bank, MITM phishing, virus in my computer, or whatever other cause), the basic legal presumption is that it's my loss, not the bank's. I consider the risks of this too high. What would need to be fixed for you to use OLB in the future? I would want the same ability to refuse an unauthorized transaction that I have now with credit cards, where basically any losses over 50 Euros/dollars are the bank's problem, not mine. What is your threat model (WIYTM)? For online banking, any/all of (a) insider fraud at the bank and/or anyone else to whom they've outsourced relevant processing (b) computer breakin/theft at the bank and/or anyone else to whom they've outsourced relevant processing (c) MITM phishing or DNS hijacking (d) viruses/worms in my computer What risks are present in OLB that are not present in the offline world? (c) and (d) above. Also liability for problems is mine, not the bank's (see above). Also there are few paper records that I can use to help document problems. In the offline world, (a) and (b) are mitigated by paper records (and forms with my written signature) which crooks usually don't bother forging. What about the risks of the offline financial world? If I wire-transfer money from my bank in Germany to my credit union in Canada, my written signature is (supposed to be) required to verify that I did in fact authorize the transaction. If the bank sends my money off to a crook's account (whether by mistake or due to deliberate fraud), the next time I get a statement I'll notice, and I'll ask them what happened. If the bank can't show me a piece of paper with my signature on it, my understanding is that (if I complain enough) I can force them to refund the money to me (so it's then their problem to try to recover it from wherever it went). For example, all of the information that someone needs to put money in, or take it out, of your checking account via ACH is nicely printed in magnetic ink on your checks in the US. And you give it out to anyone when you write them a check. Where I live now (Germany) people don't use cheques, they do bank transfers which the *payer* gives direct to her bank. These (are supposed to) have the written signature of the payer (the account-holder). If someone forges one of these and takes money out of my account, I can refuse the transaction and (I understand) the bank is legally required to refund the money to me (and it's their problem to recover it from whoever got it). When I lived in Canada (where people use cheques in the same way as in the US), my understanding is that (a) Even with the transit/routing numbers, noone is supposed to be able to take money out of an account without prior written permission. A cheque constitutes such permission _for_a_specific_transaction_, but not for any other transaction(s). (b) If someone forges another cheque (eg scans my signature etc), and my bank honors it and takes the money out of my account. then since I didn't actually sign that cheque, legally it's the bank's fault for honoring it, and (if I complain enough) I can force the bank to refund the money to me (so it's then the bank's problem to try to recover it from the crook). This reminded me of how I laughed when I saw an interview with a local security person where he said that he didn't even connect a computer to the Internet at home due to the risk. To me, this seems akin to deciding to not leave your house because you can't be sure someone won't shoot you dead. Well, in certain places that's basically what people do. For example, many foreign people in Bhagdad don't venture out of the green zone. My point is that when substantial amounts of money are involved, IMHO the internet is basically a red zone where I don't feel safe venturing. ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending
Re: [Clips] Banks Seek Better Online-Security Tools
I would never use online banking, and I advise all my friends and colleagues (particularly those who _aren't_ computer-security-geeks) to avoid it. On Sun, Dec 04, 2005 at 05:51:11PM -0500, [EMAIL PROTECTED] wrote: I've been using online banking for many years, both US and Germany. The German PIN/TAN system is reasonably secure, being an effective one-time pad distributed through out of band channel Ahh, but how do you know that the transaction actually sent to the bank is the same as the one you thought you authorized with that OTP? If your computer (or web browser) has been cracked, you can't trust _anything_ it displays. There are already viruses in the wild attacking German online banking this way: http://www.bsi.bund.de/av/vb/pwsteal_e.htm I also don't trust RSAsafe or other such 2-factor authentication gadgets, for the same reason. [I don't particularly trust buying things online with a credit card, either, but there my liability is limited to 50 Euros or so, and the credit card companies actually put a modicum of effort into watching for suspicious transactions, so I'm willing to buy (a few) things online.] ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: gonzo cryptography; how would you improve existing cryptosystems?
On Fri, 4 Nov 2005, Travis H. wrote: PS: There's a paper on cryptanalyzing CFS on my homepage below. I got to successfully use classical cryptanalysis on a relatively modern system! That is a rare joy. CFS really needs a re-write, there's no real good alternatives for cross-platform filesystem encryption to my knowledge. On Mon, 7 Nov 2005, Jason Holt wrote: Take a look at ecryptfs before rewriting cfs: http://sourceforge.net/projects/ecryptfs Nice, but linux-only and requires special kernel support. cfs supports lots and lots of different OSs and doesn't require kernel modes. So far as I know, in this regard cfs is unique among cryptographic filesystems. ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Security is the bits you disable before you ship
On Wed, 16 Mar 2005, Russell Nelson wrote: I've seen Dan Bernstein (and you don't get much more careful or paranoid about security than Dan) write code like this: static char line[999]; len = 0; len += fmt_ulong(line + len,rp); len += fmt_str(line + len, , ); len += fmt_ulong(line + len,lp); len += fmt_str(line + len,\r\n); Of course, the number of characters that fmt_ulong will insert is limited by the number of bits in an unsigned long, and both strings are of constant length. Ick. Why not the simpler/clearer (and hence safer -- complexity makes it harder to find bugs of any sort, including security ones) snprintf() call: #define N_LINE 999 static char line[N_LINE]; len = snprintf(line, N_LINE, %ul , %ul\r\n, rp, lp); snprintf() first appeared in 4.4BSD and is now in C99, so any modern system should support it by now. ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Linux-based wireless mesh suite adds crypto engine support
Ethernet * From: Paul Koning [EMAIL PROTECTED][EMAIL PROTECTED] _ * Prev by Date: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet * Next by Date: linux-ipsec: IP Sec w/ dynamic IP addresses ? * Prev by thread: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet * Next by thread: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet * Index(es): + Main + Thread -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]