0

My situation: I have a video streaming service that allows users to pause / resume their videos and also watch multiple parts of them in parallel (like IDM) each of them can be paused and resumed. Performance is a significat issue here, so we chose HC-128 which is the best in performance according to this comparsion.

In HC as in most stream ciphers one of the security techniques is to set a counter when starting the algorithm and increasing that counter as more data gets encrypted.

My solutions works fine when the stream is downloaded in full (from index 0 to content.length()) but fails when I want to resume at a given location (say at byte 10000).

I use the default HC initialization process which sets the counter to 0. I tried to read the code of HC but couldn't come up with a solution.

How can I initialize HC-128 with a given counter position?

I also have a decryption APP to decrypt my stream but this is worked if counter incremented with incoming bytes.

There is a sample of HC 128 copied from bouncy castle library that works fine

You can run this code online here In main method "Hello World" is the input

Angelo Fuchs
  • 9,825
  • 1
  • 35
  • 72
java acm
  • 1,020
  • 12
  • 24
  • What is the problem with a resetted internal counter for `HC 128`? If a server establishes a open stream with the client using a stream cipher, the server encrypts information and the client decrypts it. Should the stream be stopped and recreated whats wrong with a resetted stream cipher? The operation of any cipher should be content irrelevant and trying to lock the stream ciphers internal counter to your plaintext data (i.e. context byte position) brings no benefit whatsoever. – initramfs Dec 14 '13 at 06:14
  • 1
    overhead of initialization of HC is highthe initialization phase of the cipher includes expanding the 256-bit key into the tables P, Q and then running the cipher for 4096 steps. The author of HC-256 estimates this process to take around 74,000 cycles. – java acm Dec 14 '13 at 12:11
  • also main problem with your solution is downloader app (for example IDM)after downloaded all part(by connection more than one) of a stream ,be joined into one file and if user wanted to decrypt by my app , app not know where is index 0 , because index of 0 is more than one part and your solution is not good for minimum footprint because i must be programmed a special downloader for do it and user is limited to selection of downloader app – java acm Dec 14 '13 at 12:20
  • 1
    I didn't find any claim that HAC-128 supports random access. Do you have a source for that? If you want random access, consider Salsa20, ChaCha or AES-CTR. – CodesInChaos Dec 15 '13 at 13:49
  • absolutely in any Stream Cipher not supported by main algorithm but must be handle by a technical trick. main problem is counter that is incremented. – java acm Dec 15 '13 at 18:45
  • please include any code samples and the like in your question. – Angelo Fuchs Mar 05 '14 at 10:08

0 Answers0