Default PBKDF2 Iteration Count for Encrypted Keys Generated by OpenSSL

When generating keys with openssl you have the option to encrypt them. It is done by specifying a cipher alogrithm, for example

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -aes-128-cbc -out key.pem 

generates a 2048 bit RSA key and encrypts it with AES in CBC mode. OpenSSL will prompt you to provide a pass-phrase for the encryption. It is important to understand how that pass-phrase/password will be used to derive a key for the AES encryption. The whole encryption scheme is defined by something called PBES2 1, which in turn uses PBKDF2. The important factor on the computation complexity of PBKDF2, is the number of hash-iterations used.

OpenSSL doesn’t have an option in its command-line utilities to control that number of iterations. However, that number is allowed to change pretty much arbitrarly by the standard, so it is part of the ASN1 representation of the generated encrypted key.

$ openssl asn1parse -i -in key.pem  | head
    0:d=0  hl=4 l=1311 cons: SEQUENCE          
    4:d=1  hl=2 l=  73 cons:  SEQUENCE          
    6:d=2  hl=2 l=   9 prim:   OBJECT            :PBES2
   17:d=2  hl=2 l=  60 cons:   SEQUENCE          
   19:d=3  hl=2 l=  27 cons:    SEQUENCE          
   21:d=4  hl=2 l=   9 prim:     OBJECT            :PBKDF2
   32:d=4  hl=2 l=  14 cons:     SEQUENCE          
   34:d=5  hl=2 l=   8 prim:      OCTET STRING      [HEX DUMP]:F3098873E5AB1A81
   44:d=5  hl=2 l=   2 prim:      INTEGER           :0800
   48:d=3  hl=2 l=  29 cons:    SEQUENCE       

The line saying INTEGER :0800 states the number of iteration used (in hex notation) for the generated key.pem. It means that at least for OpenSSL 1.0.1, the default number of iterations is 0x800=2048. This number is relatively low in modern standards2.

  1. As the name suggest there is also PBES1, which is now obsolete. The main difference is that PBES1 only allowed DES and RC2 to be used as cipers. See RFC 2898 for more details. 
  2. Apple uses 10,000 iterations for iTunes passwords, and LastPass defaults to 5,000 

Setting Up Lighttpd with PHP-FPM

PHP-FPM can provide an alternative to spawn-fcgi when setting up Lighttpd with PHP. It has several advantages over using spawn-fcgi among them:

  • It can dynamically scale and spawn new processes as needed.
  • Gracefully respawn PHP processes after configuration change.
  • Comes with init.d script so no need write your own.
  • Ability to log slow PHP script execution (similar to MySQL’s slow query log).


PHP-FPM is available from the Ubuntu (since 12.04) and Debian’s repositories, so all you need to do is:

$ sudo apt-get install php5-fpm


PHP-FPM works with process pools. Each pool spawns processes independently and have different configurations. This can be useful to separate the PHP process of each user or major site on the server. PHP-FPM comes with a default pool configuration in /etc/php5/fpm/pool.d/www.conf. To create new pools, simply copy the default pool configuration and edit it. At least you will need to set the following:

  • Pool name – [www]. I name mine according to the user which the pool serves.
  • user – I set the user to the appropriate user, and leave group as www-data.
  • listen = /var/run/php.$pool.sock – Unix sockets have lower overhead than tcp sockets, so if both Lighttpd and PHP run on the same server they are preferable. $pool will be expanded to your pool name. Also, it is more secure to create the sockets in a directory not writable globally (such as /tmp/) so /var/run is a good choice.
  • listen.owner should match the PHP user, while should match the group Lighttpd runs in, so both have access to the socket.

If you copied www.conf to create new configuration, you will need to rename it to something like www.conf.default in order to disable it.

In the Lighttpd configuration you need to add the following to each vhost that uses PHP:

fastcgi.server    = ( ".php" => 
                "disable-time" => 0,
                "socket" => "/var/run/php.pool.sock",

Where pool in the socket configuration is replaced by the matching pool name in the PHP-FPM configuration. Overriding disable-time and setting it to 0, is suitable in the case you have only one PHP backend and it’s local. In this scenario, attempting to connect to the backend is cheap, and if it gets disabled no requests will get through any way.

Useful Files

  • /etc/php5/fpm/pool.d – The PHP-FPM pool configuration directory.
  • /var/log/php5-fpm.log – The PHP-FPM error log. It will display error and warning notifying you when pm.max_children has been reached, when processes die unexpectedly, etc.

Creating a Hebrew Document in LyX 2.1 with XeTeX

This post complements the basic LaTeX template I gave yesterday for typesetting Hebrew with XeTeX. I’ll walk through the (short) list of steps needed to configure LyX with XeTeX.


  • LyX 2.1 or later (I’ve also tested with the development version of 2.2). I had very limited success with LyX 2.0, so you should probably avoid it.
  • XeTeX – I’ve tested with version 3.1415926-2.4-0.9998 which comes with TeXLive 2012, but I guess any recent version will do.
  • The polyglossia and bidi packages. Again I’ve used those which come with TeXLive 2012.
  • Good TrueType Hebrew fonts. I recommend Culmus 0.121 or newer. You may also try and use the fonts that come with your operating system, they might work as well.

Setting up the document

Create a new document and open the settings dialog (Document -> Settings...).

  1. Pick a suitable Document class. I recommend “KOMA-Script Article” but “Article” works just as fine. Avoid “Hebrew Article”, as it is broken under XeTeX.
  2. Under Fonts check the box next to `Use non-TeX fonts (via XeTeX/LuaTeX) and select suitable fonts:
    • Roman: Frank Ruehl CLM. David CLM is also a good choice with somewhat better italics variant.
    • Sans Serif: Simple CLM.
    • Typewriter: Miriam Mono CLM.
    • There is no need to change the Math font.
  3. Under Language select Hebrew as the document’s language.

That’s basically it. You can now write your document and compile it. I would suggest saving these settings as default (via “Save as Document Defaults”) or saving it as a template so you won’t need to repeat those steps.

Writing in English

To insert English text in your Hebrew document, you need to change the current language. The easiest way to do so is to create a keyboard shortcut for it:

  1. Go to Tools -> Preferences -> Editing -> Shortcuts
  2. Write “language” under “Show key-bindings containing:”.
  3. Select “language” under “Cursor, Mouse and Editing Functions” and click “Modify” to set a keyboard shortcut (F12 is traditionally used for this).

Now you can toggle the current language between English and Hebrew by simply pressing F12.

Remark about Fonts

It is preferable to use fonts that provide both Hebrew and Latin scripts, as otherwise there might be significant style differences which make the document look weird. It is possible to set a different font for Hebrew and Latin, but care needs to be taken to match styles. To do so, add the following lines to the Preamble:

\newfontfamily\hebrewfont[Script=Hebrew]{David CLM}
\newfontfamily\hebrewfonttt[Script=Hebrew]{Miriam Mono CLM}
\newfontfamily\hebrewfontsf[Script=Hebrew]{Simple CLM}

Hebrew with XeTeX Example

This is an example of a document in XeTeX (Actually XeLaTeX). I’ve used The fonts from the Culmus Project. Note that you’ll need Culmus 0.121 or newer in order to get the Frank Ruehl font in TrueType. As you can see, Nikud are placed correctly. The cantillation marks (טעמי המקרא) are in a small offset compared to the ideal position.

Overall, XeTeX works much better with Hebrew (and easier to use) than pdfTeX.


\setmainfont{Frank Ruehl CLM}
\setmonofont{Miriam Mono CLM}
\setsansfont{Simple CLM}
% Use the following if you only want to change the font for Hebrew
%\newfontfamily\hebrewfont[Script=Hebrew]{David CLM}
%\newfontfamily\hebrewfonttt[Script=Hebrew]{Miriam Mono CLM}
%\newfontfamily\hebrewfontsf[Script=Hebrew]{Simple CLM}
טקסט רגיל
\textbf{טקסט מודגש}
\textit{טקסט נטוי}
\textit{\textbf{טקסט מודגש ונטוי}}
בְּרֵאשִׁ֖ית בָּרָ֣א אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת הָאָֽרֶץ:
In the beginning God created the heaven and the earth.
טקסט רגיל
\textbf{טקסט מודגש}
\textit{טקסט נטוי}
\textit{\textbf{טקסט מודגש ונטוי}}
בְּרֵאשִׁ֖ית בָּרָ֣א אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת הָאָֽרֶץ:
In the beginning God created the heaven and the earth.
טקסט רגיל
\textbf{טקסט מודגש}
\textit{טקסט נטוי}
\textit{\textbf{טקסט מודגש ונטוי}}
בְּרֵאשִׁ֖ית בָּרָ֣א אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת הָאָֽרֶץ:
In the beginning God created the heaven and the earth.

Creating Menu Entries for Calibre

I recently installed Calibre using their binary installer for linux, and found out that it doesn’t come with .desktop files, so Calibre doesn’t appear in the GNOME menu. To remedy this I installed the following desktop files in ~/.local/share/applications/ (modified from the Debian Sid package):

[Desktop Entry]
Name=E-Book Viewer
Comment=E-Book Viewer
Exec=/home/user/.local/calibre/ebook-viewer %F


[Desktop Entry]
GenericName=E-book library management
GenericName[de]=E-Book Bibliotheksverwaltung
Comment=E-book library management
Comment[es]=aplicación para la gestión de libros electrónicos
Comment[de]=E-Book Bibliotheksverwaltung
Exec=/home/user/.local/calibre/calibre %f

You may need to adjust the paths for TryExec, Exec and Icon to match where you installed Calibre.

RTL Tiddlers in TiddlyWiki 5

Few years ago I wrote about how to create RTL (right-to-left) tiddlers in TiddlyWiki. Creating RTL tiddlers is almost a necessity if you want to create tiddlers in a right-to-left language such as Hebrew or Arabic. TiddlyWiki5, the new version of TiddlyWiki, broke the old solution, but a similar one is can be made. In order to be able to add RTL tiddlers to your TiddlyWiki follow these steps:
Continue reading

Kindle Paperwhite “Unable to Open Item”

Recently, I tried transfering some new ebook to my Kindle Paperwhite (first generation), the books were listed properly. However, when I tried to open them I got
“Unable to Open Item” error, suggesting I re-download the books from Amazon. I tried transferring the files again and again, but it didnt’ help. Some of the books were mobi files while others were “AZW` (which I got from אינדיבוק) and all of them opened fine on my computer.

Finally, I followed an advice from a comment in the KindledFans blog, and converted the files to AZW3 (the original comment suggested mobi but AZW3 works better with Hebrew). After converting, I moved the files to my Kindle and they opened just fine.

Enabling Compose-Key in GNOME 3.4

For some reason I couldn’t easily find how to enable the compose-key in Gnome 3.4. All the references I’ve found did not match the actual menus and dialogs that I saw on my system. That is including the official GNOME help pages. So I’ve decided to document it here for my future reference.

  1. Go to System Settings->Keyboard Layout.
  2. Select the Layouts tab and click Options.
  3. Under Compose key position, select the key you want to use as the compose-key.

Wikipedia has a nice table summarizing the compose-key sequences.

gettext with Autotools Tutorial

In this tutorial we walk through the steps needed in order to add localizations to an existing project that uses GNU Autotools as build system.

We start by taking a a slightly modified version of the Hello World example that comes with Automake sources. You can keep track of the changes to the source throughout this tutorial by following the commits to amhello-gettext on GitHub. We start with the following files:

$ ls -RF
.:  README  src/


Running gettextize

The first step is copying some necessary gettext infrastructure to your project. This is done running gettexize in the root directory of your project. The command will create a bunch of new files and modify some existing files. Most of these files are auto-generated, so there is no need to add them to your version control. You should only add those files you create or modify manually.

You will need to add the following line to your


The version specified is the minimum required version of gettext your package can compile against.

Copy po/Makevars.template to po/Makevars and modify it as needed.

The next step is to copy over gettext.h to your sources.

$ cp /usr/share/gettext/gettext.h src/

libintl.h, which is the header that provides the different translation functions. gettext.h is a convenience wrapper around it which allows disabling gettext if the --disable-nls is passed the ./configure script. It is recommended to use gettext.h in favor of libintl.h.

Triggering gettext in main()

In order for gettext to work, you need to trigger it in your main(). This is done by adding the following lines to the main() function:

setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);

You should also add #include "gettext.h to the list of includes.

PACKAGE should be the name of your program, and is usually defined in config.h file generated by either autoconf or autoheader. To define LOCALEDIR we need to add the following line to src/

AM_CPPFLAGS = -DLOCALEDIR='"$(localedir)"'

If AM_CPPFLAGS is already defined, just append to it the -DLOCALEDIR='"$(localedir)"' part.

Marking strings for translation

At this point, your program should compile with gettext. But since we did not translate anything yet it will not do anything useful. Before translating we need to mark the translatable strings in the sources. Wrap each translatable string in _(...), and add the following lines to each file that contains translatable strings:

#include "gettext.h"
#define _(String) gettext (String)

Extracting string for translation

Before extracting the strings, we need to tell gettext where to look. This is done by listing each source file with translatable strings in po/ So in our example po/ should look like:

# List of source files which contain translatable strings.

Afterwards the following command can be used to actually extract the strings to po/amhello.pot (which should go in the version control):

make -C po/ update-po

If you haven’t ran ./configure yet you need to run autoreconf --install && ./configure before running the above make command.

Translating strings

To begin translating, you need to a *.po file for your language. This is done using msginit:

cd po/ && msginit --locale he_IL.utf8

The locale should be specified as two-letter language code followed by two-letter country code. In my example, I’ve used Hebrew, hence it will create a po/he.po file. To translate the program you edit the .po file, using either a text editor or a dedicated program (see list of editors here).

After you updated the .po file for your language, list the language in po/LINGUAS (you need to create it). For example, in my case:

# Set of available languages

Now you should be ready to compile and test the translation. Unfortunately, gettext requires installing the program in order to properly load the message catalogs, so we need to call make install.

./configure --prefix /tmp/amhello
make install

Now to check the translation simply run /tmp/amhello/bin/hello (you might need to change LC_ALL or LANGUAGES depending on your locale to see the translation).

$ LANGUAGE=he /tmp/amhello/bin/hello 
שלום עולם!

Final note about bootstrapping. When people checkout your code from the version control, many autogenerated files will be missing. The simplest way to bootstrap the code into a state which you can simple call ./configure && make is by using autoreconf:

autoreconf --install

Will add any missing files and run all the autotools friends (aclocal, autoconf, automake, autoheader`, etc.) in the right order. Additionally it will callautopointwhich copies the necessarygettextfiles that were generated when you calledgettextize` earlier in the tutorial. If your project is using ./ script that call the autotools utilities manually, you should add a call to autopoind --force before the call to aclocal.

Finally, those are the files that end up version controlled in our example:

$ ls -RF
.:  po/  README  src/

amhello.pot  he.po  LINGUAS  Makevars

gettext.h  main.c


Displaying Google Adsense in MediaWiki

This post shows how to insert code that displays ads in MediaWiki. The proposed methods use hooks instead of modifying the skin. This has two advantages:

  1. No need to modify each skin separately. This allows users to change skins and ads will be presented to them in the same logical place.
  2. It makes upgrades simpler. Hooks reside in LocalSettings.php which isn’t modified by MediaWiki version upgrades, unlike skins.

The examples below show how to insert ads into the header, footer and sidebar of each page. I’ve used the Google Adsense ad-serving code, but it could be easily replaced by the ad-serving code of any other ad network.
Continue reading