Let $a_1$ through $a_k$ be some permutation of the first $k$ primes. Let $n \in [1,k!]$ be a parameter specifying the exact ordering by taking the $n$th permutation in a sorted list or by some other simple mechanism.
Then define $f(n,k)=a_1^{p_1}+a_2^{p_2}+\ldots+a_k^{p_k}$, where $p_i$ is the $...
I have a working Java code for encryption of string in AES encryption using the key , and i have been trying the replicate the code in Nodejs for quite long but unable to get the exact encrypted hash output as Java code gives me. Please let me know what i have been doing wrong.
Encrypt.java
...
I was one of the implementers of JScript and on the ECMA committee in the mid to late 1990s, so I can provide some historical perspective here.
The JavaScript Math.random() function is designed to return a floating point value between 0 and 1. It is widely known (or at least should be) that t...
Not a confession but explain the something behind the curtain.
Browsers also may run on various systems. If you would run /dev/urandom on some old Debian and even Ubuntu machines you could easily hang the entire system by depleting the entropy pool. Actually, I'm wondering if you still cannot.
So it may be frickin' weird, but using a non-secure random would be more secure in that situation. World is weird.
@bdegnan The sha256 function didn't implement HMAC at all, but JS simply ignores spurious arguments.
JavaScript cannot be used to produce secure code, because it injects uncertainty at every step. C has a lot in common, but it doesn't fail at that kind of level.
more complexity -> less security. More state -> less security.
More uncertainty -> more possible state.
Cryptography is probably strange in the way that it introduces complexity and security :)
Well, considered that 90% of posts on SO shows insecure code, I might as well say that it may introduce security.
I'm rather fond of C, but I'm generally pretty intimate with hardware. I'm mindful of buffers and such. Most of what I write C for, I also wrote the HDL or made the IC.
I want to learn Python for matplotlib, but the white space kills me. :/
Yeah, I get C for lower platforms. But even then, I'd rather use a low level language where at least some bounds checking is performed for most functionality. I've seen too many horrid mistakes and doing "software security" course on Coursera kindof cemented my opinion.
Writing an entire OS in C with millions upon millions lines of code ... what could possibly go wrong?
@bdegnan Question: do you regularly use things like valgrind (or any other source code analysis) on your code? Or is that too complex for embedded platforms?
I once hoped that static analysis would remove most of the vulnerabilities of C, but that hasn't happened it seems.
I have a custom BSD that I use, it's not that large. It's like 20k lines. The problem is not the language, but the people. people suck at pointers and under/overruns. For instance, I have memory that is allocated that starts with the address and the length, so there's overhead but you can never overun your memory.
@MaartenBodewes no, basically, it's just carefully designed.
There's probably better ways to tackle the problem of coding platforms; however, the abstraction required is pretty hard. Generally, the hardware guys do the bring up just because we know what/how it works.
I've been asked to write small things in C where I just did the development in another language and manually translated the code to C when I was done.
I made the mistake of telling someone I did that once, though. It automatically disqualified my code in their eyes.
As long as a language isn't dynamically typed it's fairly easy to mentally map small amounts of code in any language to unoptimized assembly. It's not hard to write code high level code that produces the same output as a given piece of assembly. (Functionally compatible code, that is. Not so much code that does the same task the same way. Or anything that needs to care about which registers get used.)
Wouldn't most higher level languages be written in C? The only runtime I ever wrote was a Java coprocessor, and that was in C and then we targeted it to VHDL. That was ages ago. You probably could have Java create a byte code interpreter.
I could write Java that emits machine code. It would be a pain though because I'd then have to reimplement something that's already been implemented in C many times though. There doesn't inherently need to be source-level dependency on C in higher level languages.
You could write a Java compiler in C# which converts programs to webasm instead of Java's traditional byte code.
"Python as a language is just a set of rules (like syntax rules, or descriptions of standard functionality)" That's true for languages in general. There is also nothing stopping someone from writing a C compiler in Python.
And it (this hypothetical compiler) could emit binaries that run at the same speed or faster than something like GCC. The compiler might be slow because it runs in an Python environment, but the output need not inherent the compiler implementation's Python-ness.
hi :) if i have two scalars for a ristretto curve (integer under mod group order) generated by taking the sha512 hash of some data and i add them (under mod group order), is that operation collision resistant? is there anywhere i can find things to read on that?
i explained it wrong and you are correct. i compute (sha512(x) mod L) * P where P is the basepoint of the ristretto curve and apply the group operation * of that to (sha512(y) mod L) * P
i have some short proof-of-concept code if that would help
@FutureSecurity well, in the end you'll have a hard time finding an OS that is not at least partially written in C so you can always argue that some part of your stack is using C :p
I think people think that C is faster than any "programming language written in C" because they see it as a nesting doll situation. Like if you write something in assembly then it's supposed to be as fast as you can possibly get. Then if you write something in C then it will inherently be at least slow as the same thing implemented in assembler.
And if you write a program written in a language written in C then it inherently has to be even more inefficient because you're nesting assembly in C in Python.
People don't understand that there is a difference between interpreters and compilers though. It's hard to argue with someone who thinks C is the fastest thing short of assembly because of that nesting logic. If you give them a counterexample then they'll latch onto any little piece of the stack that uses C. So they would argue that your LLVM-based compiler is only produces efficient binary code because C is fast.
If you give them a counterexample that uses no C whatsoever, a project bootstrapped without having ever having used any C-based dependencies in its entire history, then they're going to think "Well, that still proves my point because it's based on ASM instead of C so of course it's just as good."
I'm not aware of popular examples that support arbitrary volatile memory accesses. Lots of languages have a more restricted form that allows volatile access to compiler-managed variable.
You could make arbitrary volatile and fenced memory accesses in non-standard Java though using Sun's "Unsafe" class.
Compilers could do something like that for any other language
"I think people think that C is faster than any "programming language written in C" because they see it as a nesting doll situation. Like if you write something in assembly then it's supposed to be as fast as you can possibly get. Then if you write something in C then it will inherently be at least slow as the same thing implemented in assembler."
@FutureSecurity Above is not correct per se though. There are plenty of examples where a JIT beats stuff written in low level C++, for instance. Cryptography not being one of them, mind you.
@SEJPM Yeah, but the JVM is written in C. Well sure, parts of it is probably even written using assembly. However, the trick is to make the amount of code that is vulnerable as small as can be. The footprint for errors is much smaller with a JVM.
That said, there have been very weird loopholes when it comes to MT, reflection and native access
And things like mutable class fields that are really dangerous. Java should not have allowed those to exist.
Configurable XML parsers and TLS libraries are horrid too. One config to rule them all!
There was a lot of arguments in the C++ community ridiculing the insecurity of Java because e.g. problems with the imaging library. Of course, that mainly depended on a native library written in .... guess what.