Re: Hushmail in U.S. v. Tyler Stumbo
On Nov 1, 2007, at 10:49 AM, John Levine wrote: Since email between hushmail accounts is generally PGPed. (That is the point, right?) Hushmail is actually kind of a scam. In its normal configuration, it's in effect just webmail with an HTTPS connection and a long password. It will generate and verify PGP signatures and encryption for mail it sends and receives, but they generate and maintain their users' PGP keys. There's a Java applet that's supposed to do end to end encryption, but since it's with the same key that Hushmail knows, what's the point? I'm sorry, but that's a slur. Hushmail is not a scam. They do a very good job of explaining what they do, what they cannot do, and against which threats they protect. You may quibble all you want with its *effectiveness* but they are not a scam. A scam is being dishonest. You also mischaracterize the Hushmail system. The "classic" Hushmail does not generate the keys, and while it holds them, they're encrypted. The secrets Hushmail holds are as secure as the end user's operational security. I know what you're going to say next. People pick bad passphrases, etc. Yes, you're right. That is not being a scam. They have another system that is more web-service oriented, and they explain it on their web site far better than I could. It has further limitations in security but with increased usability. It is also not a scam. Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Hushmail in U.S. v. Tyler Stumbo
>Since email between hushmail accounts is generally PGPed. (That is >the point, right?) Hushmail is actually kind of a scam. In its normal configuration, it's in effect just webmail with an HTTPS connection and a long password. It will generate and verify PGP signatures and encryption for mail it sends and receives, but they generate and maintain their users' PGP keys. There's a Java applet that's supposed to do end to end encryption, but since it's with the same key that Hushmail knows, what's the point? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Spammers employ stripper to crack CAPTCHAs
'Melissa' disrobes in ploy that relies on people, not CPUs, to crack squiggly codes October 30, 2007 (Computerworld) -- Spammers are using a virtual stripper as bait to dupe people into helping criminals crack codes they need to send more spam or boost the rankings of parasitic Web sites, security researchers said today. A series of photographs shows "Melissa," no relation to the 1999 worm by the same name, with progressively fewer clothes and more skin each time the user correctly enters the characters in an accompanying CAPTCHA (Completely Automatic Public Turing Test to Tell Computers and Humans Apart), the distorted, scrambled codes that most Web mail services use to block bots from registering hundreds or thousands of accounts. Spammers rely on Web e-mail accounts because they're disposable; by the time filters have blocked the address, the spammers throw it away and move on to another. The CAPTCHAs that Melissa feeds to users are, in fact, legitimate codes snatched from Yahoo Mail's signup screens, said analysts at Trend Micro Inc. The hackers, frustrated at their inability to come up with a way to automate account registration, are getting users to do their dirty work. "They're using human beings in semi-real time to translate CAPTCHAs by proxy," said Paul Ferguson, a network architect at Trend Micro. "You have to give them this, it's clever." Each time the user correctly decodes the CAPTCHA, a new Melissa photo is revealed, pulled from a hacker-controlled server in Israel, according to Symantec Corp. The plain-text decodes are sent to that same server, where they are presumably banked for future use in generating large numbers of Yahoo Mail accounts. Fumble-fingered typists are even encouraged by Melissa to try their luck again: "Hmmm, nope, the word you entered is incorrect honey! Lets [sic] try again?" the virtual stripper replies. Trend Micro said the striptease was part of a Trojan horse called CAPTCHA.a; rival Symantec dubbed it Captchar.a instead. The Trojan horse may be part of a multistage attack, downloaded to a PC that's been compromised by other, more malicious code, or can be encountered as a drive-by Web-based exploit. "This isn't the first time that they've tried to bust CAPTCHAs," said Ferguson, noting past attempts by bot-driven malware to apply optical character-recognition technology to deciphering the squiggles and obscured letters. Nor is it the first time human beings have been put to work decoding CAPTCHAs. "Work-at-home money mule schemes run by criminals have hired people to do this same thing," Ferguson said. "They're told to log on to this Web page and type the CAPTCHA. They have a quota." In some cases, those CAPTCHAs have been used to sidestep bot protection for blog commenting rights; hackers will flood a blog they've created with fraudulent comments to drive up its search-engine ranking, expecting that the higher placement will translate into more traffic and thus more clicks on the ads displayed on the blog page. "Sometimes they use [CAPTCHAs] just to bump up their page [ranking]," Ferguson said. The Trojan horse can strike PCs running Windows 98, Me, NT, 2000, XP and Server 2003. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Commercial CAPTCHA-breakers for sale
"Ali, Saqib" writes: -+-- | The complexity of some the captchas shown on this web-site | made me think. We have gone to such extents to prevent | against spammers. When we should be prosecuting and hanging | the spammers. | | Remember | "Men are not hanged for stealing horses, but that horses may | not be stolen" George Savile | I stand ready to organize a massive conspiracy to execute all conspiracy theorists. Are you with me? --dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
Hello, On 30/10/2007 17:13, Ali, Saqib wrote: > Windows have had FDE (with pre-boot) solutions for a long while. Here > is a list: http://www.full-disk-encryption.net/Full_Disc_Encryption.html IIRC, none of the products on this list is open source. Hagai. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Hushmail in U.S. v. Tyler Stumbo
Maybe this is off topic, but I think it does relate to the implementation of cryptography. I stumbled across this filing: http://static.bakersfield.com/smedia/2007/09/25/15/steroids.source.p rod_affiliate.25.pdf relating to a drug case where the defendant and others used Hushmail. What I found interesting was: 1. The amount of data which Hushmail was required to turn over to the US DEA relating to 3 email addresses. 3 + 9 = 12 CDs What kind of and for what length of time does Hushmail store logs? 2. That items #5 and #15 indicated that the _contents_ of emails between several Hushmail accounts were "reviewed". 3. The request was submitted to the ISP for IP addresses related to a specific hushmail address (#9). How would the ISP be able to link a specific email address to an IP when Hushmail uses SSL/TLS for both web and POP3/IMAP interfaces? Since email between hushmail accounts is generally PGPed. (That is the point, right?) And the MLAT was used to establish probable cause, I assume that the passphrases were not squeezed out of the plaintiff. How did the contents get divulged? Rearden - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
> Right -- I was unaware that Windows actually had any real (pre-boot) > FDE solutions before about the time of BitLocker. But I only > peripherally have any idea about Windows crypto solutions, so I > wouldn't be surprised if I'm wrong. Cheers, Windows have had FDE (with pre-boot) solutions for a long while. Here is a list: http://www.full-disk-encryption.net/Full_Disc_Encryption.html Note: BitLocker is NOT true FDE. It is only volume based encryption. It has 3 modes. In one of the mode you can store the key on a external USB device. Only in that mode BitLocker acts as a FDE solution with pre-boot. saqib http://security-basics.blogspot.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
On Oct 30, 2007, at 5:12 AM, Hagai Bar-El wrote: A great product, but not an FDE one. Right -- I was unaware that Windows actually had any real (pre-boot) FDE solutions before about the time of BitLocker. But I only peripherally have any idea about Windows crypto solutions, so I wouldn't be surprised if I'm wrong. Cheers, -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
Hello, On 30/10/2007 07:37, Ivan Krsti? wrote: > On Oct 29, 2007, at 3:56 PM, Hagai Bar-El wrote: >> Are there at all any open source FDE products for Win32? > > http://www.truecrypt.org/ A great product, but not an FDE one. It encrypts contents of logical drives into container files. You still have to worry about temp files, swap files, hibernation files, tampering with the OS when you're away, etc. FDE typically authenticates pre-OS-boot and supports the encryption of the full disk, including the OS, applications, system storage areas, etc. Hagai. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: password strengthening: salt vs. IVs
On Oct 29, 2007, at 12:24 PM, travis+ml- [EMAIL PROTECTED] wrote: * PGP Signed by an unknown key So back in the bad old days when hashing was DES encryption of the zero vector with a fixed key, someone came up with salt as a password strengthening mechanism. I'm not quite sure why it was called salt. Before the bad old days of using DES, there was the old days of one- way functions. These one-way functions were not hash functions, they were one-way. They were in a sense related to hash functions, but perhaps more directly related to redundancy checks and similar polynomials. The belief was that storing passwords in plaintext was a bad idea. A related notion was that storing a password encoded through a symmetric function was essentially storing it in plaintext. The term salt comes from the metaphor of considering the process of one-waying a password to be like making hamburger out of meat, or stew out of ingredients, or some other cooking metaphor. The salt was introduced to address the issue of dictionary attacks and carried the observation that cooking is better if you add a little salt to it. The salt was a sprinkling of an arbitrary constant into the function to spice it up a bit. The people who worked on these password-grinding systems had a tendency to sneer at those who would use a cipher such as DES for that because DES is reversible. Using a reversible function is essentially storing the password in plaintext. Munging DES was seen by those people as inferior to designing one-way functions that were properly one-way. Eventually, these became a subset of what one would use a hash function for. The IV in a block cipher serves the same function as salt. It's called an IV, though because of the different path of development. The term "salt" gets used in other places, like with randomized hashing, which is often also called salting a hash, too. The question you had is how much entropy there should be in salt. The answer is none, but that's a very subtle answer. Salt is -arbitrary- as opposed to -random-. As it turns out, the best way to get a 256- bit arbitrary number is to pull it off your RNG. Arbitrary numbers like salt, don't have to worry about subtle issues that you'd want key material to worry about. Arbitrary numbers are in general public (or at least not secret), and key material is secret. With salt, you want the number to be unique-ish, as the whole point is to stymie dictionary attacks. A counter is likely not such a great idea, because of collisions, but there are all sorts of things you could do that would be very very bad with key material but are mostly okay with salt. Nonetheless, the easiest way to get salt with a system that has an RNG is to just pull the number off the RNG. But that doesn't mean it has entropy. Now as what to call it? I like "salt." Jon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: password strengthening: salt vs. IVs
On Mon, 29 Oct 2007, [EMAIL PROTECTED] wrote: > So back in the bad old days when hashing was DES encryption of the > zero vector with a fixed key, someone came up with salt as a password > strengthening mechanism. > > I'm not quite sure why it was called salt. > > It perturbed the S-boxes in DES IIRC, but essentially it was a known > bit of text that was an input to the algorithm that varied between > entries, like an IV does with encryption. > > If there isn't already a term for this, I'm going to call this > general concept "individuation", or possibly "uniquification". > > Nowadays with strong hash algorithms, but rainbow tables and > low-entropy passwords as the threat, I'm wondering what the best > practice is. Use a good existing password hash (e.g. OpenBSD's bcrypt[1]) or some well reviewed KDF (e.g. PKCS #5 PBKDF2[2]). Perhaps I'm not imaginative enough, but I can't think of a use case that is not covered by these algorithms. Given decent salt they will not succumb to reverse (rainbow table) lookup and both include parametised computation complexity to drive up the cost of brute force attacks. -d [1] http://www.openbsd.org/papers/bcrypt-paper.ps [2] http://www.rsa.com/rsalabs/node.asp?id=2127 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Full Disk Encryption solutions selected for US Government use
On Oct 29, 2007, at 3:56 PM, Hagai Bar-El wrote: Are there at all any open source FDE products for Win32? http://www.truecrypt.org/ -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: password strengthening: salt vs. IVs
On Mon, 29 Oct 2007 14:24:23 -0500 [EMAIL PROTECTED] wrote: > So back in the bad old days when hashing was DES encryption of the > zero vector with a fixed key, someone came up with salt as a password > strengthening mechanism. > > I'm not quite sure why it was called salt. > > It perturbed the S-boxes in DES IIRC, but essentially it was a known > bit of text that was an input to the algorithm that varied between > entries, like an IV does with encryption. > > If there isn't already a term for this, I'm going to call this > general concept "individuation", or possibly "uniquification". > > Nowadays with strong hash algorithms, but rainbow tables and > low-entropy passwords as the threat, I'm wondering what the best > practice is. > > I was thinking of simply prepending a block of text to each passphrase > prior to hashing, and storing it with the hash - similar to salts in > passwd entries. > > It should have at least as much entropy as the hash output, maybe a > little more in case there's collisions. If it were uniformly random, > you could simply XOR it with the passphrase prior to hashing and save > yourself some cycles, right? > > Would it be appropriate to call this salt, an IV, or some new term? That's an IV. I strongly suggest your read the Ritchie and Thompson paper on the reasons for the salt. While making sure that two identical passwords rarely hashed to the same value, it had another purpose: protecting against hardware attacks. Ritchie and Thompson assumed that there would be generic DES chips; they didn't want those to be used in a password-cracking machine. Accordingly, the salt was used to permute the E-box -- not the S-boxes -- to prevent that. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: password strengthening: salt vs. IVs
On Oct 30, 2007 6:24 AM, <[EMAIL PROTECTED]> wrote:
> So back in the bad old days when hashing was DES encryption of the
> zero vector with a fixed key, someone came up with salt as a password
> strengthening mechanism.
>
> I'm not quite sure why it was called salt.
>
> It perturbed the S-boxes in DES IIRC, but essentially it was a known
> bit of text that was an input to the algorithm that varied between
> entries, like an IV does with encryption.
>
> If there isn't already a term for this, I'm going to call this
> general concept "individuation", or possibly "uniquification".
>
> Nowadays with strong hash algorithms, but rainbow tables and
> low-entropy passwords as the threat, I'm wondering what the best
> practice is.
>
> I was thinking of simply prepending a block of text to each passphrase
> prior to hashing, and storing it with the hash - similar to salts in
> passwd entries.
well what you're describing is quite classically a salt, imho.
> It should have at least as much entropy as the hash output, maybe a
> little more in case there's collisions. If it were uniformly random,
> you could simply XOR it with the passphrase prior to hashing and save
> yourself some cycles, right?
well no. i mean to xor it (or probably what you mean: to otp it)
you'll need to have a "salt" who's length is equal to the input. that
would then mean that short inputs would result in short salts. i.e. a
password of "a" may result in the "salt" of "x". hash("a" ^ "x") is
hardly secure against a rainbow table.
so you're better off maintaining the salt in a separate location
(after all, the threat model is that someone takes the db and has a
list of all the hashes, and then calculates out the passwords) and
still prepend it on before the main passphase.
you may consider, however, that if this "salt" is as long as one block
of the input to the hash algorithm, it effectively becomes a new iv.
but what that has to do with anything; i don't know ...
> Would it be appropriate to call this salt, an IV, or some new term?
>
> --
> Life would be so much easier if it was open-source.
> http://www.subspacefield.org/~travis/> Eff the ineffable!
> For a good time on my UBE blacklist, email [EMAIL PROTECTED]
--
mike
http://lets.coozi.com.au/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
