#2 Exception while creating Keystore


Using the following command to initialize a keystore, I get the following exception:

java -jar org.cumulus4j.keymanager.cli-1.0.0-SNAPSHOT.jar initDateDependentKeyStrategy -keyActivityPeriod 30s -keyStorePeriod 1y -keyStoreID test-fleque

java.lang.IllegalArgumentException: source too long! Cannot encode length 16819252 in 2 bytes!
at org.cumulus4j.keystore.KeyStoreUtil.writeByteArrayWithShortLengthHeader(KeyStoreUtil.java:74)
at org.cumulus4j.keystore.AbstractEncryptedData.write(AbstractEncryptedData.java:150)
at org.cumulus4j.keystore.EncryptedProperty.write(EncryptedProperty.java:85)
at org.cumulus4j.keystore.KeyStoreData.writeToStream(KeyStoreData.java:196)
at org.cumulus4j.keystore.KeyStore.storeToFile(KeyStore.java:1089)
at org.cumulus4j.keystore.KeyStore.setProperty(KeyStore.java:1455)
at org.cumulus4j.keystore.DateDependentKeyStrategy.init(DateDependentKeyStrategy.java:136)
at org.cumulus4j.keymanager.api.internal.local.LocalKeyManagerAPI.initDateDependentKeyStrategy(LocalKeyManagerAPI.java:128)
at org.cumulus4j.keymanager.api.DefaultKeyManagerAPI.initDateDependentKeyStrategy(DefaultKeyManagerAPI.java:88)
at org.cumulus4j.keymanager.cli.InitDateDependentKeyStrategySubCommand.run(InitDateDependentKeyStrategySubCommand.java:111)
at org.cumulus4j.keymanager.cli.KeyManagerCLI.main(KeyManagerCLI.java:138)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.simontuffs.onejar.Boot.run(Boot.java:306)
at com.simontuffs.onejar.Boot.main(Boot.java:159)


  • Alexander Bieber

    A faster way to reproduce this is:
    java -jar org.cumulus4j.keymanager.cli-1.0.0-SNAPSHOT.jar initDateDependentKeyStrategy -keyActivityPeriod 30s -keyStorePeriod 2d -keyStoreID test-fleque -userName fleque

  • Marco Schulze

    Marco Schulze - 2012-02-01

    I analysed the bug and created a test case for it:


    I already implemented a solution and tested it: It works fine, but it breaks compatibility: EncryptedProperty has now the (newly introduced) overridden method 'getEncryptedDataLengthHeaderSize()'. If the result is changed from 2 to 4, it works fine, but a bigger 'length' field means that the old key-stores cannot be read anymore.

    We therefore need to increment the file version number (from 1 to 2) and implement a mechanism that allows for reading old files (they can be automatically converted to the new format, IMHO - i.e. only reading needs to take the old version into account - writing doesn't necessarily).

    Because I do not have enough time, I left the file format unchanged, for now. Need to do this later.

  • Marco Schulze

    Marco Schulze - 2012-02-18
    • assigned_to: nobody --> nlmarco
    • status: open --> closed-fixed
  • Marco Schulze

    Marco Schulze - 2012-02-18

    There are now two supported key store file versions: 1 and 2. The KeyStore can read both and will always write version 2.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks