c-rack / cbor-java Goto Github PK

Hi!

I was wondering if you would be interested in getting cbor-java fuzzed by OSS-Fuzz? Fuzzing is a technique for stress-testing applications and OSS-Fuzz is a service run by Google for fuzzing important open source projects, and it would be great to get cbor-java integrated with OSS-Fuzz. OSS-Fuzz will run the fuzzers continuously and report back with bug reports when bugs are found. These reports will have full stack traces, input triggers and more. If you are interested, then the only thing needed is an email(s) connected to a Google account that can be used for receiving the bugs reports, which can be put in the configuration file (project.yaml) over at the OSS-Fuzz repository.

I have set up an initial integration with OSS-Fuzz here: google/oss-fuzz#6788 and this PR on the OSS-Fuzz repository includes a simple initial fuzzer. We can always extend with more fuzzers if you are happy to integrate. I would just need an email and then get this PR merged, following that we should be good to go and down the line we can also migrate fuzzers from OSS-Fuzz to cbor-java owns repository.

Quite a few embedded libraries do not like indefinite-sized CBOR maps (or arrays for that matter).

For demonstration, I created a map with:

            new CborEncoder(baos).encode(new CborBuilder()
                    .startMap(4)
                    .put("Timestamp", 123456789)
                    .end()
                    .build()

and the resulting map is:

BF                         # map(*)
   69                      # text(9)
      54696D657374616D70   # "Timestamp"
   1A 075BCD15             # unsigned(123456789)

Is there a way to assemble a map that has a specified length in the end result?

Please show in your example how to extract the encode data. You only show
for(DataItem dataItem : dataItems) { // process data item }
This is not very helpful. Please add the code to get back the data you encoded in the encoding example.

http://cbor.schmorp.de/perl-object

http://peteroupc.github.io/CBOR/rational.html

https://peteroupc.github.io/CBOR/langtags.html

I am interested in knowing the usage of CBOR library. Can you please suggest appropriate documentation?

Hi Team,

According a specially crafted message, the library will try to allocate a message that is way above the memory capacity.

For a CBOR array input. The code was trying to decode the CBOR array before trying to use the byte[]. The library that has no limit on the allocation memory that is requires -> an attacker could get craft a packet that will ask the library to allocate an object that will exceed the available memory.

When including cbor-java as a dependency of a project using Java 9 modules, the build process produces the following warning:

[WARNING] ************************************************************************************************************************************
[WARNING] * Required filename-based automodules detected: [cbor-0.9.jar]. Please don't publish this project to a public artifact repository! *
[WARNING] ************************************************************************************************************************************

This is because Java will convert the jar file to an automatic module, whose name is based on the name of the jar file itself, which is (apparently) not guaranteed to be the same across build systems.

From what I gather, the solution - assuming you don't want to move to modules yourself - is to add an Automatic-Module-Name entry to the jar's manifest that specifies an explicit name to be used in this case. I think something like the following should work:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.2.2</version>
    <configuration>
        <archive>
            <manifestEntries>
                <Automatic-Module-Name>co.nstant.in.cbor</Automatic-Module-Name>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

As I understand it, this will ensure a consistent automatic module name for any consumers using Java platform modules, without forcing you to adopt modules yourself.

We have a situation where client has to use peteroupc CBOR (https://github.com/peteroupc/CBOR-Java) library whereas server has to use c-rack CBOR library(https://github.com/c-rack/cbor-java)
Although both comply to RFC 7049. but wanted to doubly sure if there are any potential challenges/issues w.r.t to the above mentioned arrangement.

While using the library I stumbled upon how the builder currently handles tags. There seems to be quite a difference between what the Builder produces and what the Decoder will produce:

new CborBuilder().addTag(1).add(22)

which results in a list of two items, the first being the tag, the second being the integer. If we encode the result we will get (as expected):

C116

If we decode the same, we'll get a single DataItem of type UnsignedInteger with the tag set appropriately. This difference is a bit bad when writing functions that should operate on a tree of DataItems.

Additionally we can only tag DataItems on the "top level". The ".addTag()" interface could work inside array, but doesn't at all in maps.
I think a nice interface could be to provide static methods in CborBuilder like

public static DataItem tagged(int tag, ...)

that could be used like:

final List<DataItem> di = new CborBuilder()
    .add(tagged(2, tagged(1, "foobar")))
    .build();

where the result would encode as

C2                                               # tag(2)
  C1                                             # tag(1)
    66                                           # text(6)
      666F6F626172                               #   "foobar"

What would you think of that as an addition to the CborBuilder?

The following assertion in the NegativeInteger(long) constructor prevents the creation of negative integer instances >= -4294967296L:

public NegativeInteger(long value) {
this(BigInteger.valueOf(value));
assertTrue(value < 0L, "value " + value + " is not < 0");
assertTrue(value >= -4294967296L, "value is not >= -4294967296"); // <- should be removed
}

The README in this repo links to the JavaDoc documentation here. That documentation does not say anything about DataItem having a getTag method; however, it does, at least in version 0.9.

Hi,

I still didn't figure out how to decode CBOR to primitive data types. Can you give me an example?

I have been trying this:

ByteArrayInputStream bais = new ByteArrayInputStream(data);

    List<DataItem> dataItems = null;

    try {
        dataItems = new CborDecoder(bais).decode();
    } catch (CborException e) {
        e.printStackTrace();
    }

    JsonObject jsonResponseObject = null;
    for (DataItem dataItem : dataItems) {
        // process data item
        Log.d(TAG, "Decoded CBOR: " + dataItem.toString());
        Log.d(TAG, "Decoded CBOR: " + dataItem.getMajorType().toString());

    }

Output:

Decoded CBOR: SIMPLE_VALUE
Decoded CBOR: MAP

I am expecting a boolean value instead of words: SIMPLE_VALUE or MAP. How can I fix it?

Found it difficult to use byte array e.g. byte[]. One can encode but how to decode?

My use case is to encode big byte strings (which are then tagged as typed arrays), possibly up to 100MiB. I haven't profiled it yet, but from previous experience I can smell that the ByteString class will be one source of bottlenecks due to its use of array cloning within the constructor and also in getBytes(). In the ByteStringEncoder the getBytes() method is called and there is absolutely no reason to make a copy here. For the constructor, well, I would put more responsibilty into the user's hands and explicitly say in the javadoc that no copy is made, so the user has to make one himself if he wants to further use the byte array.

Removing the cloning operations will not only reduce memory usage spikes but also remove the time it would take to make the clone and also the effort that the garbage collector would have.

Hi, can you push another release to maven. Last one is from 2015 and there are changes since then.

Currently the MapBuilder can't be used to start an indefinite length map, since there is no startMap function. Would you be against adding that?

Decoding certain byte strings cause an infinite loop in MapDecoder.decodeInfinitiveLength(). The issue is that the input stream is exhausted, so decodeNext() always returns null. Null is never checked for an exit condition to the infinite loop. The data is not well formed CBOR, I realize, but I assumed that the decoder should throw in exception for malformed input.

Below is a base64 encoded byte string which triggers the problem and example code which shows the issue.

v0W5jpZleP8=
CBORInfiniteLoop.java.gz

hello,rack .I want to serialize a data, but I have a problem.

Help me see the problem.

throws co.nstant.in.cbor.CborException: Reserved additional information;

example code：

// add fack data
List<StoreShard> data = Lists.newArrayList();

long size = 7;
boolean fec_enable = false;
float fec_shards = 0.0;

String serialize() throws CborException {
        ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
        MapBuilder<CborBuilder> map = new CborBuilder().addMap();

        MapBuilder<CborBuilder> item = new CborBuilder().startMap();
        List<DataItem> list = null;
        for (StoreShard s : this.data) {
            item.put("ip", s.ip);
            item.put("key", s.key);
            item.put("peer_id", s.peer_id);
            item.put("port", s.port);
            item.put("size", s.size);
            list = item.end().build();
        }
        ArrayBuilder<MapBuilder<CborBuilder>> data = map.putArray("data");
        for (DataItem d : list) {
            data.add(d);
        }
        data.end().end().build();
        map.put("fec_enable", fec_enable);
        map.put("fec_shards", fec_shards);
        map.put("size", size);

        List<DataItem> build = map.end().build();
        new CborEncoder(outputStream).encode(build);

        final String serialize = outputStream.toString();

        ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(serialize.getBytes());
        List<DataItem> decode = new CborDecoder(byteArrayInputStream).decode();
        for (DataItem d : decode) {
            String s = d.toString();
            System.out.println(s);
        }
        System.out.println("serialize:\t " + serialize);
        return serialize;
}

class StoreShard {
    String key;
    String peer_id;
    String ip;
    int port;
    int size;
}

There's currently no way to create an Array with a hint of the capacity it will have. Since Map already has such a constructor, Array should have it too since it can improve performance in cases where the size is known.

Hi guys, I have some problem with deserialize this hex string d8799f5f58403030353438313635393537626166646462653966343837323938383663353864653734393734393539366663653166373137323130623237626466633932326558323166366364356436316337333961643436343931323563613537313736323965363534623636326431376634353963616461ffff and serialize it to cbor. The raw cbor is diffrence so I want to ask that :"How can it perform byte(*) with your lib "

actual data:
d8 79 # tag(121)
9f # array(*)
58 72 # bytes(114)
30303534383136353935376261666464 # "00548165957bafdd"
62653966343837323938383663353864 # "be9f48729886c58d"
65373439373439353936666365316637 # "e749749596fce1f7"
31373231306232376264666339323265 # "17210b27bdfc922e"
31663663643564363163373339616434 # "1f6cd5d61c739ad4"
36343931323563613537313736323965 # "649125ca5717629e"
36353462363632643137663435396361 # "654b662d17f459ca"
6461 # "da"
ff # break

expect data:

d8 79 # tag(121)
9f # array()
5f # bytes()
58 40 # bytes(64)
30303534383136353935376261666464 # "00548165957bafdd"
62653966343837323938383663353864 # "be9f48729886c58d"
65373439373439353936666365316637 # "e749749596fce1f7"
31373231306232376264666339323265 # "17210b27bdfc922e"
58 32 # bytes(50)
31663663643564363163373339616434 # "1f6cd5d61c739ad4"
36343931323563613537313736323965 # "649125ca5717629e"
36353462363632643137663435396361 # "654b662d17f459ca"
6461 # "da"
ff # break
ff # brea

http://cbor.schmorp.de/generic-object

It would be nice if streaming encoding similar to Jackson is added. Important for me would be that I could stream the elements of a ByteString as well, since these form the major part of my payload.

I was wondering if it would make sense to add optional functionality where the input of encoding and output of decoding are Java objects like List, Map, etc. That would make it easier to use the library for the non-streaming case. Semantic tags could be handled in the encoding process by registering semantic tag handlers which would work on certain class/interface types. For example, a Date object could then automatically be tagged as such. Decoding would work similarly based on tag values.

I'm using 0.3 from Maven Central & #1 is biting me in a pretty bad way -- I'm sending UUIDs encoded as two longs & negative values are exploding pretty regularly.

I can work around the issue using strings for now, but any possibility we could get a release of 0.4 sometime soon-ish for those of us who don't like vendoring jars? :)

It would be good if you could create git version tags for all your releases. This makes it easier to check/reference the source code of a given version.

Hi,
Apologies if the question is not clear. I am a newbie to cbor.
My scenario is as follows:
We are building a large IOT platform where we need to communicate with devices from the cloud. We have a reqirement to push configurations to the devices. The configurations essentially are in the JsonApi Spec format. So, essentially, the platform exposes REST api's to accept these configuration json as a String entity which are then cbor encoded and sent to the devices. Our typical json string would look like

{"data": {"id": "15", "type": "configs", "meta": {"t": "2015-03-25T13:59:19Z", "val": 1234}, "attributes": {"key": {"k1": "2015-03-25T13:59:19Z"}, "k2": {"key2": "val2", "key3": "val3", "key4": 1}, "meta": {"version": ["1.2"]}}

Now, since this is a string , the cbor library encodes the entire payload as MajorType 2 or 3. However, what we really need is to identify inner attributes such as "val" which is of integer type, or attributes which can contain map or other sub objects. In this case they are all considered as a String literal type and not encoded. Is there a way for the library to identify and encode individual values within a json String?

My sample Code:

import co.nstant.in.cbor.CborBuilder;
import co.nstant.in.cbor.CborEncoder;
import co.nstant.in.cbor.CborException;

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;

public class TestCbor {
    public static void main(String[] args) throws CborException, IOException {
        String s = "{\"data\":{\"id\":\"15\",\"type\":\"configs\"," +
                "\"meta\":{\"t\":\"2015-03-25T13:59:19Z\",\"val\":1234}," +
                "\"attributes\":{\"key\":{\"k1\":\"2015-03-25T13:59:19Z\"}," +
                "\"k2\":{\"key2\":\"val2\",\"key3\":\"val3\",\"key4\":1}," +
                "\"meta\":{\"version\":[\"1.2\"]}}}}";

        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        new CborEncoder(baos).encode(new CborBuilder()
                .add(s).build());
        byte[] encodedBytes = baos.toByteArray();
        Files.write(Paths.get("output.cbor"), encodedBytes);

    }
}

File Output
x�{"data":{"id":"15","type":"configs","meta":{"t":"2015-03-25T13:59:19Z","val":1234},"attributes":{"key":{"k1":"2015-03-25T13:59:19Z"},"k2":{"key2":"val2","key3":"val3","key4":1},"meta":{"version":["1.2"]}}}}

I tried to run the cbor encoding using the nodejs library . I am trying to get the same output in java as well .
Nodejs output
¡ddata¤bidb15dtypegconfigsdmeta¢att2015-03-25T13:59:19Zcval^Y^DÒjattributes£ckey¡bk1t2015-03-25T13:59:19Zbk2£dkey2dval2dkey3dval3dkey4^Admeta¡gversion<81>c1.2

http://cbor.schmorp.de/stringref

Hi,

Appears that cbor 0.7 jar in maven repo (https://repo.maven.apache.org) is different from what we get on building 0.7 from source code.

The issue notificed is:
Using cbor 0.7 downloaded from maven repo gives boolean as SIMPLE_VALUE during decode.
Where as using cbor 0.7 built from source code gives boolean as TRUE or FALSE during decode.

Please update cbor 0.7 on maven repo.

Best Regards,
Chary

The "Maven Dependency" section of README.md says to use 0.9 but I can't find a v0.9 tag anywhere so I'm wondering if there's even been a 0.9 release? If I go to https://github.com/c-rack/cbor-java/tags the latest release is v0.8. Would it be possible to add a v0.9 tag? Thanks!

(The reason I'm asking is that we're planning to release an Android Jetpack which uses cbor-java. The way Android Jetpack build system works is that for third-party dependencies we need to check-in a prebuilt, for security reasons. We're currently using cbor-java 0.8 and we run into problems when our library is built against cbor-java 0.8 and an application is using our library and also cbor-java 0.9.)

Hi, there are a couple of improvements and bugfixes in 0.9 that I need, but 0.8 is the latest version in the public repositories, so 0.9 isn't easy to specify as a dependency.

How special characters in JSON strings are handled by c-rack library while serialization and de-serialization?
Also is the behaviour same for all the CBOR libraries that conform to RFC 7049?
Please clarify.

http://cbor.schmorp.de/value-sharing

Hi,

I'm trying to decode cbor.
When I'm decoding i'm getting the following error.
co.nstant.in.cbor.CborException: Reserved additional information at co.nstant.in.cbor.decoder.AbstractDecoder.getLength(AbstractDecoder.java:70) at co.nstant.in.cbor.decoder.MapDecoder.decode(MapDecoder.java:19) at co.nstant.in.cbor.CborDecoder.decodeNext(CborDecoder.java:136) at co.nstant.in.cbor.decoder.MapDecoder.decodeInfinitiveLength(MapDecoder.java:32) at co.nstant.in.cbor.decoder.MapDecoder.decode(MapDecoder.java:21) at co.nstant.in.cbor.CborDecoder.decodeNext(CborDecoder.java:136) at co.nstant.in.cbor.CborDecoder.decode(CborDecoder.java:89) at org.eclipse.californium.examples.HelloWorldServer$1.handlePUT(HelloWorldServer.java:64) at org.eclipse.californium.core.CoapResource.handleRequest(CoapResource.java:218) at org.eclipse.californium.core.server.ServerMessageDeliverer.deliverRequest(ServerMessageDeliverer.java:85) at org.eclipse.californium.core.network.stack.BaseCoapStack$StackTopAdapter.receiveRequest(BaseCoapStack.java:162) at org.eclipse.californium.core.network.stack.AbstractLayer.receiveRequest(AbstractLayer.java:80) at org.eclipse.californium.core.network.stack.AbstractLayer.receiveRequest(AbstractLayer.java:80) at org.eclipse.californium.core.network.stack.BlockwiseLayer.receiveRequest(BlockwiseLayer.java:237) at org.eclipse.californium.core.network.stack.ReliabilityLayer.receiveRequest(ReliabilityLayer.java:218) at org.eclipse.californium.core.network.stack.AbstractLayer.receiveRequest(AbstractLayer.java:80) at org.eclipse.californium.core.network.stack.BaseCoapStack.receiveRequest(BaseCoapStack.java:97) at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.receiveRequest(CoapEndpoint.java:736) at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.receiveMessage(CoapEndpoint.java:665) at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl.access$800(CoapEndpoint.java:628) at org.eclipse.californium.core.network.CoapEndpoint$InboxImpl$1.run(CoapEndpoint.java:642) at org.eclipse.californium.core.network.CoapEndpoint$5.run(CoapEndpoint.java:804) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
I'm getting cbor data in string and I'm converting to byte array using
content.getBytes()
Following is the code snippet for the same.

ByteArrayInputStream bais = new ByteArrayInputStream(content.getBytes()); List<DataItem> dataItems; try { dataItems = new CborDecoder(bais).decode(); for(DataItem dataItem : dataItems) { System.out.println(dataItem); } } catch (CborException e) { // TODO Auto-generated catch block e.printStackTrace(); }

Am I missing something here?

I try to put key and values with MapBuilder, for instance

mapBuilder.put(-2, "v1");
mapBuilder.put(0, "v2");

However, key 0 will on first item, when encoding map. Is it possible to keep the same order what I inserted?

can any one tell how to avoid this exception

Hi there!

Great lib, really useful. It's been quite a while since a new version has been released (0.9 @ 2020-04-04) and there has been many updates merged since then.

Could you make a new release with the latest changes?

Thanks!

http://cbor.schmorp.de/value-sharing

If a tag is followed by a tag followed by a data item, the parsed representation will not include the inner tag.

@Test
public void foo() throws CborException {
    List<DataItem> items = CborDecoder.decode(new byte[] {(byte) 0xC1, (byte) 0xC2, 0x02});
    DataItem item = items.get(0);
    Tag outer = new Tag(1);
    Tag inner = new Tag(2);
    inner.setTag(outer);
    UnsignedInteger value = new UnsignedInteger(2);
    value.setTag(inner);
    System.out.println(item);
    System.out.println(item.getTag());
    System.out.println(item.getTag().getTag());
    assertEquals(item, value);
}

Above test will fail and print

2
Tag(1)
null

Looking at the code it seems that a few cases of invalid CBOR do not result on exceptions being thrown, e.g.

    @Test(expected = CborException.class)
    public void shouldThrowOnIncompleteMap() throws CborException {
    	byte[] bytes = new byte[] {(byte) 0xa2, 0x01, 0x02};
    	CborDecoder.decode(bytes);
    }
    
    @Test(expected = CborException.class)
    public void shouldThrowOnIncompleteArray() throws CborException {
    	byte[] bytes = new byte[] {(byte) 0xc2, 0x01 };
    	CborDecoder.decode(bytes);
    }

Is this for a specific reason, or did this just never come up? I wanted to use the library to tests clients for a protocol that uses CBOR to encode data, and would need to reject invalid serializations.

The current behaviour is also a bit misleading, since the decode functions' documentation lists CborExcpetion as being thrown "if decoding failed".

When parsing encoded CBOR, is there a way to detect duplicate keys in maps? For e.g.

A2 0101 0102

I'd need to be able to detect this scenario (as this is prohibited for the communication protocol I'm working with). Do you see a way to do that?
Looking at the current code, the element is just replaced in the map, would you be open to e.g. make this behavior configurable?

Hello,

I am completely new to this format and would appreciate if you could help me.
I currently have a bunch of CBOR formatted files that are dumped from Apache Nutch. The question is, how can i simply call decode? or i will have to first create an encoder to map it?
I only need to use the body tag in each response

this is the format of the file
y\x0fk{\n "url" : "http://168.144.229.73/company_logo.gif",\n "timestamp" : "1377529395000",\n "request" : {\n "method" : "GET",\n "client" : {\n "hostname" : "nsfpolardata.dyndns.org",\n "address" : "54.183.226.231",\n "software" : "Nutch-1.10-SNAPSHOT",\n "robots" : "CLASSIC",\n "contact" : {\n "name" : "",\n "email" : ""\n }\n },\n "headers" : [ [ "Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8" ], [ "Accept-Encoding", "" ], [ "Accept-Language", "en-us,en-gb,en;q=0.7,;q=0.3" ], [ "User-Agent", "" ] ],\n "body" : null\n },\n "response" : {\n "status" : "",\n "server" : {\n "hostname" : "168.144.229.73",\n "address" : ""\n },\n "headers" : [ [ "Content-Encoding", "" ], [ "Content-Type", "image/gif" ], [ "Date", "1424619196000" ], [ "Server", "Apache/2.2" ], [ "ETag", ""a89a0-3d4-4e4db0e41b2c0"" ], [ "Content-Length", "980" ], [ "nutch.crawl.score", "7.8264076E-14" ], [ "Last-Modified", "Mon, 26 Aug 2013 15:03:15 GMT" ], [ "fst", "33" ], [ "nutch.segment.name", "20150222070353" ], [ "Connection", "close" ], [ "Accept-Ranges", "bytes" ] ],\n "body" : "GIF89a\xef\xbf\xbd\u00000\u0000\xef\xbf\xbd\u0000\u0000\u0000\u0000\u0000\xef\xbf\xbdjl\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd@@@\xef\xbf\xbd&)ooo \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbf\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdADPPP\u0010\u0010\u0010\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd333```\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\x7f\x7f\x7f\xef\xbf\xbd\\\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xe5\x8f\x8f\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdppp\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000!\xef\xbf\xbd\u0004\u0000\u0007\u0000\xef\xbf\xbd\u0000,\u0000\u0000\u0000\u0000\xef\xbf\xbd\u00000\u0000\u0000\u0005\xef\xbf\xbd\xef\xbf\xbd!\xef\xbf\xbddi\xef\xbf\xbdh\xef\xbf\xbd\xef\xbf\xbdl\xef\xbf\xbdp,\xef\xbf\xbdtm\xef\xbf\xbdx\xef\xbf\xbd\xef\xbf\xbd|\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdpH,\u001A\xef\xbf\xbd\xc8\xa4r\xef\xbf\xbdl:\xef\xbf\xbd\xd0\xa8tJ\xef\xbf\xbdZ\xef\xbf\xbd\xef\xbf\xbdK\xef\xbf\xbdPY\xef\xbf\xbd2\xef\xbf\xbd.v\xcc\xac\u0010\xce\x95\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd \xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdx)~~\xdb\x89t\xc2\x9c~\xef\xbf\xbd\u0003\xef\xbf\xbd{r'\t\u0012\u0011\u0000\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\u0000\u0011\u0003\u0018\tP\xef\xbf\xbd\n\u0007\xef\xbf\xbd\u000F2\n\xef\xbf\xbdP\xef\xbf\xbd$\xef\xbf\xbd&\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\u0011\u0013O\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd0\t\n\u0011\xef\xbf\xbd:\xef\xbf\xbd\"\xef\xbf\xbd#\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\u0011\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd1\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd0\u0003\r\u000E\xef\xbf\xbd9\xef\xbf\xbd\xef\xbf\xbd\"\u000F\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdK\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd/\u0003\u0005\u0005\xef\xbf\xbd7\xef\xbf\xbd|&\xc9\x88\r\xef\xbf\xbd#\xef\xbf\xbd\u0016\u000E\xef\xbf\xbdL\xce\x87\xef\xbf\xbd0\xef\xbf\xbd\u0000\xef\xbf\xbd,\u0010\u0010\b\u0018;\xd9\x82%\xdc\x87\u0014)\u0005\xef\xbf\xbd\u0003\u0007\u0016\u0003\xef\xbf\xbd\u0000\u0003J\xef\xbf\xbd\u0000C\xef\xbf\xbd\u0001\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd(\xef\xbf\xbd\bs\u0000\xef\xbf\xbd\u001D@P\xef\xbf\xbd\u0001D\xef\xbf\xbd(\xef\xbf\xbd\u0012\xef\xbf\xbd\xef\xbf\xbd\u0017\u0002\t\u0016kI\xef\xbf\xbd1\xef\xbf\xbd\xce\xb6D\xef\xbf\xbdP\xef\xbf\xbd\xef\xbf\xbd\xe3\xb7\x90\xef\xbf\xbd\u0004\u0012\u0010\u0012_z\xef\xbf\xbd\u0012\u0014+\u0011\u0010\xef\xbf\xbd%\u0018\xef\xbf\xbd\f@\xca\x8e\u0007 \xef\xbf\xbd<\xef\xbf\xbdG\xdb\x88c\u0007\u0016\xef\xbf\xbd<\xef\xbf\xbd2\xef\xbf\xbdP\u0000\u00168\xef\xbf\xbd\xef\xbf\xbd\t\xef\xbf\xbd\xef\xbf\xbd\W\xef\xbf\xbd\u001E\xef\xbf\xbd\xef\xbf\xbdS\xef\xbf\xbd\u0001\xef\xbf\xbd\u0017\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdg\u0014V\xef\xbf\xbd\u0011JSX\xef\xbf\xbd\xef\xbf\xbd/`@\xef\xbf\xbd\xef\xbf\xbdD\xef\xbf\xbd\f\u0005\xd0\x82?\xef\xbf\xbd\u0000\u00139\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdZ\xef\xbf\xbd\u0007e\u0002\xef\xbf\xbd\xef\xbf\xbd\u0011A\"\u0003x\xef\xbf\xbd\u0016\xef\xbf\xbdg\xef\xbf\xbd1Z\xef\xbf\xbd)\u001A$\xef\xbf\xbd\u001A9\xd1\x81\u0004z\u0011\xef\xbf\xbdX\xef\xbf\xbd9\xe7\x81\xb9\xef\xbf\xbd4\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdp\xef\xbf\xbd\"]8\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xd7\xaeA\u001F\xef\xbf\xbdb\xef\xbf\xbd\xef\xbf\xbdD\u001A\xef\xbf\xbdA\xef\xbf\xbd\xef\xbf\xbd,+\u0000\xca\xb2(\xef\xbf\xbd&w\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdO\u0015m\xef\xbf\xbdp\u0010o\xef\xbf\xbdC\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd`.\u0018\u0014o_\xef\xbf\xbd+\xef\xbf\xbd\xef\xbf\xbdZ\xef\xbf\xbdpL\xef\xbf\xbd\u001D4\xef\xbf\xbd\xef\xbf\xbdz\xef\xbf\xbd\xef\xbf\xbd\u0013T{\xef\xbf\xbd>\xef\xbf\xbd\xef\xbf\xbdit\xef\xbf\xbd%4$\xef\xbf\xbd\xef\xbf\xbd.\xef\xbf\xbd\xef\xbf\xbd\u0002\xef\xbf\xbd\xef\xbf\xbd7P\u0000\xef\xbf\xbdy\xef\xbf\xbdg!\xef\xbf\xbd\o\xef\xbf\xbd\rU\xef\xbf\xbd5\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\u001B\xef\xbf\xbd}\xef\xbf\xbd\r8\u0001P\u0007\bP\xef\xbf\xbda\xef\xbf\xbd-f\xef\xbf\xbdQ\u0001:\xef\xbf\xbd\xef\xbf\xbd\u00004u\xef\xbf\xbd\xef\xbf\xbd\u0003\u0010|\xd3\x9e-n=\u0007\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\u001C\xef\xbf\xbd\u0016\\xef\xbf\xbd1x_-\u000ED\u0005\xef\xbf\xbde\u0016\bCK\xef\xbf\xbd>\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbdV-\xef\xbf\xbd\xef\xbf\xbdW\t\u0014X6\xef\xbf\xbd\b\xef\xbf\xbd\u001D\xef\xbf\xbdT}%I\u0014q_IC\u0002\u0002\u0002\xef\xbf\xbd\u0006\xef\xbf\xbd\u0001\u0016\u001E\xef\xbf\xbd\xef\xbf\xbdc\u0002\u0012\xef\xbf\xbd\xef\xbf\xbd&\u0004\xef\xbf\xbd\b\xef\xbf\xbd$\xef\xbf\xbdf\u0002P\xef\xbf\xbd%\xef\xbf\xbd\u0000\u000BC\xef\xbf\xbd\xef\xbf\xbd@\xef\xbf\xbd\u0000\xef\xbf\xbdG\xef\xbf\xbdc\xef\xbf\xbd1\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd]\n\xef\xbf\xbd${\xef\xbf\xbd\xef\xbf\xbdI\xef\xbf\xbd\xef\xbf\xbd\u0011}\xef\xbf\xbd\xef\xbf\xbdh)\xef\xbf\xbd\xef\xbf\xbdc}9\u0002\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd<\xef\xbf\xbd0\xef\xbf\xbd"%\xef\xbf\xbd)\xef\xbf\xbd\b\u0002\xef\xbf\xbd\xef\xbf\xbdn\xef\xbf\xbdEJWb\xef\xbf\xbd\u0000\xef\xbf\xbd\xef\xbf\xbd?\xef\xbf\xbd\u001D\xef\xbf\xbd\xe6\x85\x8d\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\f\b\xef\xbf\xbd\b\u0013\f\xef\xbf\xbd\u0019\xef\xbf\xbd\xef\xbf\xbd$`\xef\xbf\xbd2(&w\xef\xbf\xbd\u000F:\xef\xbf\xbdH_\u000Bl\xd6\x92\xef\xbf\xbd\u0007\xef\xbf\xbd7\xd4\xac\xef\xbf\xbdM\xef\xbf\xbd*-\xef\xbf\xbd>\xc5\x8e+\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbde\xef\xbf\xbd-<\xef\xbf\xbd\u0010-\u0011H\xef\xbf\xbd\b\u0002\u0001\u0001\nSQs\xef\xbf\xbdJ\xef\xbf\xbdQ\xef\xbf\xbd\xef\xbf\xbd)&B\u00025n\xef\xbf\xbd\xef\xbf\xbdD\xdc\x8a\xef\xbf\xbd\u0004\xef\xbf\xbd\xef\xbf\xbdP\xef\xbf\xbd\u001F\xef\xbf\xbd\u0016\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd[\xef\xbf\xbd\u001A\\xef\xbf\xbd\u0011G\u001B\xef\xbf\xbd\xef\xbf\xbd;\xef\xbf\xbd\u0016\xA\u0002\u0018\xef\xbf\xbd\xef\xbf\xbd+\xef\xbf\xbd\xef\xbf\xbd\u0004\u0017l\xef\xbf\xbd\xef\xbf\xbd\b'\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\f7\xef\xbf\xbd\xef\xbf\xbd\xef\xbf\xbd\u0010G,\xef\xbf\xbd\xef\xbf\xbd\u0014W\xef\xbf\xbdB\b\u0000;"\n },\n "key" : "73_229_144_168_2ce1dc3cb091222ed3a0eeb3b2ec6362f4cd9ab2_1424619196000",\n "imported" : "1424619196000"\n}

Thanks

I'm trying to use cbor-java to implement webauth. In this case, I need to get a COSE from a subset of a binary field in a CBOR object. The code for doing this with cbor-java could be more ergonomic:

Map attestationDataItem = (Map) CborDecoder.decode(Base64.getDecoder().decode(base64AttestationObject)).get(0);
byte[] authData = ((ByteString) attestationDataItem.get(new UnicodeString("authData"))).getBytes();
int idLength = authData[53] << 8 | authData[54];
byte[] publicKeyBytes = new byte[authData.length - 55 - idLength];

Map cosePublicKey = (Map) CborDecoder.decode(publicKeyBytes).get(0);

Number keyType = (Number) cosePublicKey.get(new UnsignedInteger(1));
KeyFactory keyFactory = KeyFactory.getInstance("EC"); // since keyType == 2

Number algorithm = (Number) cosePublicKey.get(new UnsignedInteger(3));

Number curveType = (Number) cosePublicKey.get(new UnsignedInteger(-1));
AlgorithmParameters params = AlgorithmParameters.getInstance("EC");
params.init(new ECGenParameterSpec("secp256k1")); // since curveType == -1

// since keyType == 2
byte[] x = ((ByteString) cosePublicKey.get(new UnsignedInteger(-2))).getBytes();
byte[] y = ((ByteString) cosePublicKey.get(new UnsignedInteger(-3))).getBytes();

ECPublicKeySpec keySpec = new ECPublicKeySpec(
        new ECPoint(new BigInteger(x), new BigInteger(y)),
        params.getParameterSpec(ECParameterSpec.class)
);

(please disregard the KeyFactory, AlgorithmParameters and ECGenParameterSpec stuff - this is java.security stuff)

In an ideal world, I would be able to write something like:

Map attestationDataItem = CborDecoder.decodeMap(Base64.getDecoder().decode(base64AttestationObject)).get(0);
byte[] authData = attestationDataItem.getBytes("authData");
int idLength = authData[53] << 8 | authData[54];
byte[] publicKeyBytes = new byte[authData.length - 55 - idLength];

Map cosePublicKey = CborDecoder.decodeMap(publicKeyBytes).get(0);

int keyType = cosePublicKey.getInt(1);
KeyFactory keyFactory = KeyFactory.getInstance("EC"); // since keyType == 2

int algorithm = cosePublicKey.getInt(3);

int curveType = cosePublicKey.getInt(-1);
AlgorithmParameters params = AlgorithmParameters.getInstance("EC");
params.init(new ECGenParameterSpec("secp256k1")); // since curveType == -1

// since keyType == 2
byte[] x = cosePublicKey.getBytes(-2);
byte[] y = cosePublicKey.getBytes(-3);

Would you consider a pull request to this effect?

(If you want to be really ambitious, doing COSE => java.security would be cool)