creating byte[] with subfields

R

Roedy Green

I often have to construct byte arrays with binary fields, or read
them.

I use a ByteArrayOutputStream and a DataOutputStream to compose them.
I wondered if there is a simpler way, one that does not require
computing each byte individually with shifts.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law
 
J

Jim Janney

Roedy Green said:
I often have to construct byte arrays with binary fields, or read
them.

I use a ByteArrayOutputStream and a DataOutputStream to compose them.
I wondered if there is a simpler way, one that does not require
computing each byte individually with shifts.

In C, sure. Java by design doesn't allow those kinds of tricks.
 
N

Nigel Wade

I often have to construct byte arrays with binary fields, or read
them.

I use a ByteArrayOutputStream and a DataOutputStream to compose them.
I wondered if there is a simpler way, one that does not require
computing each byte individually with shifts.

BitSet, and its toByteArray() method may do what you require.

I've not tried it myself. I still do it by shift/mask.
 
J

Jim Janney

Jim Janney said:
In C, sure. Java by design doesn't allow those kinds of tricks.

The hotspot compiler might notice that you're shifting and masking by 8
bits and replace it with direct byte addressing. That seems like a
straightforward optimization. OTOH, the speed difference is probably
too tiny to notice anyway.
 
D

Daniel Pitts

I often have to construct byte arrays with binary fields, or read
them.

I use a ByteArrayOutputStream and a DataOutputStream to compose them.
I wondered if there is a simpler way, one that does not require
computing each byte individually with shifts.
How about using a BitSet instead?

Or, avoid this level of low-level work?

Or, create a helper wrapper class. BitStream, where you can write a
number of bits, rather than whole bytes.
 
R

Roedy Green

How about using a BitSet instead?

I don't often have to do anything finer than the byte.
On project I did recently involved XOR encryption, where you need
everything in bytes to be able to xor.

Last night I was composing/decomposing a DataPacket for
SingleInstance.

I did one to handle Network Time Protocol.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law
 
D

Daniel Pitts

I don't often have to do anything finer than the byte.
On project I did recently involved XOR encryption, where you need
everything in bytes to be able to xor.

Last night I was composing/decomposing a DataPacket for
SingleInstance.

I did one to handle Network Time Protocol.
FWIW, XOR encryption is more like XOR obfuscation. It doesn't actually
encrypt, at least not the naive approach to it.
 
A

Arne Vajhøj

I often have to construct byte arrays with binary fields, or read
them.

I use a ByteArrayOutputStream and a DataOutputStream to compose them.
I wondered if there is a simpler way, one that does not require
computing each byte individually with shifts.

A DataOutputStream on top of a ByteArrayOutputStream is the
old Java way of doing it. And if you do not need to manipulate bits
and you are happy with big endian then you should not to use shifts.

The new Java way is ByteBuffer which support both big and little
endian, so you only need shift for bit manipulation.

Those are both pretty low level. If you need something more
high level, then you will need to look outside of standard
Java API.

Arne

PS: I actually have something on the shelf for that.
 
A

Arne Vajhøj

A DataOutputStream on top of a ByteArrayOutputStream is the
old Java way of doing it. And if you do not need to manipulate bits
and you are happy with big endian then you should not to use shifts.

The new Java way is ByteBuffer which support both big and little
endian, so you only need shift for bit manipulation.

Those are both pretty low level. If you need something more
high level, then you will need to look outside of standard
Java API.
PS: I actually have something on the shelf for that.

Data class:

import dk.vajhoej.record.Endian;
import dk.vajhoej.record.FieldType;
import dk.vajhoej.record.Struct;
import dk.vajhoej.record.StructField;

@Struct(endianess=Endian.LITTLE)
public class Data {
@StructField(n=0,type=FieldType.BIT,length=4)
private int bf1;
@StructField(n=1,type=FieldType.BIT,length=4)
private int bf2;
@StructField(n=2,type=FieldType.INT4)
private int iv;

@StructField(n=3,type=FieldType.VARSTR,prefixlength=1,encoding="ISO-8859-1")
private String sv;
public Data() {
this(0, 0, 0, "");
}
public Data(int bf1, int bf2, int iv, String sv) {
this.bf1 = bf1;
this.bf2 = bf2;
this.iv = iv;
this.sv = sv;
}
public int getBf1() {
return bf1;
}
public void setBf1(int bf1) {
this.bf1 = bf1;
}
public int getBf2() {
return bf2;
}
public void setBf2(int bf2) {
this.bf2 = bf2;
}
public int getIv() {
return iv;
}
public void setIv(int iv) {
this.iv = iv;
}
public String getSv() {
return sv;
}
public void setSv(String sv) {
this.sv = sv;
}
}

Test program:

import dk.vajhoej.record.RecordException;
import dk.vajhoej.record.StructReader;
import dk.vajhoej.record.StructWriter;

public class RW {
public static void main(String[] args) throws RecordException {
Data o1 = new Data(1, 2, 3, "ABC");
StructWriter sw = new StructWriter();
sw.write(o1);
byte[] ba = sw.getBytes();
for(byte b1 : ba) {
System.out.printf(" %02X" , b1);
}
System.out.println();
StructReader sr = new StructReader(ba);
Data o2 = sr.read(Data.class);
System.out.println(o2.getBf1() + " " + o2.getBf2() + " " + o2.getIv()
+ " " + o2.getSv());
}
}

Output:

12 03 00 00 00 03 41 42 43
1 2 3 ABC

Arne
 
R

Roedy Green

FWIW, XOR encryption is more like XOR obfuscation. It doesn't actually
encrypt, at least not the naive approach to it.

It depends. I just finished a project which I will be permitted to
release into the public domain in a year which uses one time pads,
which XOR messages with strings of truly random bits.

The only way you can crack it is to crack the machine at either end or
intercept the key transfer. You can't do it just by studying
messages.
--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law
 
A

Arne Vajhøj

FWIW, XOR encryption is more like XOR obfuscation. It doesn't actually
encrypt, at least not the naive approach to it.

Not today. 200 years ago it would (1 byte XOR is really
a special case of 1 replacement alphabet and N byte XOR
of N replacements alphabets).

Arne
 
D

Daniel Pitts

It depends. I just finished a project which I will be permitted to
release into the public domain in a year which uses one time pads,
which XOR messages with strings of truly random bits.

The only way you can crack it is to crack the machine at either end or
intercept the key transfer. You can't do it just by studying
messages.
It really does depend.

If the plain-text are formed poorly (eg. plain ascii text, or contains
any well known substrings), and the key is sufficiently small (needs to
be repeated several times) one could easily figure out the key, or at
least part of it. That could be enough to turn it into a simple word
game, which will eventually reveal the entire plain-text.
 
J

Joshua Cranmer

It really does depend.

No, it doesn't. A one-time pad is provably 100% perfectly secure, and is
the only cryptographic method to be so proven. The requirements is that
you have a string of random bits as long as the message you send and you
never reuse those random bits ever again.
 
A

Arne Vajhøj

It really does depend.

If the plain-text are formed poorly (eg. plain ascii text, or contains
any well known substrings), and the key is sufficiently small (needs to
be repeated several times)

A one time pad by definition has a key size equal to message
size so the key does not repeat.

Arne
 
A

Arne Vajhøj

No, it doesn't. A one-time pad is provably 100% perfectly secure, and is
the only cryptographic method to be so proven. The requirements is that
you have a string of random bits as long as the message you send and you
never reuse those random bits ever again.

And there is a good reason why it is not called two times pad.

In the late forties the Russians had a shortage of one time pads
and started using twice - once for military stuff and one for
civilian stuff. In the sixties the British and Americans discovered
that and started cracking it.

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

StringBuilder for byte[] 11
video cards for Java 1
ctrl-c ctril-v 14
regex reserved chars 23
jdk 1.7.0_13 is out 4
abbreviated generic syntax 14
probing SSL websites 1
slick progress bar 5

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top