Is there a way to use Google Truth to compare a protobuff to a string? I am hoping to find something that looks like this:
assertThat(myProto).isEqualToString("a: 1\n b:2")
Truth provides an extension for protocol buffer assertions, which is probably what you should use. Asserting on a message's string format is going to be brittle, and failures will be harder to understand.
That said you certainly can do what you're asking:
assertThat(myProto.toString()).isEqualTo("a: 1\n b:2");
Related
I would like to intercept the behavior of read to give some control over the interning of symbols. I might, for example, wish for read to throw an error if a previously uninterned symbol shows up in the input stream. Or perhaps I want to limit the packages in which new symbols can be interned.
Is there a way to hook the interning process without rewriting the reader from scratch?
I am ok with alternate reader implementations. Using read itself is not a must.
You can't do this with the reader defined by the standard without jumping through huge hoops: you'd have to implement the process of accumulating and parsing tokens (including all the number parsing stuff) and then provide suitable ways of intervening. The standard tells you enough that you should be able to do that, but it's a lot of work: I suspect that most of any reader implementation is that stuff.
Of course specific implementations might provide convenient points at which you can intervene.
The other approach would be to use a portable, extensible reader. There is at least one thing which may be such a thing: Eclector, and there may well be others. I don't know anything about it, unfortunately.
I have never gone really deep into encryption algorithms till date but now I have been put on a project which demands some knowledge on it.
I am using AES-CTR algo and really need to understand what '||' this operation means.
For example: I have the formula which looks like this:
message = AES-CTR<KEY>(SNONCE16||DNONCE16||SID16,NS14).
Basically, key is the encryption key, snonce16 is randomly generated 16 byte on server side, dnonce16 is received from an IOT device and SID16 is its serial no., NS14 is randomly generated encryption nonce on server side.
I get everything, but what does this operation '||' mean . I assumed it was a normal 'or' operation but that might not be the case.
Really need an experts opinion on this.
Thanks.
In cryptography the || operation usually means simple concatenation. It's written \| (or, apparently \mathbin\Vert) in TeX and that makes the pipe characters much more narrow, distinguishing it more from other uses.
Related text on the origin of || on the cryptography site is asked and answered here. Apparently it has been adopted from set theory in mathematics.
Note that usually the (encryption) nonce is put in front of the plaintext or ciphertext, rather than the last parameter, so that surprised me a bit.
I am fairly new to cryptography, but I have come across this :
ea706916-4d0a-460d-9778-4d1a7195b229
which looks like a familiar format. It's original value is tjotol.
Would anyone know what format the above code is in? I know that if it has hashes it can be a giveaway. Base64? HTML? Something else?
It does not look like Base64, it may be MD5 with dashes in-between. However, remember that a hash is a one-way function (ie. it's not reversible), while a cryptographic function is two-way (you can encrypt and decrypt it). Hence, it's not correct to speak about "hash decrypting". I don't know what you mean by "format language", would you care to elaborate on that?
A quick google search took me to this article that seems to be well written an covering many issues regarding your concern related to hashes being a "giveaway".
Note: Base64 is hardly an encryption algorithm, it is indeed just an encoding/representation format.
This have the format of a Globally unique identifier (GUID). Take a look here: Globally unique identifier
I want to make a javascript library for signing messages. I expect the format to be something like...
--- BEGIN SIGNED MESSAGE ---
This is a plain old message
It goes on and on...
--- BEGIN RSA OF SHA1 ---
Base64Stringassfd86asdf870n8
09as8d76fn098==
--- END SIGNED MESSAGE ---
But I don't know the correct format. I could replicate PGP format (I am sure it is not hard to find info on that) but I would prefer to use a standard method if there is one.
Is there a standard format for this kind of signed message?
Cryptographic Message Syntax (a.k.a PKCS #7) is a very commonly used format for signed data. It also supports encryption and authentication of payload contents, so it's a bit of an uber-format. The downside is the complexity of implementation - the specification can be tiresome to trawl through and you have to be comfortable working with ASN.1.
OpenPGP format is likely to be simpler to implement and more readable to the human eye (no ASN.1 to be seen). This might be the best bet for simplicity. Again, you would have the option to add encryption at a later date, if you so desired. However, the specification can be equally infuriating to work with - I've never encountered an RFC that was so... imprecise before.
For sake of completion, W3C XML Signature, it is slightly easier from the syntax and encoding perspective but requires that the final data is in XML.
I am looking for a Stream Cipher encryption method, that will result in the encrypted string being prefferably as short as possible, and containing alphanumeric characters only.
Is there such a thing built in .NET? I have researched but could not find something like this.
Thank you,
I found the answer here Really simple short string compression, meaning its not possible, as encryption means also making the value longer. The best that can be done is keeping the same size of the input, but if the result must be alphanumeric then a longer string is a must
You can make it shorter - just zip the resulting encrypted string using java or some other library and output as hex. Pretty straight forward.