Hi Arpad, my understanding of the core session logic is that my module should not impact the behaviour in any such corner cases. I believe they will succeed/fail just as they would succeed/fail if the proxied module was called without being proxied through SSDS. However: I don't have any testcases for that (yet) - give me a couple of days and I'll provide my results.
As to your question of the IV computation: the IV has no confidentiality requirements - in fact it is "public": it is stored as a prefix to the crypted session data itself. The logical data structure of SSDS generated session-data is 1. base64 encoded ciphertext (actual session-data) 2. a seperator character 3. the hex encoded IV So let's consider the example on slide 15 of my presentation (Session-ID=viq6ehuba8lb9gpg6g1hi7g3n7). Thus, the contents of the file /var/lib/php5/sess_e73407a8d1ac72ca03c599b660ae9ae7 are (line breaks inserted by me to demonstrate the data structure 9Ar5gGImihQ7B+/g7m6l+4it9VdU8/Y/b2c5LFk2IPY= # 9281b50004c880e0e317615c9d7fd2fa Where "9A...PY=" is the based encoded ciphertext (of what would have been written in plaintext to the file without SSDS). The hashmark "#" is the separator character and "92...fa" is the hex encoded IV. So, the IV is actually present within the session-data that SSDS generates. That's entirely OK though, because IVs are sort of expected to be "public" (as in: known to an adversary) in most crypto implementations. Jürgen PS: You also mention that the filename is the Session-ID, which is not the case: the filename is a hash derived from the Session-ID - but not the Session-ID itself. Am Freitag, den 16.08.2013, 01:27 +0100 schrieb Arpad Ray: > Hi Jürgen, > > On Wed, Aug 14, 2013 at 11:26 PM, Jürgen Pabel <[email protected]> > wrote: > An introduction/overview to my extension can be found online: > > http://programm.froscon.de/2012/system/attachments/202/original/2012-08-26%20-%20FrOsCon%20-%20php-ssds.pdf > > Key idioms while implementing this extension were simplicity > for > deploying administrators and runtime compatibility: > configuration is > easy and PHP applications must not be modified. All session > storage > backends (save_handler's) are automatically supported. > > My current release is just a few minutes old and should meet > all > requirements for PHP extensions (that I am aware of, at > least). In > addition, the implementation has been source-code audited by > several > experts and no weaknesses have been found. I consider it to be > production-ready. > > > Thanks for your work, from a quick read-through the code looks nice > and clean, however I think there's at least a couple of issues: > > > > - It relies on the proxied session module behaving nicely when called > in an unexpected manner which may happen given the extra logic your > module imposes, e.g. close before read. Do you have tests for this > kind of situation? How about user session handlers? > > > - In your paper you say that the IV is computed as > hash[iv_hash](concat(NOW,SESSION-ID)) to avoid draining the PRNG, but > when for example the proxied session module is the files module, NOW > is ~ the file ctime and SESSION-ID is the file basename, so unless I'm > misunderstanding something, the IV is trivially known by your > hypothetical attacker with access to the file system. > > > Regards, > > > Arpad -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
