Re: Windows guru requested - Securing Windows
Peter Fairbrother wrote: > Bot from CD, create a memory FS, union mount it to the main windows fat-32 > FS, with the fat-32 fs mounted read-only, boot Windows? That way any changes > to the files would be wiped out when the power was switched off, and the > fat-32 fs would remain untouched. I don't quite understand this. The concept of mounting a FS is an OS operation, so to say "mount the FS read-only and then boot the OS" is nonsensical. If taking the Linux live CD route isn't acceptable, your best bet would be to start looking at something like BartPE: http://www.nu2.nu/pebuilder/ You might want to contact Bart directly (http://www.nu2.nu/contact/bart/) and ask him for advice on how to proceed. -- Ivan Krstic <[EMAIL PROTECTED]> | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
-- Anne & Lynn Wheeler wrote: > part of x9.59 retail payment standard requires the > transaction to be authenticated. another part of the > x9.59 retail payment standard requires that the > account number in x9.59 retail payments can't be used > in non-authenticated transactions. it as been > recognized for a long time that a major source of > account financial fraud has been the data breaches > http://www.garlic.com/~lynn/subpubkey.html#harvest Have any merchants adopted the X9.59 standard? Is it in fact possible for a merchant to today take orders over X9.59? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG SCLw5bENxW3GhAPjMCCFxAZNTWWplgH3XHfzZejK 4wUo1x4tRVdskoDX1ZgiomicCYwgwFPLepwR04i2a - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of attacks on AES?
Right. But can you explain *why* you strongly believe in it? In the last 10 years it never failed to tell the difference between good and bad ciphers. The only thing that makes it controversial is its ability to detect flaws in ciphers believed to be strong simply because no attacks against them are found yet. We do not believe in the approach "if no one broke it in N years, then accept it as secure until they do" alone. We believe in combining it with studying algebraic structure of the resulting functions from every angle with automated tools, and if they display obvious sparsity or patterns in the distribution of monomials of any algebraic degree, or if the size/output or size/security proportions are too low, or if too many rounds are required for a change to make those functions different in a way indistinguishable from random (slow avalanche of change as we see it), the cipher should be discarded even if no one can find a way to break it. Here's an example: replace XOR with ADD in RC5 and try to attack it by any means other than the Mod N attack found years after RC5... But our tests immediately show that the cipher is easily breakable. They also immediately show weakness of the first two bytes in RC4 and breakability of such ciphers as A5, LILI, etc. The list can go on and on. Often there is no explanation for years until an attack is found, but our tests help us detect presence of flaws in seemingly strong ciphers in a matter of minutes. I personally do not bother analysing ciphers that fail our tests - someone else will break them sooner or later anyway. I immediately discard them as breakable and concentrate on the hard ones to see if the cipher structure needs to be addressed. But if the cipher doesn't have any odd components that it relies on and that can be attacked individually and if its proportions are chosen correctly, I accept it as secure. The fact that Rijndael fails our tests so terribly prohibits me personally from trusting it even though no attack breaking it has been published. I would use Twofish or RC6 instead. Passing our tests combined with years of public scrutiny makes me believe that Twofish and RC6 can be trusted. Rijndael cannot. Ruptor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Windows guru requested - Securing Windows
Today the UK Home Office announced the public consultation on the Code of Practice of Part 3 of RIPA. This is the first stage of the process by which it can be brought into force. Part III of RIPA is the "policeman-say-gimme-all-your-keys-or-go-to-jail-(and-don't-tell-anybody)" law passed 6 years ago but not yet brought into force. With the advent of GAK in the UK looking more and more likely, I am ramping up the m-o-o-t project ( http://www.m-o-o-t.org , but the website is woefully out-of-date and the final form of the project may be rather different to that described therein), which has been dormant for some time. m-o-o-t's goal is to provide even the dumbest luser with the tools to avoid and evade demands for keys in such a way that it is very hard for them to mess up and to anything insecurely. This will be either for free or at very low cost (might do something with a USB stick which the user would have to buy, but not from us - software will be free). In a preliminary search for alternatives, I am seeking an answer to this question. I know very little about Windows beyond that many people use it and that source is not available, so be gentle with me please. In an attempt to partially secure Windows for temporary use, ie when it's being temporarily used in "secure mode", and to prevent data being stored in softwarekeylogger, temp and swap files, would something like the following be possible? Bot from CD, create a memory FS, union mount it to the main windows fat-32 FS, with the fat-32 fs mounted read-only, boot Windows? That way any changes to the files would be wiped out when the power was switched off, and the fat-32 fs would remain untouched. Mount a steganographic FS read/write on eg a USB key (or a different partition) on / with a hard-to-guess name. Secret files should be saved to this fs. Thanks, -- Peter Fairbrother [EMAIL PROTECTED] http://www.m-o-o-t.org Moderated mailing list: [EMAIL PROTECTED] Notification of release: blank email to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
On Wed, 7 Jun 2006, John Brazel wrote: > What we really need is something similar to the built-in "remember > my password" functionality of current web browsers: the browser keeps > track of a login/password/certified (ie TLS certificate-backed) DNS name > tuple... [...] > The downside, of course, is that: > > a) It wouldn't handle password changing, > b) Some people use the same login and password *everywhere*, > c) Once you change browsers or computers, all bets are off (because the > new browser doesn't know anything about which passwords you use where). If you haven't looked at this yet, i think you'll find it interesting: http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/ These design ideas are intended to address exactly the things you've just mentioned. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: U. Washington Crypto Course Available Online For Free
No cryptographers at UW? I think Neil Koblitz would disagree with that: http://www.math.washington.edu/~koblitz/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John R. Black Sent: Tuesday, June 06, 2006 7:35 PM To: cryptography@metzdowd.com Subject: Re: U. Washington Crypto Course Available Online For Free On Tue, Jun 06, 2006 at 01:57:25AM -0700, Udhay Shankar N wrote: > http://it.slashdot.org/article.pl?sid=06/06/04/1311243 > It is taught by good people, but I find it a bit strange they are all Microsoft employees. This is perhaps because U. Wash doesn't have any cryptographers. That changes in the fall: they hired an excellent young cryptographer named Yoshi Kohno. == Prof. John R. Black www.cs.colorado.edu/~jrblack Computer Science 430 UCB [EMAIL PROTECTED] University of Colorado Office: +1-303-492-0573 Boulder, CO 80309 USA Fax: +1-303-492-2844 - 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: UK Detects Chip-And-PIN Security Flaw
re: http://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw http://www.garlic.com/~lynn/2006l.html#32 Google Architecture as i mentioned, the x9a10 financial standards working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments this included at least all kinds of internet, all kinds of POS, and all kinds of payments (debit, credit, stored-value, etc). part of the resulting x9.59 financial standard was transaction authentication. session authentication had been looked at, and it was felt (compared to transaction authentication) it was much more vulnerable to end-point threats, mitm threats, as well as insider threats. from at least some retailers comments that chip&pin wasn't appropriate for internet transactions ... it might be implied that chip&pin does session-like (as opposed to transaction) authentication ... regardless of whether it is SDA or DDA (possibly making it vulnerable to some of the end-point threats, mitm threats, and/or insider threats considered by the x9a10 financial standard effort). UK Detects Chip-And-PIN Security Flaw http://www.cardtechnology.com/article.html?id=20060606I2K75YS using the x9.59 transaction authentication paradigm, i had started on the aads chips strawman. http://www.garlic.com/~lynn/x959.html#aads at the NISSC conference in 98, i had quiped that I was going to take a mil-spec security token, cost reduce it by two orders of magnitude while increasing its security. in a chip&pin reference this met having a chip doing "DDA" at higher integrity than the chip&pin DDA chip ... but at lower cost than the chip&pin SDA chip. The aads chip strawman also needed to be able to do x9.59 transaction authentication within iso14443 contactless power profile and within the transit industry turnstyle timing requirements. a number of aads strawman chips were demonstrated in dec. 1999 at the world-wide retail banking show in miami, authenticating a variety of different kinds of financial and non-financial transactions. i gave a presentation on assurance at the 2001 intel developer's forum (in the tpm track). I happened to quip during the presentation that it was nice to see that the TPM chip design had started to look more and more like the aads chip strawman over the previous year or so. the guy leading the TPM chip effort was in the front row and quiped back that it was because i didn't have a committee of 200 people helping me with my design. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
UK Detects Chip-And-PIN Security Flaw
UK Detects Chip-And-PIN SecurityFlaw http://www.cardtechnology.com/article.html?id=20060606I2K75YSX APACS says the security lapse came to light in a recent study of the authentication technology used in the UK's new "chip-and-PIN" card system. ... snip ... this was documented as the "yes card" in 2002 regarding chip&pin rollouts that had been done in the 99-2002 time-frame since the "yes card" vulnerability is an attack against the pos terminal (not the card) ... and since the vulnerability is part of the standard ... even if all new cards were rolled w/o the "fix" ... the infrastructure might still be vulnerable if POS terminals could be convinced to communicate using the vulnerable standard (this is somewhat analogous to attacker attacking protocols and convincing parties to downgrade to lower encryption). misc. posts discussing the "yes card" vulnerability as well as mentioning possible man-in-the-middle attack against the fix for "yes card" vulnerability. http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM? http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News http://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10) http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10) http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10) http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10) http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10) http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"? http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants] http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram http://www.garlic.com/~lynn/2004j.html#39 Methods of payment http://www.garlic.com/~lynn/2004j.html#44 Methods of payment http://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind? http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing" http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message? http://www.garlic.com/~lynn/2006k.html#1 Passwords for bank sites - change or not? http://www.garlic.com/~lynn/2006l.html#27 Google Architecture - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
James A. Donald wrote: The concept of trusted computing is an attempt to address this problem - each application has exclusive access to certain data, a trusted path to interact with the user, and the ability to prove to servers what code is being executed on the client. so they aren't exactly unrelated. re: http://www.garlic.com/~lynn/aadsm23.htm#45 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#53 Status of SRP the financial standards x9a10 working group had been given the requirement to preserve the integrity for all retail payments. the result was the x9.59 payment standards for all retail payments. http://www.garlic.com/~lynn/x959.html#x959 part of x9.59 retail payment standard requires the transaction to be authenticated. another part of the x9.59 retail payment standard requires that the account number in x9.59 retail payments can't be used in non-authenticated transactions. it as been recognized for a long time that a major source of account financial fraud has been the data breaches http://www.garlic.com/~lynn/subpubkey.html#harvest and resulting fraudulent use of account numbers ... this is somewhat my old posting on security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 in effect, account numbers have been overloaded. on one hand, knowledge of account numbers have been sufficient for doing fraudulent transactions. as a result they have to be treated as shared secrets, kept confidential and never divulged. on the other hand, account numbers are required in a large number of business process as the fundamental cornerstone for transaction execution ... and are required to be widely available. as a result of these totally opposing requirements, i've periodically observed that the planet could be buried under miles of cryptography used in hiding account number, and it would still be unable to prevent leakage of account numbers. the x9.59 business rule recognizes this and changes the paradigm, eliminating the severe financial fraud vulnerability associated with divulging account numbers (and/or data breaches involving account numbers). another part of x9.59, in addition to providing for transaction digital signature as part of transaction authentication (and trying to close some of the barn door with the overloaded requirements placed on account numbers) was allowing for a second digital signature by the environment that the transaction originated in. this would provide the relying party additional information for performing risk assessment related to authorizing the transaction. so later when this software company wanted to come up with something for content providers, they hired the chair of the x9a10 financial standards working group to move to redmond to be director of development. for other drift on trusted computing ... there are capability based operating systems ... current example is capros ... which was spawned from eros, which was sort of spawned from keykos, which was spawned from gnosis ... recent post mentioning some capros, eros, keykos, gnosis, et all (and other related lore regarding secure and/or capability-based operating systems ... going back to deployments by commercial time-sharing service bureaus in the late 60s and their connections to some of the current efforts ... as well as connections to what i was doing as an undergraduate in the 60s) http://www.garlic.com/~lynn/2006k.html#37 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: U. Washington Crypto Course Available Online For Free
At 20:34 -0600 2006/06/06, John R. Black wrote: On Tue, Jun 06, 2006 at 01:57:25AM -0700, Udhay Shankar N wrote: > http://it.slashdot.org/article.pl?sid=06/06/04/1311243 It is taught by good people, but I find it a bit strange they are all Microsoft employees. This is perhaps because U. Wash doesn't have any cryptographers. I hardly think that you can discount the skills of Josh Beneloh and Brian LaMacchia. That changes in the fall: they hired an excellent young cryptographer named Yoshi Kohno. Damn, I was trying to hire Yoshi... Greg. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
RE: Status of attacks on AES?
> Good, bad, right, wrong, correct, incorrect, meaningful, meaningless... Who > knows? Don't ask us. We are simply trying to contribute something new that > we strongly believe in Right. But can you explain *why* you strongly believe in it? William - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
Jeffrey Altman wrote: Solving the phishing problem requires changes on many levels: (1) Some form of secure chrome for browsers must be deployed where the security either comes from a "trusted desktop" or by per-user customizations that significantly decrease the chances that the attacker can fake the web site experience. (Prevent the attacker from replicating the browser frame, toolbars, lock icons, certificate dialogs, etc.) (2) Reducing the number of accounts and passwords (or other identifiers) that end users need to remember. With a separate identifier for each and every web site it is no surprise that my extended family can never remember what was used at each site. Therefore, it is not much of a surprise when a site says that the authentication failed. (3) Secure mechanisms must be developed for handling enrollment and password changing. What we really need is something similar to the built-in "remember my password" functionality of current web browsers: the browser keeps track of a login/password/certified (ie TLS certificate-backed) DNS name tuple, and if it ever spots the user entering said login/password into a different website, brings up some form of dialog alerting the user to a potential phishing attack. The downside, of course, is that: a) It wouldn't handle password changing, b) Some people use the same login and password *everywhere*, c) Once you change browsers or computers, all bets are off (because the new browser doesn't know anything about which passwords you use where). J. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
