This week's book giveaway is in the Java in General forum.
We're giving away four copies of Helidon Revealed: A Practical Guide to Oracle’s Microservices Framework and have Michael Redlich on-line!
See this thread for details.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

Overhead IO : The cryptic case of the extra bytes

 
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Could resist the title sorry. Anyway, down to business. I wrote up a simple encoder/decoder program. For some reason, the decryption information always comes back with extra information. A sample of the program running is below. If I open the output file, it always contains some unreadable binary data, sometimes with extra spaces. The words show up fine, but there is extra data. Should I be using "ByteArrayOutputStream"?
If I print it out to the system, it shows up with extra spaces with every line, with no visible extra binary data. Please look at the bottom to see the weird results.
Here it is running :


I can edit out the unnecessary stuff if you want, but the code is relatively short so I won't bother unless you ask me too.



Here is the contents of "simple"

Here is the contents of output.ShouldBeWorking :


Thank you very much. I hope you all have a very Merry Christmas and a Happy New Year
John Price
 
Ranch Hand
Posts: 423
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

encrypt each line using cipher.update method instead of cipher.doFinal.
Call doFinal only on the last line (chunk of data).
Cipher.doFinal finishes the encryption - and probably fills the remaining space of a block by nulls or something else
(AES is a block encryption algorithm, as wiki says -> webpage it uses fixed 128-bits data block).
But update method appends the encrypted chunk to the block and continues the encryption.
Your encrypted file consist of several finished blocks of data created by doFinal , but you are reading this file by one call do doFinish.

Regards
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do I use to start the output? If I put doFinal for the first line, it prints out a blank line and then just the first line. If I put update for the first line, it produces an empty file. If you are wondering what I am saying, look below (I did change it to make it easier and less lines of code) :


Thanks,
John Price
 
Ireneusz Kordal
Ranch Hand
Posts: 423
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

You don' need to bother with reading data byte by byte, with buffers, separators etc.
use CipherInputStream and CipherOutputStream instead.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe this is my last issue. I can't seem to properly read the lines in. It's reading the proper amount of lines (3 for the test case), but it's reading each line in as "null". Thank you very much for your suggestion Ireneusz Kordal. I tried it without reading a file in (the information being retrieved from the CLI), and it worked 100%. I then tried reading a file in, but my logic below if faulty somewhere. Everything else seems to work fine. Thanks very much. I hope you all had a great Christmas and have a happy new year!


Thank you very much,
John Price
 
Sheriff
Posts: 22817
132
Eclipse IDE Spring Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
bufferedReader.readLine() moves the file position forward. Once it starts returning null it will return null forever. Use a List<String> instead of a String instead, and store the Strings as you encounter them:
You can (and should) even integrate the StringBuilder part into the first while loop.
 
Sheriff
Posts: 28344
97
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, yeah. First you read all of the lines in from the BufferedReader, until it returns null. But you don't do anything with those lines. Then you call nextLine() again that same number of times, which of course continues to return null each time because you already read of the lines in the first loop. And this time you store the nulls in an array.

So what's that all about? Why not just read the lines and put them into a List? That would be much simpler and it might actually work.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you guys very much. I appreciate all the work that you did for me. I want to shout out a special thanks to Ireneusz Kordal for helping me out on this particular thread very much. Thank you Rob Spoor and Paul Clapham also! I will be separating this into separate programs for my integration with one of my projects, but here is the final test project that I have edited :


Happy new year,
John Price
 
passwords must contain 14 characters, a number, punctuation, a small bird, a bit of cheese and a tiny ad.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic