March « 2006 « D-kriptik Blog

Archive for March, 2006

ID check, OpenSSL FIPS, IE fix, social device, vi chart, and neuro-chips

Thursday, March 30th, 2006

I remember a period of time a few years ago when my ID was checked twice at the airport, once when passing through security and once before boarding the actual flight. This was around the time when John Gilmore started fighting the ID requirements. Now it appears checking ID is not necessarily required at all.

Now, the signs in the airport still tell you that you must have identification.

The TSA’s website itself states, “Each adult traveler needs to keep available his/her airline boarding pass and government-issued photo ID until exiting the security checkpoint.”

Neither those signs nor the TSA’s website are true.

Who says?

The TSA.

“Passengers are allowed to enter screening area without identification,” TSA spokeswoman Amy Kudwa told this humble reporter today.

This reminds me of the non-requirement to take off one’s shoes, which varied from airport to airport, TSA employee to TSA employee, during the period of time when I had to travel a great deal for work. I remember one encounter, at my local airport at the time, Reagan National, that went something like this.

Me: “I have passed through this metal detector in this airport many times before without taking off these very shoes, and there have been no problems.”

TSA employee: “Sir, please take off your shoes.”

Me: “I have never been forced to take off my shoes here before. Is that a new requirement, or is it still optional with the risk of extended searches if I set off the detector?”

TSA employee: “It is an optional, but I will not let you pass until you choose to take off your shoes.”

Me: “So, you are essentially saying I have to take off my shoes?”

TSA employee: “No, but I will not let you pass until you choose to take off your shoes.”

At that point, I gave up and took off my shoes. (Of course, the next time I flew out of Reagan National, I was not required to take off my shoes. Too bad, I made sure my socks were nice and dirty. )

All that aside, I still don’t understand what ID has to do with determining whether I am really a threat to a flight. I mean, getting a fake ID is simple – just ask any teenager.

I have sort of commented on this before.

Twice I was assessed, determined to be a friend and beneficial instead of a foe or threat, and then used to counter threats and mitigate risks. These people did so without scanning me with metal and chemical detectors, checking my identification, or making me feel harassed. They used their real world experience, applied it to me, my look, and my behavior, and made solid judgments based on the current situations. These are the types of skills necessary for people working in roles such as security screening at airports.

via DefenseTech

OSSI announced that the OpenSSL FIPS module has been officially FIPS 140-2 level 1 validated.

UPDATE: Wednesday, March 22, 2006
The OpenSSL FIPS Object Module has been validated and posted on the CMVP FIPS 140-2 Validation List. Certificate number 642

The FIPS validated module, security documents and user’s guide will be posted shortly. Thanks for your patience.

There it is. Congratulations to the team.

I commented on this effort back when the certificate was almost issued.

via Apex Assurance Group – Weblog

Determina has released a temporary fix for an unpatched Internet Explorer vulnerability that is actively being exploited in the wild.

This is a runtime fix for the IE createTextRange() vulnerability. It can be applied to Windows 2000, XP and 2003 systems running Internet Explorer 5.01 and 6.0. The vulnerability lies in the MSHTML.DLL rendering engine which is loaded into many applications for HTML rendering, including but not limited to Internet Explorer and Microsoft Office.

When Microsoft patch day arrives, it will be time to uninstall this temporary fix and install the official Microsoft patch.

Once Microsoft releases an official patch and it is installed by the user, the Determina Shield will not be applied any more. Determina recommends uninstalling this fix even though keeping it active will not affect the system. To uninstall the fix, use “Add Remove Programs” in the Control Panel. To uninstall it manually, remove the DLL from the AppInit_DLLs key and restart your machine. You can then safely delete the DLL.

via this post to DailyDave

Update: The official Microsoft patch has been released.

DHTML Method Call Memory Corruption Vulnerability – CVA-2006-1359

Many other critical issues in IE are patched as well.

Don’t notice those social cues when trying to explain a technical topic to a non-technical audience? This device could help.

The “emotional social intelligence prosthetic” device, which El Kaliouby is constructing along with MIT colleagues Rosalind Picard and Alea Teeters, consists of a camera small enough to be pinned to the side of a pair of glasses, connected to a hand-held computer running image recognition software plus software that can read the emotions these images show. If the wearer seems to be failing to engage his or her listener, the software makes the hand-held computer vibrate

For the typical geek though, technology is not the answer – practice and feedback are the proper tools, such as presenting at the NYCBUG meetings.

Here we have a periodic table of the elements for VI/VIM. (I use VIM most happily.)

via Populicio.us

And, look here.

The line between living organisms and machines has just become a whole lot blurrier. European researchers have developed “neuro-chips” in which living brain cells and silicon circuits are coupled together.

The achievement could one day enable the creation of sophisticated neural prostheses to treat neurological disorders or the development of organic computers that crunch numbers using living neurons.

What first popped into my mind? Ghost in the shell.

(I love the opening song to Stand Alone Complex – the MP3 can be found here on the official web site. Yoko Kanno.)

via OmniNerd

Posted in NYCBUG, Off-topic, Security | 2 Comments »

Salty crypt functions

Monday, March 27th, 2006

I was recently asked via email whether using a constant, hard-coded salt with the traditional Unix crypt function was a bad idea. I sent off a quick reply to point the person in the right direction, but I figured it would be good to write a quick blog post as well. (The small link farm at the end is the most useful part of this post.)

In general, this is a bad idea. The point of mixing in a salt as part of generating password hashes with the crypt function is so that the same password does not necessarily generate the same password hash. The set of possible password hashes that can be selected by the crypt function for a particular password grows expontentially with size of the salt (the salt is 12 bits here, so 2^12 password hashes are possible for each password). This can make precomputing password hashes and building lookup tables more difficult as such efforts will have to incorporate the unknown salts and thus the larger set of password hashes possible per password, and this can increase the effort of cracking multiple password hashes as the same salt needs to be shared between password hashes for the work performed on cracking one password hash to be easily applied to others.

For example, say I generate password hashes by running a password through SHA-256. Now, say I have a 48 bit salt that is randomly generated and appended to the password before it is run through SHA-256 to generate the password hash. For any given password, there are now 2^48 different password hashes possible, instead of the just one if I did not use a salt. If an attacker wanted to precompute hash values for a dictionary, that means each dictionary entry will require 2^48 password hashes instead of just one. If the attacker gained access to multiple password hashes, the effort of cracking one of those password hashes only applies to another password hash if their salts (a one in 2^24 chance in the ideal world, is it?) are the same instead of applying to all passwords hashes when no salt is used.

(One thing to keep in mind here, the salt is not being used to notably effect the speed with which the crypt function computes password hashes, which is sometimes implied in discussions on this topic. In fact, the traditional Unix crypt function and even the MD5 crypt function both take a constant, non-configurable amount of computation to generate password hashes. Also, the salt used for generating a particular password hash is assumed to be public – it is not a secret like the password – so the effort of attacking an individual password hash is not made any harder by using a salt.)

Ok, so, by using a hard-coded, constant salt, the same password will generate the same password hash. If this constant salt becomes public and thus attackers can be assumed to know it, then really all benefit of using the salt is lost – it can just be considered (a slight variant of) the traditional Unix crypt with no salt.

That is not to say that this change cannot be used without some security benefit over the usual crypt function without a salt – if this constant is configurable, then it can make precomputation more difficult following similar, but weaker, logic as for a salt. And, if this constant is kept secret, then there is effectively additional “key material” being used to generate the password hash, which makes precomputation more difficult and could even make it harder to crack individual password hashes. But then, using the term salt becomes misleading – perhaps it should just be called the “concatenated constant.” (I don’t know about everyone else, but assuming password hashes can be accessed but not the “concatenated constant” seems a bit strange to me.)

Even with salts, the traditional Unix crypt function is quite dated and may not be a good choice for generating password hashes. The tiny salts, short password length, optimizations, current processing speeds, etc. all combine to make crypt function generated password hashes quite susceptible to password cracking efforts. The two common alternatives are the MD5 crypt function, which uses the MD5 hash algorithm as its underlying crypto primitive and incorporates a salt, and the blowfish crypt function, which uses the blowfish encryption algorithm with modified key schedule as its underlying primitive and incorporates both a salt and an interation count. The blowfish crypt function is considered to be the latest and greatest crypt function that is widely deployed.

(FYI, there was recently a discussion on the NYCBUG talk mailing list about the fact FreeBSD still ships with MD5 crypt function as the default. Instructions for configuring the default crypt function settings in FreeBSD can be found here.)

A few good papers on the subject… the Unix crypt paper from back in 1979 (and 10 years later) and the OpenBSD bcrypt design paper from 1999. A good interview on the topic… Solar Designer’s (author of John The Ripper) interview from earlier this year (2006). PKCS#5 might be of interest as well. (There was also this paper in the aforementioned CCS 2005 proceedings.)

(Of course, the key here – see Appendix A – is choosing good passwords. This blog commented on passwords way back when the blog first started.)

Posted in Authentication & Identity, BSD, Crypto, Security | 1 Comment »

Firefox SSL/TLS settings, use your bookmarks, and some cool, useful, and nice news

Thursday, March 23rd, 2006

The following image depicts the settings I generally configure Firefox v1.5 to use with regards to SSL/TLS protocol support and algorithm suites. These can be viewed/configured by typing “about:config” (without the quotes) in the address bar in Firefox.

Firefox v1.5.0.1 about:config view of TLS/SSL settings.

Most noteworthy, these disable SSLv2, small key lengths (40 bits, 56 bits – note: DES keys are 56 bits with 8 bits of parity), and null encryption. These settings also turn off all RC4 usage for encryption, which has become a habit of mine, but may just be silly. Assuming an SSL/TLS session is being established with the proper entity, these settings should make communications over that channel quite resilient against standard sniffing, which is probably the main benefit of SSL/TLS use right now for web browsing.

Update:

Important Note – This comment just came in. Of the algorithms disabled here, RC4 is commonly used and it seems some banking sites support only it for encryption – so, you may want to set “security.ssl3.rsa_rc4_128_sha” to “true”.

Firefox v1.5.0.3 about:config view of TLS/SSL RC4 settings with one RC4 cipher suite enabled.

Thanks to Hal Jalikakik for the feedback kick.

Side note – I find it weird that Citibank online banking only supports RC4. I thought the financial community had embraced FIPS-approved algorithms (e.g., AES, Triple-DES), but perhaps that does not apply to securing customer data as it is transmitted over the Internet between the customer and the bank.

About the “Assuming an SSL/TLS session is being established with the proper entity” caveat in the previous paragraph…

These settings have nothing to do with verifying that you are in fact establishing an SSL/TLS session with the proper entity. For example, you could establish an SSL/TLS session with a malicious web site that has a domain name that is a variation of, or related to, the name of the site you intended to visit. That site wcould easily have a proper certificate signed by a browser trusted authority for that domain name, which means the browser does not even pop up a warning dialog box.

These settings also have nothing to do with countering an SSL/TLS MITM attack. For example, ettercap will gladly negotiate a secure connection with you and with your intended destination server, replacing the intended destination server’s certificate with its own, populated quite fully with the intended destination server’s information. This will generally result in a warning dialog box from your browser, but an attacker could get a certificate signed by a proper authority, and then have that sign the certificate ettercap generates on fly, which means the browser does not even pop up a warning dialog box.

The former is growing more common as it trivial to setup the server and then plug that in to phishing attacks, the latter is not widespread as it requires the ability to manipulate traffic between someone and their intended destination.

(Obviously, these settings also do nothing against someone that can grab the data before it enters, or after it exits, the SSL/TLS session. For example, spyware can grab sensitive credentials off your machine, rendering SSL/TLS moot. That is neither here nor there for this post though – see “yeah right, crypto this” or pretty pictures.)

In fact, most people have no idea what warning dialogs with relation to SSL/TLS negotiations or digital certificates mean, and, in many cases, they are false alarms anyway. So, virtually everyone has grown accustomed to just clicking through such warning dialogs. Worse yet, many times there are no warning dialogs, and only checking the certificate information everytime you negotiate a SSL/TLS session to see if it looks valid will help (Does the Common Name match the domain you were trying to reach? Does the Oragnization look appropriate? What about the Issuer information?). But, even that is not foolproof. For example, browser trusted CAs sometimes issue certificates to improper entities. Another example, some sites spoof a lock icon, although current versions of Firefox now add a lock icon to the address bar and colors the address bar yellow when connected to a site over an SSL/TLS connection. Other examples are cited above.

This is an active research area. Petnames have been proposed, which I like (think PGP web of trust in some form). This has similarities to the SSH-type trust model, which has also been proposed and which I also like. In recent minutes to an IETF-PKIX meeting, the Opera people were looking at “extended validation” certificates. There has been all sorts of talk, pros and cons, about “high-assurance” certificates.

The rare SSL/TLS MITM attack aside, many of these techniques will be experienced by people in the form of phishing attacks, primarily from email and instant messages. There is an easy countermeasure that works decently today though…

Bookmark web sites that you visit, especially where you conduct transactions like buying stuff, and then return to those sites only through your bookmarks (this is like what we do with server public keys in SSH). Now, when you receive that email, instant message, or embedded link in some rogue web site purporting to be from, or purporting to point you to, Paypal and you really do feel it necessary to log into Paypal in response, don’t follow any of the links provided – instead, use your bookmark for the Paypal web site. It doesn’t solve all these problems, but it helps quite a bit.

Update: First, a big thanks for the late morning discussion. Now, to the points…

Someone pointed out that all the example attacks are “yeah right, crypto this.” I can see that, as all of these attacks do leverage trust, process, and/or people to be effective – they are not direct attacks on the crypto of the SSL/TLS protocol. However, the current incarnation/usage/presentation of SSL/TLS for securing HTTP traffic for the average web browsing individual just does not seem to ~~not~~ work – that could be a sign of more than a “yeah right, crypto this” attack.

Someone else pointed out that negotiating an SSL/TLS session with a malicious server is the same as having spyware installed on your machine – in either case, it is stealing information after it enters/exits the SSL/TLS session. That is true. My point was that SSL/TLS includes mechanisms to authenticate the entity with which you are speaking and these have been translated into the web browsing experience, but these mechanisms are not always effective in the web browsing medium. SSL/TLS was not designed to prevent spyware and other such attacks.

Also note, this post was geared towards HTTPS (HTTP over SSL/TLS) and people using normal web browsers, with Firefox being explicit discussed. I was not talking about OpenVPN, which uses the TLS handshake to authenticate and negotiate keys and then passes those keys to IPSec, or any SSL/TLS VPN. I was not talking about POP3, SMTP, FTP (who even uses such a thing?), etc. over SSL/TLS. I was not talking about EAP-TTLS or any other EAP. Granted, some of these attacks might be relevant, but that is out of the scope here.

Completely unrelated, the death of the mechanical hard drive is inevitable, and thank goodness. Here is one example, in a new Samsung notebook.

At the Cebit technology fair in Germany, Samsung has unveiled a prototype Laptop which has 32 GB of Flash memory instead of a traditional hard drive. The newer memory chips are smaller in size and occupy the same space as traditional 1.8″ disk-based drives. The advantages are Flash memory is much faster the prototype laptop that Samsung showed off was able to boot (the operating system was not mentioned) in 18 seconds versus 31 seconds for the laptop with a regular hard disk drive. As it does not hav any moving parts it is completely silent.

Cool.

And, I can’t say this is new, but someone wrote it up with pictures.

A simple way to remove scratches from a cd so you can get your data back off the disc again.

Useful.

via MAKE: blog

This may get me using a cell phone again.

A new sheet has been leaked out that shows a 5/28/06 targeted release date for the 700p. It will come with Power Vision EV-DO, 1.3 megapixel camera, Sprint TV on Demand, Phone as a modem capability, Bluetooth, 128MB of memory (yay!), SD card slot, and a “refined industrial design”.

Nice.

Posted in Crypto, Security | 11 Comments »

Install issue with GNUCash from the FreeBSD ports

Tuesday, March 21st, 2006

So, I went to install GnuCash on a machine running FreeBSD 6.1 Prerelease (“cd /usr/ports/finance/gnucash; sudo make install”) a couple of days back (19-03-2006). Just as I was rejoicing at all the dependencies being handled automatically (and goodness knows there were many), the install died.

===> gnucash-1.8.12_1 depends on executable: gmake – found
===> gnucash-1.8.12_1 depends on file: /usr/local/bin/perl5.8.8 – found
===> gnucash-1.8.12_1 depends on file: /usr/local/bin/intltool-extract – found
===> gnucash-1.8.12_1 depends on executable: pkg-config – found
===> gnucash-1.8.12_1 depends on shared library: guile.15 – found
===> gnucash-1.8.12_1 depends on shared library: guppi.16 – found
===> gnucash-1.8.12_1 depends on shared library: popt.0 – found
===> gnucash-1.8.12_1 depends on shared library: ofx.2 – found
===> gnucash-1.8.12_1 depends on shared library: gw-standard.0 – not found
===> Verifying install for gw-standard.0 in /usr/ports/devel/g-wrap
===> g-wrap-1.3.4_8 depends on file: /usr/local/share/guile/slibcat – not found
===> Verifying install for /usr/local/share/guile/slibcat in /usr/ports/lang/slib-guile
===> slib-guile-3a1 is marked as broken: Does not install.
*** Error code 1

Stop in /usr/ports/lang/slib-guile.
*** Error code 1

Stop in /usr/ports/devel/g-wrap.
*** Error code 1

Stop in /usr/ports/finance/gnucash.

Sure enough, the makefile (“/usr/ports/lang/slib-guile/Makefile”) for slib-guile in the ports tree identified the port as BROKEN.

BROKEN= Does not install

A quick search of the FreeBSD ports mailing list archives, and there was a recent post pointing to the following workaround.

1) Use portdowngrade to grab the slib-3a1_2 version, and install it.
gnucash/guile does not like 3a3.
2) Use pkgtools.conf to ‘hold’ slib-*.
3) remove the “BROKEN” status from slib-guile-3a1

Attempt ‘make install clean’ of gnucash.

(Note: The use of “sudo” proceeding these commands is not necessary if you are root, of course.)

I thought “slib-3a3″ was automatically installed as a dependency of GNUCash, but, before I removed it, I checked to make sure that was the case and there were no dependencies on “slib-3a3″.

pkg_info -R slib-3a3

No packages were listed as depending on “slib-3a3,” so I removed it.

sudo pkg_delete slib-3a3

I did not have “portdowngrade” installed, so I needed to install that.

cd /usr/ports/sysutils/portdowngrade
sudo make install

I tried using “portdowngrade” with SSH, but it fails as unsupported, which meant the USA anoncvs mirrors were out. I then tried the French anoncvs server, but this failed with some sort of read error for lang/slib. So, then I went to Japan.

sudo portdowngrade -o -s:pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs lang/slib$

When prompted, I entered the password “anoncvs” (without quotes).

During step 3 of the 6 step process, a list of previous versions was provided, from which you could select one to downgrade to. I selected the number corresponding to “3a1_2″ (#3 when I was performing these steps), confirmed that I wanted to downgrade, and was downgraded.

As instructed by “portdowngrade,” I updated my ports database since I use “portupgrade” (this could have been performed later).

sudo portsdb -Uu

With that completed, I installed the downgraded port, “slib-3a1_2″.

cd /usr/ports/lang/slib
sudo make install

I then edited “/usr/local/etc/pkgtools.conf” to hold “slib” and “slib-guile” by adding “slib-*” to the “HOLD_PKGS” array.

sudo vi /usr/local/etc/pkgtools.conf

My HOLD_PKGS ending up looking as follows.

   HOLD_PKGS = [
     'bsdpan-*',
     'slib-*',
	]

I then edited the Makefile for “slib-guile” and commented out the “BROKEN= Does not install” line.

sudo vi /usr/ports/lang/slib-guile/Makefile

With that all set, I was ready to build and install GNUCash.

cd /usr/ports/finance/gnucash
sudo make install clean

Perfect.

(Completely unrelated, this is quite interesting.

With new technologies constantly being invented in corporate and academic labs around the world, identifying which ones will transform computing, medicine, telecommunications and business always is a challenge. In “10 Emerging Technologies,” a special package in the March/April issue of Technology Review, MIT’s magazine of technology, the editors name those that they feel will soon have a significant impact. The ten technologies are also featured at www.technologyreview.com/special/emerging.

via Infectious Greed)

Posted in BSD | 2 Comments »

Curious geeks

Sunday, March 19th, 2006

Things have been hectic, but I wanted to point out the following quote in a Sunday post.

“Hire curious people. Even if they don’t have the exact skill set you want, curious, passionate people can learn anything.”

I learned a long time ago that if you speak the lingo of a certain subject, people begin to believe you understand that subject – it is just one of the indicators of knowledge that we all use when we know little to nothing about a subject. Sometimes it is a good indicator, many times it is not. An example of the latter is the movie “The Fast and The Furious.” There is a part in that movie where Vin Diesel’s character says something like “granny shifting instead of double-clutching like you should” when criticizing a fellow street racer. That sounded cool to me when I first heard it, like he really knew what he was talking about, but it also made me wonder what on earth it meant – so I asked a car guy I knew back then, and he pointed out that the statement was in fact incorrect there.

(A particular case of this led to a joke in one of my circles that involved blending crypto buzzwords together in a way that made absolutely no sense yet sounded profound. For example,

So, we take some X9.31 (no BlumBlumShub around here), add a touch of SHA-256 (MD5 is so 90’s, you know) with a little of the HMAC, and mix in a few bits of AES (combined with the Diffie-Hellman of course, cause, well, you know why). That’s not all – we then ECDSA that and even toss in a little modular exponentiation with hardware acceleration just to be conservative. But, man, you don’t even want to know what we do next… [And so on until it gets old.]

)

What does this have to do with the quote above? Well, questions about skill set commonly result in answers that are a bunch buzzwords and surrounding fluff. It is a rarity that you get responses that convey passion and curiosity with technical competence as just a given. Yet, those are exactly the type of responses we should be looking for when trying to find people to help with our technology needs. For example, having sat through many a technical interview, my favorite interviewees do not list a bunch of skills and buzzwords, they talk about what cool technologies they are currently playing with.

People who love to dig are rare. They tinker, they research, they build – in other words, they love to play with things and learn. Such people accumulate experience and knowledge, and can connect the dots. They also like to share and tend to know others just like them. Statements like “I first encountered this while…” or “I played with something similar…” or “my buddy and I are working on a project…” are commonly heard from them.

Any of us that have dealt with first tier technical support, only to work our way up the chain to someone that actually knew how to dig have experience this. Static people regurgitate training and checklists without listening to you, dynamic people listen to you and then solve your problem, evolving all the while.

And, this is one of the difficulties with many open source platforms crossing over to the mainstream – they require people to dig. Most of people using IT act as I do with my couch – they just want it to meet their needs, they don’t care how it really works. Why should they? Specialization is one of the benefits of our world, and we can trade to meet our needs.

So, lets have a new buzzword – curious geeks, hackers in the traditional sense. I can’t see using anyone else for hands on technical work.

Update: Looks like that joke is not forgotten… I received the following via email.

Dude.. I am DYING! I tried to explain to [removed] why I have tears rolling down
my eyes, but [removed] just doesn’t get it

You did forget about XORing the result with the closing price of Light Sweet
Crude Oil and concatenating with Avogadro’s number

Welcome to my world.

Posted in D-Kriptik, Off-topic | 1 Comment »

Draft of FIPS186-3 released for public comment

Wednesday, March 15th, 2006

The draft for FIPS 186-3 has been made available for public comment by NIST. (I actually expected this to happen a couple of months ago, given what I had heard and the fact that elements of FIPS 186-3 were referred to a bit in drafts of SP800-56 and SP800-57 from many months ago.)

FIPS 186, first published in 1994, specifies a digital signature algorithm (DSA) to generate and verify digital signatures. Later revisions (FIPS 186-1 and FIPS 186-2, adopted in 1998 and 1999, respectively) adopt two additional algorithms specified in American National Standards (ANS) X9.31 (Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA)), and X9.62 (The Elliptic Curve Digital Signature Algorithm (ECDSA)).

The original DSA algorithm, as specified in FIPS 186, 186-1 and 186-2, allows key sizes of 512 to 1024 bits. With advances in technology, it is prudent to consider larger key sizes. Draft FIPS 186-3 allows the use of 1024, 2048 and 3072-bit keys. Other requirements have also been added concerning the use of ANS X9.31 and ANS X9.62. In addition, the use of the RSA algorithm as specified in Public Key Cryptography Standard (PKCS) 1 (RSA Cryptography Standard) is allowed.

Prior to the submission of this proposed standard to the Secretary of Commerce for review and approval, it is essential that consideration is given to the needs and views of the public, users, the information technology industry, and Federal, State and local government organizations. The purpose of this notice is to solicit such views.

DATES: Comments must be received on or before June 12, 2006.

This draft can be found here. I quickly flipped through a little of the proposed standard and noted a few of the obvious changes.

Most apparent and interesting given the history, RSA (PKCS#1) for digital signatures is formally included in this FIPS. RSA digital signatures have been allowed through guidance for quite some years now, but there was no formal NIST standard specifying what was allowed in the arena of RSA digital signatures. This version of FIPS 186 finally fixes that.
Other notes, RSA (PKCS#1) and rDSA (ANSI X9.31) are restricted to key sizes of 1024 bits, 2048 bits, and 3072 bits. The key generation must follow the requirements in Appendix B.3.1 of FIPS 186-3, where the technique for key generation is explicitly defined along with a large set of checks to be performed during key generation. This makes a big difference, as, prior to this specification, there were really no strong guidelines on RSA key generation for use by the Federal government (and everyone else that follows these standards).
With the SHA-2 family now available, the big change for DSA itself is the addition of various key sizes greater than 1024 bits – 2048 bits (with SHA-244 or SHA-256) and 3072 bits (with SHA-256) – and the removal of key sizes less than 1024 bits, which had already become commonplace through guidance.
(The key sizes make sense based on the guidelines for key strength, which state that keys with an effective strength of 128 bits, which 3072 bit RSA/DSA and 256 bit ECDSA are, will be appropriate well into the future (potentially beyond 2030). Only ECDSA has key sizes specified that go beyond 128 bits of effective strength.)
Random number generators are no longer specified in the standard. Only random number generators specified for draft SP800-90 are to be used, and the strength of random number generators is finally becoming a criteria for usage. (SP800-90 is clearly becoming the official specification of random number generators.)
The generation of primes, parameters, and key pairs has been updated quite a bit, and there are a variety of checks and verifications for assuring the correctness of these values now incorporated into the standard. This ties in with the various assurance elements that have been brought into the standard.
There is a lot more process described in FIPS 186-3 than prior versions, which muddies the algorithm specification a bit. For example, there is discussion around assuring a key pair is tied to/possessed by the appropriate entity – I almost expected to find an appendix describing a full blown PKI that MAY be implemented. Much of this points to a separate document, draft SP800-89, which is where I think all of it should go.

I can only imagine the new generation mechanisms, including domain parameters and random numbers, and the new key (and hash) sizes will tier out through the standards community quite rapidly and then out to designs/implementations.

In general, the coverage provided by various FIPS combined with various SPs is indicating a more robust and rigorous CMVP is taking hold. This is good news, as this guidance is now available to, and followed by, many people throughout the world.

(Please note the “Common Questions” post.)

Update: I have been asked a bunch of questions that I translated into the following list.

When will this become a law? Will there be a transition period? What will be the impact to my DSA, RSA, ECDSA implementation?
What will this mean to FIPS 140 validations where digital signatures are involved? Will it effect products already validated? Will it effect validation efforts in process? How will it effect future validation efforts?
Does this impact algorithm testing efforts?
You mentioned additional rigor in the CMVP – is that really true? Are FIPS 140-2 validation becoming more intensive? Will a FIPS 140-3 validation be more effort than a FIPS 140-2 validation?
Speaking of FIPS 140-3, any news on this front? If it is coming down the pipe soon, should I hold off FIPS 140 validation until it is ready, or should I do the opposite and avoid the kinks/rigor of FIPS 140-3?

Unfortunately, these questions are not appropriate for D-kriptik to answer, but I thought it would be useful to at least publish the questions.

Update: I love people sharing information. You asked, and the comments section now has answers. Thanks to Ray Potter for responding.

Posted in Crypto | 2 Comments »

Freed info, EPIA EN & C7 coolness, open NYCBUG, 786-718, LC no more, GPG uh oh, buy 3.9, 0.1.1.x RC1, and SXSW 2006

Tuesday, March 14th, 2006

I noticed this article via Schneier on Security.

The CIA asked the Tribune not to publish her name because she is a covert operative, and the newspaper agreed. But unbeknown to the CIA, her affiliation and those of hundreds of men and women like her have somehow become a matter of public record, thanks to the Internet.

The information age in general and that remarkable trashdump known as the Internet always reinforce what I believe to be a sort of law of nature, information wants to be free. The more digital and connected our world becomes, the stronger that want becomes. All of us as owners and protectors of information try to fight that freedom at times, and one mistake is often all it takes to crush those efforts in the modern world. Once information is freed today, there is little that can be done to lock it back up. In an instant, it is everywhere and nowhere, free.

Information leaks aside though, the following blurb reminded me of a story I once heard.

Some are heavily guarded. Others appear to be unguarded private residences that bear no outward indication of any affiliation with the CIA.

Someone once told me about a meeting they had with a different TLA. They drove to the meeting, and ended up in a mostly residential neighborhood in Maryland, where they encountered what appeared to be a private residence at the address that they had been given. That facade only held until they got within a certain distance of the building though, at which point they encountered a very thorough escort. This was no ordinary private residence.

Could it be?

Taipei, Taiwan, 10 March 2005 – VIA Technologies, Inc, a leading innovator and developer of silicon chip technologies and PC platform solutions, today announced the VIA EPIA EN-Series Mini-ITX mainboards, the first of VIA’s ultra compact platforms to feature the VIA C7 processor, making it the most powerful EPIA platform to date.

Designed to inspire a new generation of powerful digital media appliances, the VIA EPIA EN mainboard sets new standards for performance per watt and rich feature set, integrating the advanced VIA CN700 digital media IGP chipset that boasts an impressive range of features, including full hardware HDTV encoding up to 1080i, 720p output, hardware MPEG-2 acceleration, VIA Vinyl Multi-channel Audio, support for up to 1GB of DDR2 400/533MHz memory, full featured SATA II RAID, an LVDS module connector and Gigabit LAN.

And lots of hardware crypto.

Integrated into the VIA C7 and VIA Eden processor supporting is the VIA PadLock Security Engine, the world’s most comprehensive collection native x86 security tools. Featuring the world’s fastest x86 AES encryption engine, a powerful secure hash engine, a hardware Montgomery Multiplier to accelerate public key encryption such as RSA, and dual quantum based random number generators to provide an unshakable foundation for security, the VIA PadLock Security Engine enables developers to seamlessly offload the computational process involved in complex encryption algorithms freeing processor loading to handle more data faster. The security engine also offers NX Execute protection to prevent the propagation of worms.

Oh my goodness, this sounds so so sweet (marketing spin aside). There are a couple of projects I have been thinking about for which this might be perfect.

via a post to cypherpunks

The April 2006 NYCBUG meeting looks like it is going to have an open format.

Some of you may have noticed that we don’t have a meeting listed for April.

On admin we are discussing the idea of having an open type meeting, one
in which a few people off talk can propose a topic that they can discuss
in 5 minutes or so that is relevant to the their work with or on the BSDs.

In other words, if you’ve had a repeated problem figuring out how to get
spamd working, or you have a great solution for dealing with those
repeated zombie attacks on sshd, this is the time.

Some of our readers (and friends) are BSD people, especially a few of you down in DC. If you want to chime in, I may know of a place for you to crash for the night.

I know a few people that have been hit with this, including myself.

[...]I
>> got a call the other from the number 786-718-9058 and when I answered, it
>> was a message in Spanish which I couldn’t really hear and didn’t
>> understand. That was the end of it. Well then it called again 5 days
>> later and got my voicemail and left the same message it had the other day
>> when I answered the phone.
[...]

Hot on the heels of the publicity around the latest release of John the Ripper, l0phtcrack goes away.

The purpose of this letter is to notify you that Symantec Corporation is discontinuing its L0phtCrack (LC) product line and will no longer provide product code updates, enhancements or fixes to this product line.

via this post on the DailyDave mailing list

GPG patched.

Signature verification of non-detached signatures may give a positive
result but when extracting the signed data, this data may be prepended
or appended with extra data not covered by the signature. Thus it is
possible for an attacker to take any signed message and inject extra
arbitrary data.

FYI, we recently generated an OpenPGP key for general inquiries to D-kriptik. The public key can be found here.

via this post on the cryptography mailing list

Undeadly posted the following request.

Pre-Orders are Up for 3.9! Buy stuff!!!!

Pre-orders are up for 3.9, so you can all whip out your plastic and support the project.

The first release candidate for 0.1.1.x branch of TOR was announced.

This is the first release candidate for the 0.1.1.x series.

I noted the following bugfix as well.

– When we’re printing strings from the network, don’t try to print
non-printable characters. This protects us against shell escape
sequence exploits, and also against attacks to fool humans into
misreading their logs.

The 2006 SXSW music festival begins on Wednesday (14-03-2006).

The SXSW MUSIC AND MEDIA CONFERENCE showcases hundreds of musical acts from around the globe on over fifty stages in downtown Austin. By day, conference registrants do business in the SXSW Trade Show in the Austin Convention Center and partake of a full agenda of informative, provocative panel discussions featuring hundreds of speakers of international stature.

Sadly, I won’t be there.

Posted in Conferences, NYCBUG, Off-topic | No Comments »

Bank ordeal

Wednesday, March 8th, 2006

So, I went off to the bank (a branch office of a major financial) to open a new account. I noted a few of things during the (two and a half hour!) ordeal.

Social security numbers appear to be used as an index for bank accounts (no, not as the actual account numbers), and they knew of an old, deceased account I had with a bank they bought out a number of years ago based on my social security number.
When opening bank accounts, two forms of identification are required, and credit cards are considered a form of identification.
When depositing checks in amounts greater than $5000.00 upon opening new accounts, the timeframes for clearing are a bit longer due to additional processing and reporting requirements.
The workstations were slow, terribly slow, at performing their tasks. One machine even froze up just after entering all the information necessary to create my account, and we sat there chatting while waiting for about fifteen minutes to see if it would start working again. I kindly suggested CTRL-ALT-DEL, which did nothing as the box was totally locked, and then suggested power cycling. Windows XP crawled during boot and login until, after about fifteen minutes, the necessary applications were running again and they were (re-)entering my information. Then one of the printers would not print, so we had to debug that, checking the paper tray, toner, connection, etc. (I was not allowed to get on their workstation at this point) and eventually just switched to a different printer.
During the process of signing up for online banking, a senor bank person let me sit at their desk and access their machine directly to create my online banking account. They then walked away, leaving me alone at this machine for a couple of minutes. Yes, alone at the machine, fully logged on with their credentials, which, based on the transactions already performed for me, included the ability to create bank accounts, modify bank accounts, transfer money, and order debit cards and establish PINs for said cards. I wished they had at least exited/locked some of the applications that were running (and logged into), but no, they didn’t.

As to item five, given the senor bank person and I were clearly growing impatient with the various obstacles and delays created by the infrastructure problems, they tried to multitask by getting me working on creating my online account while they ran around grabbing printouts and getting other tasks done, like depositing checks. When people have to rely on an infrastructure that is clearly not meeting their needs, it frustrates them and can sometimes lead to various workarounds in an attempt to make up for the infrastructure. In this case, those workarounds combined the common priority of useability over security to create item five.

As to item four, that is the type of situation D-kriptik is in business to avoid. Afterall, at our core, we are trying to bring people and technology together for the better.

Posted in Customer service, D-Kriptik, Security | 3 Comments »

Barnum statements, validation limitations, network routing virtual machines, cool not secure, and laptop shades

Tuesday, March 7th, 2006

A NYCBUG reader asked me via email “who is this. . .”, setting the stage for my usual sense of humor and a good article pointer for this blog.

I think this rather difficult question was directed at me, Andrew Donofrio, as I attend the NYCBUG meetings quite frequently.

So, I sit here pondering how to answer a question such as this. After all, who is anyone really?

Meditating for days, alone, without sleep, drink, food, or bath, I went on a journey that freed my mind. I escaped the confines of my body, in the most minuscule of forms, a spec of dust, and I was immediately swept up by great winds. I circled the globe, faster and faster, until everything became a smear ~~swear~~ ~~swirl~~ of green and blue and gray, and then, boom, I was thrown out into space, where I floated through the vast universe, witnessing wonders no human being had ever seen. Days, months, years, centuries, eons all swept by, and I felt a great peace, the peace of being so close to complete freedom as to know I could just slip into it and leave everything else behind. Then the moment arrived, the point where the elastic strand of thought that still attached me to my body was at its limit. A choice had to be made – let the strand snap or snap back. “Timshel,” I cried out with an energy that rippled the universe around me.

When I returned to my body and left my trance, the following realizations had been realized as really important to my reality.

I have a great need for people to like and admire me.
I have a tendency to be critical of myself.
I have a great deal of unused capacity which I have not turned to my advantage.
Disciplined and self-controlled outside, I tend to be worrisome and insecure inside.
At times I have serious doubts as to whether I have made the right decision or done the right thing.
I prefer a certain amount of change and variety, and become dissatisfied when hemmed in by restrictions and limitations.
I pride myself as an independent thinker, and don’t accept others’ statements without satisfactory proof.
I have found it unwise to be too frank in revealing myself to others.
At times I am extroverted, affable, sociable, while at other times I am introverted, wary, reserved.
Security is one of my major goals in life.

“True of us all,” you might say. I would retort, “then why did you waste my time asking me a question to which you already knew the answer.”

-Andrew

PS Bald guy. Easy to spot. Oh, and that list is a bunch of Barnum statements.

Barnum statements are defined here as follows, which is where that list was taken from.

Barnum statements are general personality descriptions which apply to almost everyone, under most circumstances (see e.g. Tyson, 1982; Furnham and Schofield, 1987). Acceptance of such statements is referred to as the Barnum effect. Dickson & Kelly (1985: 367) have defined the effect as the tendency for “people to accept general personality interpretations as accurate descriptions of their own unique personalities”.

These are used by pseudo-psychics and psychologist alike to get people talking, and they are also good discussion points in that first conversation with a newly met stranger.

The article providing that definition is an exploration of the cold reading techniques employed by pseudo-psychics, and it gives an interesting window into a set of techniques employed by a group of social engineers skilled at extracting information from people. This is definitely a good read for people in the security arena.

This chapter began by describing how subjectively impressive psychic readings have been accounted for in terms of deceptive practices known as cold reading. Existing characterisations of cold reading were criticised as too vague and inconsistent to be useful. A new model of cold reading strategies was elaborated, informed by a review of magic literature concerned with pseudopsychic techniques, and by an exploratory study with a practicing pseudopsychic. These suggested that cold reading may be more usefully regarded as consisting of a number of discrete strategies which generate information about the client in different ways. These strategies were described and illustrated. The methods were characterised as falling into a hierarchical arrangement. Those lower down the hierarchy are effective under conditions of impoverished feedback, but are capable of only relatively general information. Indeed, their primary purpose often is to act as a platform for more sophisticated methods, since the generation of more specific information by ‘higher’ strategies can be dependent upon the use of more basic methods to provide the material necessary to encourage reactions from the client or to misdirect them away from their own contributions.

Someone that calls many articles to my attention has an article of their own, as mentioned here.

Information Security Magazine has published a column I wrote to discuss a common misperception of FIPS 140 and Common Criteria. The column briefly describes the value and process for obtaining FIPS 140 and Common Criteria validation. But the main point of the column is to make a case that these certifications are not a panacea for security concerns for products deployed into a system.

Check it out here. Also, this post makes a point relevant to that article.

A key point to make here is that, if the requirements are meaningless to the user, then the assurance around those requirements tends to be meaningless as well. I think TaoSecurity was trying to make such a point here about the Windows CC certifications.

Virtual machines are an easy way to setup environments for building and playing with things, from software development to network architectures, without requiring a bunch of physical machines to be at your disposal. In this case, the goal was an easy and cheap environment to play with network routing.

Some time before Christmas, a project was started. The task was to
enhance an existing LiveCD solution with User-mode Linux. A number of
requirements was stated, where the greatest challenge was to fit 10
virtual routers within an old no-name PC with only 256MB Ram. And the
solution must still be run from a LiveCD.

Thanks to Xen, the task was possible to complete.

-But, what does it do?

With this solution, students taking CCNA/CCNP level studies can have
their own router lab on a bootable CD. No need for expensive equipment.
The student can set up a virtual network of 10 routers or hosts, and
exercise BGP, OSPF, ISIS and RIP routing. The routing software is
Quagga, whose interface is very similar to Ciscos native CLI.

via a xen-devel message forwarded to cypherpunks

Being cool doesn’t mean being secure.

Someone got root from a shell account on OS X in under 30 minutes!

This reminds me of old school cameras.

The Laptop Privacy Hood (Laptop Screen Shade) is ideal for working on trains, planes or even in the car as it enables screening of confidential documents from prying eyes in addition to shading reflections in bright conditions.

Don’t go for black though. Be a proud geek.

via So Says Beetle

Posted in Off-topic, Security | 1 Comment »

NYC BUG Meeting March 2006, etc.

Saturday, March 4th, 2006

So, I had what was supposed to be an informal meeting with a small business to discuss how to go about upgrading their current infrastructure to support their growth from 3 people to a planned 10 people over the course of this year. We were originally going to meet in a bar, but ended up in a conference room, where I briefly presented about what I have experienced during such a transition and then was interrogated for quite a while.

After this meeting, I was on my way to the NYCBUG meeting, when I remembered the meetings had been changed from 6:00PM EST to 6:30PM, so, being in the area of Heathers, I popped in for a drink. Heather soon came in, and she mentioned that she used to do some tech support for Macs. We discussed that I may need more Mac people in the future, and, while she was not directly interested in such a role, she knew people who would be. Good to know.

Unfortunately, the next thing I knew, it was after 6:30PM, so I dashed out of Heathers and ran up to Baruch college on E 25th. By the time I made my way to the proper room (through two security checkpoints), it was the question and answer (QnA) portion of Ray Lai’s presentation on systrace. I was disappointed to only catch the last 15 minutes of his talk, as systrace is a good topic and its use is not as widespread as i’d expect in OpenBSD server environments.

My notes on the QnA follow.

There was a question about whether systrace has had any security issues itself, which made me chuckle a bit. Ray answered that it had on NetBSD (not OpenBSD), the last one that he knew of discovered back in 2004 (a quite simple local exploit).

There was some discussion about using systrace to debug applications, which I had never really thought of explicitly in those terms before and so had me mumbling to myself a little in thought. For example, whenever an application crashes because systrace limited its access, well, you then go about debugging what access that application thinks it needs and why. I think the gist was taking the concept of that example and using it to learn about limiting an application’s privileges during development and testing.

Johnny Lam chimed in about using systrace to lockdown builds. When you download the source code for some rogue application and build it, you really don’t know what is going to happen during that build process. Since building generally requires a very limited set of permissions, it is easy to run the build in systrace with a very strict policy and note any weird access attempts. (I have really enjoyed hearing Johnny Lam discuss his NetBSD development environment, from encrypted file-backed domains in Xen with keys stored on a token to builds conducted using systrace.)

Ray noted that the OpenBSD ports have the option to use systrace during builds, although this option is not enabled by default (set the “USE_SYSTRACE” variable to “Yes”).

There was some discussion about systrace being easier to implement in server environments, where the services provided are normally well-defined and quite limited, versus a desktop environment, where there is a wide variety of software that a user may wish to run and covering all of it with systrace can be a huge, complicated task.

Systrace is part of base on both NetBSD and OpenBSD.

The presentation slides are available online here, and an audio recording of the presentation can be found here. (I am listening to it right now.)

Thanks to Ray Lai for presenting and NYCBUG for its continued efforts.

Posted in BSD, Conferences, D-Kriptik, NYCBUG | No Comments »

D-kriptik Blog