Re: [Cryptography] Snowden "fabricated digital keys" to get access to NSA servers?
On Sat, 29 Jun 2013, Alec Muffett wrote:
> My own, personal guess is that it is obfuscation which translates as "using
> passwords" or "accessing a portal over SSL" plus "we're too embarrassed to
> admit that it was that easy".
Or simply:
http://cms.intranet.boozallen.com/document?id=${N}
http://cms.intranet.boozallen.com/document?id=${N + 1}
etc.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
Re: Why the onus should be on banks to improve online banking security
On Fri, 20 Nov 2009, Peter Gutmann wrote: > There's been a near-neverending debate about who should be responsible for > improving online banking security measures: the users, the banks, the > government, the OS vendor, ... . Here's an interesting perspective from Peter > Benson , reposted with permission, on why the onus > should be on banks to provide appropriate security measures: > > One of the main reasons to target the banks with accountability is "because > you can". There is a lot of historical regulation and controls around > banking, which makes it *relatively* easy to hold them to account. The > bigger problem, and the next logical step, is how the banks hold suppliers / > vendors of software accountable for flaws in their systems and software that > enable the problems to occur in the first place. > > Anyone recognise the following? > > "This software is provided as is, and any expressed or implied warranties, > including, but not limited to, the implied warranties of merchantability and > fitness for a particular purpose are disclaimed. In no event shall the > contributors be liable for any direct, indirect, incidental, special, > exemplary, or consequential damages (including, but not limited to, > procurement of substitute goods or services; loss of use, data, or profits; > or business interruption) however caused and on any theory of liability, > whether in contract, strict liability , or tort (including negligence or > otherwise) arising in any way out of the use of this software, even if > advised of the possibility of such damage." > > Accountability is great, and I fully support it, and would like to somehow > find the way to push a level of accountability back to various software > developers / manufacturers. Unfortunately in the current state of Contract > and Tort law, there is so much protection(ism) of the software industry, > that its still going to be time consuming and expensive to get a couple of > decent case studies out there or to change anything. So from a public good > perspective, unfortunately (realistically), it is the banks that should > carry the onus. It is a lazy argument that the banks should be held responsible just because it is easy to regulate them. Moreover, it seems like magical thinking that they would then suddenly start demanding liability warranties from their software vendors. For a start, it is probable that the majority of the problems are in their clients' software and not the banks', so demanding liability insurance would from banking software vendors would have little effect. Furthermore, the cost of liability warranties may well be less than the cost of fraud. Also, exactly how is second paragraph of the BSD license evidence of protection(ism) of the software industry? It seems like no-liability is an equilibrium that the software market has settled to without assistance from government - is there evidence to the contrary? A much better argument for the banks being responsible for the security of customers' money is that this is exactly what we pay them for. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
On Mon, 14 Sep 2009, Peter Gutmann wrote: > Damien Miller writes: > > >The seems unlikely, since we don't use OpenSSL for AES-CTR in OpenSSH. I > >don't think OpenSSL even supports a CTR mode through its EVP API. > > I first saw it reported on the Putty bugs list [0], a good place to track > interop problems with implementations since it's so widely used, which in turn > points to https://bugzilla.mindrot.org/show_bug.cgi?id=1291: Actually, I'm half-wrong (or half-right) - there was a bug in OpenSSL, just not in AES-CTR specifically. It was a mildly obscure bug in the EVP interface that showed up when plugging in one's own ciphers. We now have automated interop regression tests againt PuTTY to catch this sort of thing... -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: RNG using AES CTR as encryption algorithm
On Wed, 9 Sep 2009, Peter Gutmann wrote: > I was just going to reply with a variation of this, if you're implementing a > full protocol that uses AES-CTR (or any algorithm/mode for that matter), find > other implementations that do it too and make sure that you can talk to them. > In theory everyone could end up implementing it wrong, but that's somewhat > unlikely. > > (This has already caught AES-CTR implementation bugs in the past, for example > one particular version of OpenSSL 0.9.8 got AES-CTR keying wrong and it was > noticed when SSH users couldn't connect to OpenSSH servers using this mode). The seems unlikely, since we don't use OpenSSL for AES-CTR in OpenSSH. I don't think OpenSSL even supports a CTR mode through its EVP API. Any mistakes in implementing CTR mode in OpenSSH are therefore our own. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Tue, 16 Dec 2008, mhey...@gmail.com wrote: > On Thu, Dec 11, 2008 at 8:42 PM, Damien Miller wrote: > > On Thu, 11 Dec 2008, James A. Donald wrote: > > > >> If one uses a higher resolution counter - sub > >> microsecond - and times multiple disk accesses, one gets > >> true physical randomness, since disk access times are > >> effected by turbulence, which is physically true > >> random. > > > > Until someone runs your software on a SSD instead of a HDD. Oops. > > > Before we give up on using drive timings, does anyone have evidence to > verify this assertion? The reviews I have seen using tools like HD > Tune and HD Tach seem to show timing noise reading and writing SSDs. I > don't know where the noise comes from - it is probably not turbulence > - but it may be random enough that a long series of tests, say > for a second or so (don't forget, these drives are fast), could > provide a nice pool of unguessable bits. I think you have it quite backwards - in the absence of good evidence that transaction timings on SSDs are dependent on some physically unpredictable process (air turbulence, shot noise, etc.) then they should not be considered suitable for cryptographic use, no matter how "random looking" they are. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: CPRNGs are still an issue.
On Thu, 11 Dec 2008, James A. Donald wrote: > If one uses a higher resolution counter - sub > microsecond - and times multiple disk accesses, one gets > true physical randomness, since disk access times are > effected by turbulence, which is physically true > random. Until someone runs your software on a SSD instead of a HDD. Oops. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: street prices for digital goods?
On Thu, 11 Sep 2008, Peter Gutmann wrote: > David Molnar <[EMAIL PROTECTED]> writes: > > >Dan Geer's comment about the street price of heroin as a metric for > >success has me thinking - are people tracking the street prices of > >digital underground goods over time? > > I've been (very informally) tracking it for awhile, and for generic > data (non- Platinum credit cards, PPal accounts, and so on) it's > essentially too cheap to meter, you often have to buy the stuff in > blocks (10, 20, 50 at a time) to make it worth the sellers while. At such cheap prices, it must be close to the point where it would be worth it for the the card issuers to buy the numbers as a loss mitigation measure. -d - 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: Password hashing
On Thu, 11 Oct 2007, james hughes wrote: > I forgot to add the links... > http://people.redhat.com/drepper/sha-crypt.html > http://people.redhat.com/drepper/SHA-crypt.txt > > On Oct 11, 2007, at 10:19 PM, james hughes wrote: > > > A proposal for a new password hashing based on SHA-256 or SHA-512 has been > > proposed by RedHat but to my knowledge has not had any rigorous analysis. > > The motivation for this is to replace MD-5 based password hashing at banks > > where MD-5 is on the list of "do not use" algorithms. I would prefer not to > > have the discussion "MD-5 is good enough for this algorithm" since it is not > > an argument that the customers requesting these changes are going to accept. Some comments: * Use of an off-the-shelf algorithm like SHA1 might be nice for "tick here for FIPS certification", but they render the hashing scheme more vulnerable to dictionary attacks assisted by (near-)commodity hardware. Contrast with OpenBSD's blowfish scheme, which is deliberately designed to not be implementable using off-the-shelf crypto accelerator chips. * Hideously obfuscated and overcomplicated. Comments like those on step 11 of the algorithm (some mumbo jumbo about a completely deterministic step "adding randomness") and the absence of any rationale for the complexity seem to indicate that they believe a complicated design will somehow thwart attacks by itself. * Why specify the number of rounds directly? Most password and KDF schemes use an exponential scheme to match Moore's law. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Scare tactic?
On Wed, 19 Sep 2007, Nash Foster wrote: > http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/ > > Any actual cryptographers care to comment on this? I don't feel > qualified to judge. I "discovered" this minor weakness in most of the open source IPSec implementations in May of last year (identical checks for degenerate exponents are actually recommended in RFC2142 section 2.3.1.1). It didn't seem like this weakness could be used for much - an evil IKE endpoint could use it to force disclosure of symmetrically encrypted exchanges that were keyed from DH, but such an endpoint has a myriad of other ways they could disclose this same information. Protocols that do not perform authentication after DH (e.g. Tor) get bit much harder though. Anyway, I fixed OpenBSD's isakmpd[1], tighened the checks in OpenSSH[2] and reported the problem to the security contacts of ipsec-tools/racoon and openswan (two other open source IKE implementations). Racoon and openswan never bothered bother to fix it despite me sending a patch for racoon at least. I recall a rather bizarre conversation with an openswan developer who said he would only accept a patch if I wrote him a testcase to go with it. OTOH Racoon/ipsec-tools would benefit from the extra sanity checks that Ben Laurie added to OpenSSL for the 0.9.8a release[3], assuming it was compiled against that version or later. -d [1] http://marc.info/?l=openbsd-cvs&m=114675357804837&w=2 [2] http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/dh.c.diff?r1=1.35&r2=1.36 [3] http://cvs.openssl.org/chngview?cn=14375 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Another Snake Oil Candidate
On Tue, 11 Sep 2007, Aram Perez wrote: > The IronKey appears to provide decent security while it is NOT plugged into a > PC. But as soon as you plug it in and you have to enter a password to unlock > it, the security level quickly drops. This would be the case even if they > supported Mac OS or *nix. > > As I stated in my response to Jerry Leichter, in my opinion, their marketing > department is selling snake oil. It protects against the common threat model of lost/stolen USB keys. Why is this snake oil? Your criticism seems akin to calling a physical lock insecure because it doesn't protect you from burglars once you have unlocked it. -d - 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 Thu, 18 Jan 2007, Saqib Ali wrote: > Since when did AES-128 become "snake-oil crypto"? How come I missed > that? Compusec uses AES-128 . And as far as I know AES is NOT > "snake-oil crypto" It is even easier to use a good cryptographic transform in a way that is utterly insecure then it is to come up with a secure-looking-but-broken transform. How does this company apply AES-128 to the task of encrypting disk sectors? There are lots of ways to do it, many of them wrong. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Can you keep a secret? This encrypted drive can...
On Mon, 30 Oct 2006, Saqib Ali wrote: > http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2006/10/30/BUGU2M1ETT1.DTL&type=printable > http://www.theglobeandmail.com/servlet/story/RTGAM.20061030.wharddrive1029/BNStory/Front/?page=rss&id=RTGAM.20061030.wharddrive1029 > http://www.infoworld.com/article/06/10/30/HNseagateagain_1.html Who's secrets will they be keeping? Disk encryption and Object-based storage (where the filesystem is basically pushed down closer to the storage device, cf [1]) could be used to provide building blocks for stronger DRM. -d [1] http://dl.alphaworks.ibm.com/technologies/osdsim/osdsim2.pdf - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Spammer using Graphical Steganography
On Mon, 23 Oct 2006, Bill Stewart wrote: > Spammers have been including images in their email to evade anti-spammers. > Anti-spammers have been using OCR to identify spammy words in images. > Spammers have recently come up with tricks to work around OCRs, > by doing steganography with animated GIF images. > One approach they're taking is to build the real image progressively, > first drawing a background, then drawing parts of the image > (one spammer uses transparent pixels to do parts of it, showing dark parts of > background), > then waiting a long time and drawing a blank page in case anything's checking > the final image. IMO this isn't stego, more like a CAPCHA. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Exponent 3 damage spreads...
On Fri, 15 Sep 2006, Jostein Tveit wrote:
> [EMAIL PROTECTED] (Peter Gutmann) writes:
>
> > What's more scary is that if anyone introduces a parameterised hash
> > (it's quite possible that this has already happened in some fields,
> > and with the current interest in randomised hashes it's only a
> > matter of time before we see these anyway) [...]
>
> Both Rivest and Shamir said that they want a parameterised hash
> according to Paul Hoffman's "Notes from the Hash Futures Panel".
> http://www.proper.com/lookit/hash-futures-panel-notes.html >
Having a standard parametised hash function does not necessitate that
ASN.1 instances of their output have to be parametised too. IMO it
would make more sense to pick a progression of sizes similar to
SHA{1,256,...}
-d
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: compressing randomly-generated numbers
On Wed, 9 Aug 2006, Travis H. wrote: > Hey, > > I was mulling over some old emails about randomly-generated numbers > and realized that if I had an imperfectly random source (something > less than 100% unpredictable), that compressing the output would > compress it to the point where it was nearly so. Would there be any > reason to choose one algorithm over another for this application? What are you trying to achieve? An ARC4 keystream derived from fixed key is 100% predictable and yet cannot be compressed by anything you would normally call a "compression algorithm". -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: SSL Cert Prices & Notes
On Mon, 7 Aug 2006, John Gilmore wrote: > Here is the latest quick update on SSL Certs. It's interesting that > generally prices have risen. Though ev1servers are still the best commercial > deal out there. > > The good news is that CAcert seems to be posistioned for prime time debut, > and you can't beat *Free*. :-) Startcom (http://cert.startcom.org/) also does free "low assurance" certificates. Their CA has already been accepted for the next major release of the Mozilla products and, unlike CAcert, has undergone an independent audit. See also http://www.hecker.org/mozilla/ca-certificate-list for Mozilla's list of CAs and their status. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: A weird macro virus story
John Kelsey wrote: > Guys, > > Some of my co-workers here at NIST got an email macro virus which > appeared to be targeted to cryptographers. It appeared to be > addressed to Moti Yung, and come from Lawrie Brown and Henri Gilbert > (though that name was misspelled, maybe a transcription error from an > alternate character set). Did any of you notice something like this? > The email appeared to be addressed to several submission addresses for > various crypto conferences. How do you know it was targeted and not just following the common email virus/worm propagation behaviour of mining email contact lists and mailboxes on victims' machines? Typically these malware forge both sender and recipient addresses, and if both happen to be mined from (say) a mailbox containing an archive of the cryptography@metzdowd.com mailing list then the recipient will likely recognise the sender's name. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Zfone and ZRTP :: encryption for voip protocols
On Wed, 15 Mar 2006, Ed Gerck wrote: > cybergio wrote: > > > > Zfone :: http://www.philzimmermann.com/EN/zfone/index.html > > "...it achieves security without reliance on a PKI, key certification, > trust models, certificate authorities, or key management..." > > Good. But, uf course, there's a trust model and you need to rely on it. Points to them for making it explicit. > "...allows the detection of man-in-the-middle (MiTM) attacks by > displaying a short authentication string for the users to read and > compare over the phone." > > Depends on the trust model. May not work. This is incomplete. The paragraph goes on to say: > we still get fairly decent authentication against a MiTM attack, based > on a form of key continuity. It does this by caching some key material > to use in the next call, to be mixed in with the next call's DH shared > secret, giving it key continuity properties analogous to SSH. The SSH trust model has certainly proved itself as useful, and is probably perfectly appropriate for semi-adhoc telephony where voice nuance offers an additional means of detecting phonies (pun!). The screenshot on that page seems to indicate only three [a-z0-9] characters form the "key fingerprint". My first impression was that this was insufficient, but it is probably a good tradeoff. It is short enough that people will actually use it, and an attacker might only get a couple of tries of getting it wrong (in a 2^15 bit space) before a human would be very suspicious. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificates
James A. Donald wrote: > -- > Has anyone been attacked through a certificate that > would not have been issued under stricter security? The > article does not mention any such attacks, nor have I > ever heard of such an attack. How much money does a phishing site make before it is forced to close? (and change its cert) Would it be greater or less than the cost of a HA cert? If browser vendors make UI changes to indicate the presence of a HA cert to users (some are apparently considering changing the URL bar green), and users trust HA certs more as a result, then that increases their value when used in a scam. It isn't too much of a stretch of the imagination that phishers would go to the trouble of registering companies and forging enough of financial record to meet the higher assurance standards if it would make users more credulous of their site. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Crypto and UI issues
David Mercer wrote: > And my appologies to Ben Laurie and friends, but why after all these > years is the UI interaction in ssh almost exactly the same when > accepting a key for the first time as overriding using a different one > when it changed on the other end, whether from mitm or just a > key/IP/hostname change? Untrue, something which a moment's checking would have revealed. A brand new key requires user acceptance: > The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established. > RSA key fingerprint is f2:42:df:b2:6e:1b:8a:ac:96:27:6d:8c:b9:e6:93:a1. > No matching host key fingerprint found in DNS. > Are you sure you want to continue connecting (yes/no)? no > Host key verification failed. A changed host key (a much more risky situation) forces the user to manually remove the old key, hopefully forcing them to think about the consequences: > @@@ > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ > @@@ > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! > Someone could be eavesdropping on you right now (man-in-the-middle attack)! > It is also possible that the RSA host key has just been changed. > The fingerprint for the RSA key sent by the remote host is > f2:42:df:b2:6e:1b:8a:ac:96:27:6d:8c:b9:e6:93:a1. > Please contact your system administrator. > Add correct host key in /home/djm/.ssh/known_hosts to get rid of this message. > Offending key in /home/djm/.ssh/known_hosts:209 > RSA host key for 127.0.0.1 has changed and you have requested strict checking. > Host key verification failed. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Skype security evaluation]
On Sun, 23 Oct 2005, Joseph Ashwood wrote: - Original Message - Subject: [Tom Berson Skype Security Evaluation] Tom Berson's conclusion is incorrect. One needs only to take a look at the publicly available information. I couldn't find an immediate reference directly from the Skype website, but it uses 1024-bit RSA keys, the coverage of breaking of 1024-bit RSA has been substantial. The end, the security is flawed. Of course I told them this now years ago, when I told them that 1024-bit RSA should be retired in favor of larger keys, and several other people as well told them. More worrying is the disconnect between the front page summary and the body of the review. If one only reads the summary, then one would only see the gushing praise and not the SSH protocol 1-esque use of a weak CRC as a integrity mechanism (section 3.4.4) or what sounds suspiciously like a exploitable signed vs. unsigned issue in protocol parsing (section 3.4.6). Also disappointing is the focus on the correct implementation of cryptographic primitives (why not just use tested commercial or open-source implementations?) to the exclusion of other more interesting questions (at least to me): - What properties does the proprietary key agreement protocol offer (it sounds a bit like an attenuated version of the SSH-1 KEX protocol and, in particular, doesn't appear to offer PFS). - Does the use of RC4 follow Mantin's recommendations to discard the early, correlated keystream? - How does the use of RC4 to generate RSA keys work when only 64 bits of entropy are collected from Skype's RNG? (Section 3.1) - Why does Skype "roll its own" entropy collection functions instead of using the platform's standard one? - Ditto the use of standard protocols? (DTLS would seem an especially obvious choice). - What techniques (such as privilege dropping or separation) does Skype use to limit the scope of a network compromise of a Skype client? -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Another entry in the internet security hall of shame....
On Tue, 30 Aug 2005, Peter Gutmann wrote: - A non-spoofable means of password entry that only applies for TLS-PSK passwords. In other words, something where a fake site can't trick the user into revealing a TLS-PSK key. This sounds like a solution replete with all the problems that passwords have had all along: users choosing bad ones, using the same ones for different sites, never changing them, servers getting hacked (disclosing the probably-shared passwords of thousands of users), etc. ad nauseum... The last threat is particularly pertainent because it appears there is a requirement for servers to retain the PSK in cleartext. (To be fair, the draft does RECOMMENDED that implementations provide a way to generate random PSKs, but this has been recommeded for passwords in general for decades, to little effect.) Given the complete lack of good password management practice in the vast majority of websites, what will make them start doing things right with TLS-PSK? Maybe some of this could be solved with a good UI in the web browser (e.g. by treating the PSK as a key rather than a password), but arm-waving about UI refinements applies to improving certificate handling too. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Time for new hash standard
R. A. Hettinga wrote: > Luckily, there are alternatives. The National Institute of Standards and > Technology already has standards for longer - and harder to break - hash > functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already > government standards, and can already be used. This is a good stopgap, but > I'd like to see more. I haven't seen any discussion on constructions based on "universal hashing", like the UHASH underlying UMAC[1]. Can any cryptographers comment on this? UMAC seems like a particularly nice MAC, because it is supposedly provably-secure (to the extent that AES is) and benefits from hardware speedups to AES. -d [1] http://www.cs.ucdavis.edu/~rogaway/umac/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Is finding security holes a good idea?
Eric Rescorla wrote: >>I don't find that argument at all convincing. After all, these bugs *are* >>being found! > > Well, SOME bugs are being found. I don't know what you mean by > "these" bugs. We don't have any real good information about > the bugs that haven't been found. What makes you think that > there aren't 5x as many bugs still in the code that are basically > like the ones you've found? If developers are just treating bugs as isolated defects, and not searching for typologies of problems then this may be true. If we search for common problems and repair all that we find, then we will do better. In many cases, this doesn't take as much additional work as finding the first instance. Sometimes it can be as little work as writing a regexp. Of course, not all bugs are as easy as replacing strcpy (e.g. integer overflows are subtle), but this approach is working. What was the last trivial buffer overflow in a *BSD? > I don't think that's clear at all. It could be purely stochastic. > I.e. you look at a section of code, you find the bug with some > probability. However, there's a lot of code and the auditing > coverage isn't very deep so bugs persist for a long time. I suspect that auditing coverage is usually going to be very similar to the search patterns used by blackhats - we are all human and are likely to be drawn to similar bugs. Auditing may therefore yield a superlinear return on effort. Is that enough to make it a "good idea"? -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: WYTM?
On Sun, 2003-10-19 at 00:47, Peter Gutmann wrote: > >What was the motive for adding lip service into the document? > > So that it's possible to claim PGP and X.509 support if anyone's interested in > it. It's (I guess) something driven mostly by marketing so you can answer > "Yes" to any question of "Do you support ". You can find quite a number of > these things present in various security specs, it's not just an SSH thing. I think that you are misrepresenting the problem a little. At least one vendor (ssh.com) has a product that supports both X.509 and PGP, so the inclusion of these in the I-D is not just marketing overriding reality - just a lack of will on part of the the draft's authors. I have seen little involvement on the secsh wg mailing list by the ssh.com people since the public spat about trademark rights over "ssh" a few years back. Since noone else implements these two public key methods, the work has never been done. IIRC The wg decided to punt the issue to a separate draft if it ever arose again. It hasn't in two years. In the meantime, everyone involved seems to have become deathly afraid of touching the draft so as not to impede its glacial progress through the IETF on its way to RFC-hood. Whether a sizeable number of customers acutally use certificates for ssh is another matter. IMO The only real use for certs in ssh is the issue of initial server authentication. If one wants to use certificates to facilitate this process, they can already - just publish the server keys on a https server somewhere and/or sign them with PGP :) -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: WYTM?
On Mon, 2003-10-13 at 20:27, Ian Grigg wrote: > The situation is so ludicrously unbalanced, that if > one really wanted to be serious about this issue, > instead of dismissing certs out of hand (which would > be the engineering approach c.f., SSH), one would > run ADH across the net and wait to see what happened. I don't think that this is an accurate characterisation of the situation wrt SSH. The SSH protocol supports certificates (X.509 and OpenPGP), though most implementations don't. Around a year ago, Markus Friedl posted patches to enable X.509 certs for OpenSSH, but there was little interest. Also, SSH is somewhere between the two extremes of ADH and the PKIish hierarchial trust. Protocol 2 uses DH, so you have the PFS properties, but most implementations offer better opportunities for key verification than the popular SSL implementations (in web browsers). E.g. I don't recall a web browser offering a fingerprint for a private key, except behind a number of confusing dialogs, nor present me with ALL CAPS warnings when webservers change their keys. -d - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
