[Libreoffice-commits] core.git: 2 commits - comphelper/source package/source

[Michael Stahl]

 comphelper/source/misc/docpasswordhelper.cxx   |    6 +++---
 package/source/zippackage/ZipPackageStream.cxx |    4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

New commits:
commit 24063ec94bd3f8407827f03ccde8bd99790f85e2
Author: Michael Stahl <mstahl at redhat.com>
Date:   Wed Nov 9 18:44:17 2016 +0100

    comphelper: also bump PDBKDF2 count for password-to-modify
    
    The password-to-modify misfeature does not actually provide any
    security, but it may induce users to re-use passwords, so at least make
    it harder to crack the passwords.
    
    Change-Id: I0adf0e8e11b222fc469013e17a2695bd7122ad01

diff --git a/comphelper/source/misc/docpasswordhelper.cxx b/comphelper/source/misc/docpasswordhelper.cxx
index d384b4f..49fc0c3 100644
--- a/comphelper/source/misc/docpasswordhelper.cxx
+++ b/comphelper/source/misc/docpasswordhelper.cxx
@@ -74,9 +74,9 @@ uno::Sequence< beans::PropertyValue > DocPasswordHelper::GenerateNewModifyPasswo
     uno::Sequence< beans::PropertyValue > aResult;
 
     uno::Sequence< sal_Int8 > aSalt = GenerateRandomByteSequence( 16 );
-    sal_Int32 nCount = 1024;
+    sal_Int32 const nPBKDF2IterationCount = 100000;
 
-    uno::Sequence< sal_Int8 > aNewHash = GeneratePBKDF2Hash( aPassword, aSalt, nCount, 16 );
+    uno::Sequence< sal_Int8 > aNewHash = GeneratePBKDF2Hash(aPassword, aSalt, nPBKDF2IterationCount, 16);
     if ( aNewHash.getLength() )
     {
         aResult.realloc( 4 );
@@ -85,7 +85,7 @@ uno::Sequence< beans::PropertyValue > DocPasswordHelper::GenerateNewModifyPasswo
         aResult[1].Name = "salt";
         aResult[1].Value <<= aSalt;
         aResult[2].Name = "iteration-count";
-        aResult[2].Value <<= nCount;
+        aResult[2].Value <<= nPBKDF2IterationCount;
         aResult[3].Name = "hash";
         aResult[3].Value <<= aNewHash;
     }
commit 25205d5b29d0aade0ebd7c6405a91995d02a3a7c
Author: Michael Stahl <mstahl at redhat.com>
Date:   Wed Nov 9 18:42:46 2016 +0100

    package: ODF: bump PBKDF2 iteration counts
    
    Given recent elections we need to build a higher wall to keep the
    government out of our documents, and we will make the government
    pay for it.
    
    These iteration counts were considered appropriate a decade ago.
    
    http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256
    
    We get similar numbers on SandyBridge-E desktop and Haswell i7-4600U laptop:
    * with 10k iterations ~20 msec per derivation
    * with 100k iterations ~195 msec per derivation
    * with 150k iterations ~290 msec per derivation
    
    We can't go too high though because in ODF every package stream gets
    its own derived key with a different salt, so a document with embedded
    images may need a lot of these.
    
    Change-Id: I6894e71ed399f8c340eff97a9191c8d8419789a6

diff --git a/package/source/zippackage/ZipPackageStream.cxx b/package/source/zippackage/ZipPackageStream.cxx
index 17a6fac..932a5af 100644
--- a/package/source/zippackage/ZipPackageStream.cxx
+++ b/package/source/zippackage/ZipPackageStream.cxx
@@ -655,7 +655,7 @@ bool ZipPackageStream::saveChild(
                 uno::Sequence < sal_Int8 > aSalt( 16 ), aVector( GetBlockSize() );
                 rtl_random_getBytes ( rRandomPool, aSalt.getArray(), 16 );
                 rtl_random_getBytes ( rRandomPool, aVector.getArray(), aVector.getLength() );
-                sal_Int32 nIterationCount = 1024;
+                sal_Int32 const nPBKDF2IterationCount = 100000;
 
                 if ( !m_bHaveOwnKey )
                 {
@@ -665,7 +665,7 @@ bool ZipPackageStream::saveChild(
 
                 setInitialisationVector ( aVector );
                 setSalt ( aSalt );
-                setIterationCount ( nIterationCount );
+                setIterationCount(nPBKDF2IterationCount);
             }
 
             // last property is digest, which is inserted later if we didn't have