Re: The perils of security tools
On 5/26/08, Simon Josefsson [EMAIL PROTECTED] wrote: For example, reading a lot of data from linux's /dev/urandom will deplete the entropy pool in the kernel, which effectively makes reads from /dev/random stall. The two devices uses the same entropy pool. That's a bug in the way the kernel hands out entropy to multiple concurrent consumers. I don't think it's a semantic issue. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On Sun, May 18, 2008 at 4:55 PM, Hal Finney [EMAIL PROTECTED] wrote: A simple trick can be used to help immunize DSA signatures against these kinds of failures. I first learned of this idea many years ago from Phil Zimmermann, and a varient has been used for a long time in PGP and probably other code, but aparently not OpenSSL. The idea is to base the random k not just on the output of your RNG, but also on the private key x. Something like: k = hash (x, rng()). Of course it is still necessary that k be uniformly distributed mod q (the DSA subgroup prime order), so this can't be just a straight hash. It might be a separate PRNG instance which gets seeded with the data values shown. But the idea is to mix in the secret key value, x, in addition to data from the RNG. I've used this idea before, although in the form of using the private key as part of the PRNG seed -- which isn't of much use if the PRNG ignores its seeding as in this case. However, even the form k = hash (x, rng()) isn't good enough if the PRNG is sufficiently broken. The Debian code generated an output that was not merely predictable, but also prone to repetition if you run a binary multiple times. With typically just 2^15 different byte streams from the PRNG, by the birthday paradox you'd have to expect to have been reusing some k after around 2^8 iterations or so. So your DSA key would still be at risk! You could also make k message-dependant -- i.e., feed both x and k into the hash function: k = hash (x, rng(), m) This avoids that problem, and is likely to remain unbreakable even if rng() returns just some constant. However, then you lose one advantage of DSA, namely being able to do most of the computation in advance, before you've even seen the message to be signed: If you've obtained k and done the DSA exponentiation beforehand, you can create signatures almost instantaneously; but this won't work if k depends on the message. Bodo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
Taral [EMAIL PROTECTED] writes: On 5/26/08, Simon Josefsson [EMAIL PROTECTED] wrote: For example, reading a lot of data from linux's /dev/urandom will deplete the entropy pool in the kernel, which effectively makes reads from /dev/random stall. The two devices uses the same entropy pool. That's a bug in the way the kernel hands out entropy to multiple concurrent consumers. I don't think it's a semantic issue. Do you have any references? Several people have brought this up before and have been told that the design with depleting the entropy pool is intentional. Still, the semantics of /dev/*random is not standardized anywhere, and the current implementation is sub-optimal from a practical point of view, so I think we are far away from an even OK situation. /Simon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: not crypto, but fraud detection + additional
Anne Lynn Wheeler wrote: *Irish Bank Debit Card Skimmers Net €1m* http://www.epaynews.com/index.cgi?survey=ref=browsef=viewid=121179135013743148197block= from above: Most of the withdrawals took place at the end of April and early May 2008. Many of the victims contacted their banks to notify them of the withdrawals, as the banks’ fraud detection systems had failed to spot the suspicious activity. I don't know what the policy is in Ireland, but here in the USA there is no stop loss on debit cards so the banks are not obligated to make good on fraudulent withdrawals. I believe that most have out of fear of bad PR, but you have to fight for it if it is just a few that it happens to. If this happens too much then people might stop using debit cards. I have advised my mother, 87, to not use them as she is getting a little slow on the uptake and might miss something like this if it happened to her. Now to show how screwy the system is, I was shopping the other day and the power went off in the grocery store I was at. They had backup power so they were able to check out people; however, they couldn't use debit cards, except Well, the screwy thing was if you entered the charge at terminal as a credit card, even when it was only a debit card, it would accept it. I checked my bank, and sure enough the charge showed as a POS charge! I think the logic is a little screwy and might be able to be exploited though I'm not sure how at the moment. Best, Allen - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
People's Army of Vietnam Cryptographic Branch History
I noted the following going back on Cryptome today: A History of the Cryptographic Branch of the People's Army of Vietnam, 1945-1975, with a supplement on Cryptography in the Border Guard (formerly the Armed Public Security Forces) 1959-1989 Translated and Edited by David W. Gaddy, Center for Cryptologic History, National Security Agency, 1994 http://www.ibiblio.org/pha/PAVN/ http://www.ibiblio.org/pha/PAVN/PAVN-crypto.pdf Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: not crypto, but fraud detection + additional
Allen wrote: I don't know what the policy is in Ireland, but here in the USA there is no stop loss on debit cards so the banks are not obligated to make good on fraudulent withdrawals. I believe that most have out of fear of bad PR, but you have to fight for it if it is just a few that it happens to. If this happens too much then people might stop using debit cards. I have advised my mother, 87, to not use them as she is getting a little slow on the uptake and might miss something like this if it happened to her. Now to show how screwy the system is, I was shopping the other day and the power went off in the grocery store I was at. They had backup power so they were able to check out people; however, they couldn't use debit cards, except Well, the screwy thing was if you entered the charge at terminal as a credit card, even when it was only a debit card, it would accept it. I checked my bank, and sure enough the charge showed as a POS charge! I think the logic is a little screwy and might be able to be exploited though I'm not sure how at the moment. in theory signature debit (i.e. debit transaction w/o PIN) and credit could both work ... since they both go thru the same way. pin-debit goes thru in real time and the merchant has assurance that the transaction has been approved (and pin authenticated). as a result, the interchange fee is much lower ... because the related risk/fraud is presumed to be much lower. signature debit and credit basically go thru the network the very same way. the machine (either the actual POS terminal or a store controller) remembers all the transactions and there is periodic batch settlement (end of shift, or end of day). Settled transaction may or may not have a separate, associated real time authorization transaction. The merchant pays extra charge for each real time authorization transaction (which tend to be credit card specific regarding whether the account is active and the new transaction is within the card's credit limit or open to buy). the associated interchange fee is lower on transactions with real time authorizations (presumably transactions with real time authorizations tend to have lower risk/fraud). However, transactions may also be settled w/o an associated real time authorization (which will have a higher interchange fee since there is presumption of higher risk/fraud). there are some old merchant small fraud stories ... where the merchant claimed in the settlement transaction to have a separate real time authorization ... when there wasn't one (they got both the lower interchange fee w/o actually having to pay for a real-time authorization transaction ... this was before some financial institutions had the ability to reconcile the information). All have associated risk/fraud ... one of the tricks is for the financial institution to appropriately adjust the interchange fee to cover the financial institutions associated risk. There has been recent congressional hearings, EU anti-trust actions and merchant complaints that the financial institutions have adjusted the interchange fees way over what is needed to cover the associated risk. There were snide articles that financial institutions are making significant profits off of the risk adjusted interchange fees. 2-3 yrs ago supposedly something like 40percent of US financial institution bottom line was coming from these (risk adjusted) interchange fees ... and for many retailers it represented their single largest expense. this is been highlighted in the significant expense going into TV spots to promote signature debit since the interchange fee and especially the profit is significantly higher (vis-a-vis pin-debit). some of this was discussed in the bank fraud blame game thread that went on in this mailing list last june, july ... my posts archived here. http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: not crypto, but fraud detection + additional
Allen writes: -+--- | I don't know what the policy is in Ireland, but here in the USA | there is no stop loss on debit cards so the banks are not | obligated to make good on fraudulent withdrawals. snip There is also a legal distinction between a personal credit card and a corporate card in terms of the regulated upper bound on the losses due to a stolen card and fraudulent charges on it, though the credit companies tend never to stand on their right to not rescind fraudulent charges on non-personal cards. Factoid: Had the $50 stop-loss limit been indexed for inflation, then it would today be $300. (1968-present) --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RIM to give in to GAK in India
Excerpt: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. http://economictimes.indiatimes.com/Telecom/Govt_may_get_keys_to_your_BlackBerry_mailbox_soon/articleshow/3041313.cms Hat tip: Bruce Schneier's blog. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
Quoting Perry E. Metzger [EMAIL PROTECTED]: Excerpt: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. http://economictimes.indiatimes.com/Telecom/Govt_may_get_keys_to_your_BlackBerry_mailbox_soon/articleshow/3041313.cms Hat tip: Bruce Schneier's blog. Wow, and April 1st was almost two months ago. This is just a bunch of FUD. If someone actually talked to RIM they would find out that it's technically impossible for them to do this because THEY DONT HAVE THE DEVICE KEYS. http://news.yahoo.com/s/afp/20080527/tc_afp/indiacanadacompanyrimblackberrytelecomsecurity Apparently even the security experts are suspect to sensationalism without appropriate research. I would have expected better. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: RIM to give in to GAK in India
Perry E. Metzger wrote on 27 May 2008 16:14: Excerpt: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. http://economictimes.indiatimes.com/Telecom/Govt_may_get_keys_to_your_BlackB erry_mailbox_soon/articleshow/3041313.cms Hat tip: Bruce Schneier's blog. Although on the other hand: Excerpt: Research In Motion (RIM), the Canadian company behind the BlackBerry handheld, has refused to give the Indian government special access to its encrypted email services. [ ... ] According to the Times of India, the company said in a statement: The BlackBerry security architecture for enterprise customers is purposefully designed to exclude the capability for RIM or any third party to read encrypted information under any circumstances. We regret any concern prompted by incorrect speculation or rumours and wish to assure customers that RIM is committed to continue serving security- conscious business in the Indian market. http://www.theregister.co.uk/2008/05/27/indian_gov_blackberry_blackball/ [ Hmm, two contradictory stories, whoever woulda thunk it? There's probably some politicking going on, mixed up with marketeering and FUD-spinning. ] cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
* Dave Korn: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. Research In Motion (RIM), the Canadian company behind the BlackBerry handheld, has refused to give the Indian government special access to ** its encrypted email services. [ ... ] According to the Times of India, the company said in a statement: The BlackBerry security architecture for enterprise customers is purposefully designed to exclude the capability for RIM or any third party to read encrypted information under any circumstances. We regret [ Hmm, two contradictory stories, whoever woulda thunk it? There's probably some politicking going on, mixed up with marketeering and FUD-spinning. ] If you look closely, there's no contradiction. Non-enterprise customers don't run their own gateway, so RIM just acts as a telco, which naturally has got access to all the data. The Indian government doesn't need special access, either, because Lawful Intercept services etc. aren't that special anymore. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
Isn't this just a semantic game on the part of RIM and the government? The phrase enterprise customers would seem to isolate a class of customers such that individual customers not using a corporate version of the product would see their crypto weakened... and be subject to monitoring through the service provider On May 27, 2008, at 12:21 PM, Dave Korn wrote: Perry E. Metzger wrote on 27 May 2008 16:14: Excerpt: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. http://economictimes.indiatimes.com/Telecom/Govt_may_get_keys_to_your_BlackB erry_mailbox_soon/articleshow/3041313.cms Hat tip: Bruce Schneier's blog. Although on the other hand: Excerpt: Research In Motion (RIM), the Canadian company behind the BlackBerry handheld, has refused to give the Indian government special access to its encrypted email services. [ ... ] According to the Times of India, the company said in a statement: The BlackBerry security architecture for enterprise customers is purposefully designed to exclude the capability for RIM or any third party to read encrypted information under any circumstances. We regret any concern prompted by incorrect speculation or rumours and wish to assure customers that RIM is committed to continue serving security- conscious business in the Indian market. http://www.theregister.co.uk/2008/05/27/indian_gov_blackberry_blackball/ [ Hmm, two contradictory stories, whoever woulda thunk it? There's probably some politicking going on, mixed up with marketeering and FUD-spinning. ] cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The perils of security tools
On Mon, May 26, 2008 at 11:22:18AM +0200, Simon Josefsson wrote: For example, reading a lot of data from linux's /dev/urandom will deplete the entropy pool in the kernel, which effectively makes reads from /dev/random stall. The two devices uses the same entropy pool. I believe a much better approach would be if /dev/urandom was a fast and secure PRNG, with perfect-forward-secrecy properties, and /dev/random was a slow device with real entropy (whatever that means..) gathered from the hardware. The two devices would share little or no code. The /dev/urandom PRNG seed could be fed data from /dev/random from time to time, or from other sources (like kernel task switching timings). I believe designs like this have been proposed from time to time, but there hasn't been any uptake. My understanding of the situation is that the way you get secure use of a PRNG is by feeding it real entropy, and the way you get fast use of a PRNG is by feeding it whatever seeds you have on-hand, regardless of real randomness -- or just don't feed it any seeds at all, if you don't have any on-hand. Thus, the reason /dev/urandom is fast is that it doesn't actually *require* real entropy, and the reason /dev/random is cryptographically secure is that it *does* require real entropy, which of course means that it slows down a lot when you run out of real entropy in the pool. Assuming I am not mistaken in my understanding of the operation of the two randomness devices, you could probably get reasonable security and speed overall for /dev/urandom by limiting how quickly and often it accesses the entropy pool, hitting it once in a while at (pseudo)random intervals within a reasonable range to seed the PRNG. This would make it fast unless you're taxing the entropy pool so badly with multiple processes using /dev/urandom or some /dev/random use that there literally is no entropy left in the pool for /dev/urandom to use at all when it tries to hit the pool. It would not provide perfect forward secrecy, however, because there would be brief intervals (between hits to the entropy pool) during which knowing the PRNG algorithm and its current state would allow someone to predict further PRNG output until the end of the current entropy interval. The length of the interval, however, could conceivably be (effectively) unknowable. Ultimately, I think the reason nobody has implemented a /dev/urandom that allows for fast, secure PRNG operation with perfect forward secrecy is that it's kind of a pick n-1 situation, such as with the old saw, Fast good, cheap; pick two. To get cryptographically strong randomness, you need entropy, which taxes the entropy pool. An additional entropy pool would need more places to *get* entropy, of course. Essentially, giving the characteristics of cryptographically useful randomness and perfect forward secrecy to /dev/urandom would ultimately mean you turned it into a duplicate of /dev/random. It looks like you're suggesting just changing the way /dev/urandom receives its entropy so that it happens periodically, similarly to how I described limiting it from exhausting the entropy pool above -- but that won't solve the problem of giving /dev/urandom strong security and perfect forward secrecy characteristics. . . . or is there something I missed? -- Chad Perrin [ content licensed PDL: http://pdl.apotheon.org ] Baltasar Gracian: A wise man gets more from his enemies than a fool from his friends. pgp0tGmcL1okT.pgp Description: PGP signature
RE: RIM to give in to GAK in India
Florian Weimer wrote on 27 May 2008 18:49: * Dave Korn: In a major change of stance, Canada-based Research In Motion (RIM) may allow the Indian government to intercept non-corporate emails sent over BlackBerrys. Research In Motion (RIM), the Canadian company behind the BlackBerry handheld, has refused to give the Indian government special access to ** its encrypted email services. [ ... ] According to the Times of India, the company said in a statement: The BlackBerry security architecture for enterprise customers is purposefully designed to exclude the capability for RIM or any third party to read encrypted information under any circumstances. We regret [ Hmm, two contradictory stories, whoever woulda thunk it? There's probably some politicking going on, mixed up with marketeering and FUD-spinning. ] If you look closely, there's no contradiction. Well spotted. Yes, I guess that's what Jim Youll was asking. And I should have said seemingly-contradictory. This is, of course, what I meant by marketeering: when someone asks if your service is insecure and interceptable, you don't say Yes, our ordinary service will give you up to the filth at the drop of a hat, you spin it as No, our enterprise service is completely secure [...other details elided...]. cheers, DaveK -- Can't think of a witty .sigline today - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: RIM to give in to GAK in India
On Tue, May 27, 2008 at 08:08:11PM +0100, Dave Korn wrote: Well spotted. Yes, I guess that's what Jim Youll was asking. And I should have said seemingly-contradictory. This is, of course, what I meant by marketeering: when someone asks if your service is insecure and interceptable, you don't say Yes, our ordinary service will give you up to the filth at the drop of a hat, you spin it as No, our enterprise service is completely secure [...other details elided...]. But this is not news. It is well known (at least among the Enterprise Remote Computing wonks) that only the Enterprise RIM service provides end-to-end security, while the consumer service does not. There is nothing new here. It is not even marketing spin, without your IT shop hosting your content, it is hosted by providers subject to CALEA, ... The good news about RIM is that it has been one of the few devices that actually provides end-to-end security for Enterprises. This has been a selling point that helped get them a large share of the Enterprise market. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
