When it comes to public keys and private keys, are they determined by their respective intrinsic values, or by who (the public vs myself) holds it? In other words, if I switch the two before their first use, will the system still work?
From what I've read, it seems to me that the two are exchangeable, until you give one to the public and remain one for yourself privately. I wonder if it matters which key you give out.
Thanks.
Related
What is the difference between full Access Key and Private Keys?
The explanation here is quite limited. It would be great to know
The Difference
Examples when you would use which kind of key
Here is the link to the docs https://docs.near.org/docs/roles/integrator/integrating#access-keys
Comparing private keys to full access keys is like comparing apple to oranges. When we talk about an access key, regardless of its permissions, we usually talk about a public-private key pair. The public key of the key pair is added to the account state that is stored on chain while the private key is stored on some local device that can be used to sign transactions through some client.
It's somewhat of a misnomer situation.
There are 2 types of keys in Near:
Full Access Key
Limited Access Key or Function Call Access Key
Every key "pair" has a public and private part. These are often also called keys on their own i.e. my "public/private key." Keys are just data and usual looks like some random bytes. In near we use base58 encoding for string representations of these parts.
A private key is sometimes also called a secret key.
In Google reCaptcha, why two different key used e.g. Private Key and Public Key
My question is - What is the specific purpose for each keys ?
I know this is a relatively old question, but in the hope that it can still help you or someone else in the future..
Recapcha uses the standard public/private key cryptography implementation. To quote the link (Wikipedia)
..two separate keys, one of which is secret (or private) and one of
which is public. Although different, the two parts of this key pair
are mathematically linked. The public key is used to encrypt plaintext
or to verify a digital signature; whereas the private key is used to
decrypt ciphertext or to create a digital signature.
The Wikipedia article about encapsulation states:
"Encapsulation also protects the integrity of the component, by preventing users from setting the internal data of the component into an invalid or inconsistent state"
I started a discussion about encapsulation on a forum, in which I asked whether you should always clone objects inside setters and/or getters as to preserve the above rule of encapsulation. I figured that, if you want to make sure the objects inside a main object aren't tampered with outside the main object, you should always clone it.
One discussant argued that you should make a distinction between aggregation and composition in this matter. Basically what I think he ment is this:
If you want to return an object that is part of a composition (for instance, a Point of a Rectangle), clone it.
If you want to return an object that is part of aggregation (for instance, a User as part of a UserManager), just return it without breaking the reference.
That made sense to me too. But now I'm a bit confused. And would like to have your opinions on the matter.
Strictly speaking, does encapulation always mandate cloning?
PS.: I program in PHP, where resource management might be a little more relevant, since it's a scripted language.
Strictly speaking, does encapulation always mandate cloning?
No, it does not.
The person you mention is probably confusing the protection of the state of an object with the protection of the implementation details of an object.
Remember this: Encapsulation is a technique to increase the flexibility of our code. A well encapsulated class can change its implementation without impacting its clients. This is the essence of encapsulation.
Suppose the following class:
class PayRoll {
private List<Employee> employees;
public void addEmployee(Employee employee) {
this.employees.add(employee);
}
public List<Employee> getEmployees() {
return this.employees;
}
}
Now, this class has low encapsulation. You can say the method getEmployees breaks encapsulation because by returning the type List you can no longer change this detail of implementation without affecting the clients of the class. I could not change it for instance for a Map collection without potentially affecting client code.
By cloning the state of your object, you are potentially changing the expected behavior from clients. This is a harmful way to interpret encapsulation.
public List<Employee> getEmployees() {
return this.employees.clone();
}
One could say the code above improves encapsulation in the sense that now addEmployee is the only place where the internal List can be modified from. So If I have a design decision to add the new Employee items at the head of the List instead of at the tail. I can do this modification:
public void addEmployee(Employee employee) {
this.employees.insert(employee); //note "insert" is used instead of "add"
}
However, that is a small increment of the encapsulation for a big price. Your clients are getting the impression of having access to the employees when in fact they only have a copy. So If I wanted to update the telephone number of employee John Doe I could mistakenly access the Employee object expecting the changes to be reflected at the next call to to the PayRoll.getEmployees.
A implementation with higher encapsulation would do something like this:
class PayRoll {
private List<Employee> employees;
public void addEmployee(Employee employee) {
this.employees.add(employee);
}
public Employee getEmployee(int position) {
return this.employees.get(position);
}
public int count() {
return this.employees.size();
}
}
Now, If I want to change the List for a Map I can do so freely.
Furthermore, I am not breaking the behavior the clients are probably expecting: When modifying the Employee object from the PayRoll, these modifications are not lost.
I do not want to extend myself too much, but let me know if this is clear or not. I'd be happy to go on to a more detailed example.
No, encapsulation simply mandates the ability to control state by creating a single access point to that state.
For example if you had a field in a class that you wanted to encapsulate you could create a public method that would be the single access point for getting the value that field contains. Encapsulation is simply this process of creating a single access point around that field.
If you wish to change how that field's value is returned (cloning, etc.) you are free to do so since you know that you control the single avenue to that field.
When adding a web reference in Visual Studio 2005, I've noticed that every element within the wdsl is duplicated. E.g. for element ItemOne, the interface it generates contains both ItemOne and itemOneField. Both are the same thing, but one is a member and the other is a field. I suspect the field is just a getter for the member.
I can imagine using a field instead of a member for this...but in that case my tendency would have been to make the member private, to avoid clutter. This, despite the fact that the normal motivation for making such a member private is to hide implementation details, which is obviously not applicable in this case.
I realize that changing this now would likely introduce compatibility issues, but I don't see why they did it this way the first time.
Do not point out that such a change would introduce compatibility issues with previous versions of VS. I am interested in the original reasoning behind this.
It's a property with a backing field. What's the problem? Were you expecting it to generate an automatic property? They didn't exist until recently. Why change what works, especially since ASMX (and WSDL.EXE) is pretty much dead technology.
"I am interested in the original reasoning behind this"
as everything past 3.0 framework, the only way to create properties were having a private variable and the property name
private string myItemField;
public string myItem() {
get {
return myItemField;
}
set {
myItemField = value;
}
}
but now, there is no need for it...
public string myItem { get; set; }
the thing is, that this last code is compiled as the original one at the top, even if it's easier to write, it is compiled in the same old way, you will end up with a private variable and a property.
Same thing happens when you add a Web Reference, it needs a variable to hold the "stuff" and then the method...
I need to store a lookup table as an instance member in one of my classes. The table will be initialized when the object is constructed. Each "row" will have 3 "columns":
StringKey (e.g., "car")
EnumKey (e.g., LookupKeys.Car)
Value (e.g, "Ths is a car.")
I want to pick the data structure that will yield the best performance for doing lookups either by the StringKey or the EnumKey.
It's kind of awkward having 2 keys for the same dictionary value. I've never encountered this before, so I'm wondering what the norm is for this type of thing.
I could make a Key/Value/Value structure instead of Key/Key/Value, but I'm wondering what type of performance impact that would have.
Am I thinking about this all wrong?
Well ... "Wrong" is a harsh way of putting it. I think that because the most common dictionary is "single key to value", and a lot of effort goes into providing efficient data structures for that (maps), it's often best to just use two of those, sharing the memory for the values if at all possible.
You have two hashmaps.
One from StringKey to value.
One from EnumKey to value.
You do not have to duplicate all the Value instances, those objects can be shared between the two hashmaps.
If it's a LOT of items, you might want to use two treemaps instead of two hashmaps. But the essential principle ("Share the Values") applies to both structures. One set of Values with two maps.
Is it really necessary to key into the same structure with both types of key? You probably don't need to rebuild a complex data structure yourself. You could do some sort of encapsulation for the lookup table so that you really have two lookup tables if memory is not an issue. You could use this encapsulating structure to simulate being able to pull out the value from the "same" structure with either type of key.
OR
If there is some way to map between the enum value and the string key you could go that route with only having one type of lookup table.
LINQ's ILookup(TKey, TElement) interface may help. Assuming your Dictionary is something like:
Dictionary<carKey, carValue> cars;
You could use:
ILookUp<carValue, carKey> lookup = cars.ToLookup(x => x.Value, x => x.Key);
(...actually I think I might have slightly misread the question - but an ILookUp might still fit the bill, but the key/value set might need to be the key and the enum.)
If every value is guaranteed to be accessible by both types of keys, another idea would be to convert one type of key to another. For example:
public Value getValue(String key)
{
dictionary.get(key); // normal way
}
public Value getValue(Enum enumKey)
{
String realKey = toKey(enumKey);
getValue(realKey); // use String key
}
You could have your Enum implement a toKey() method that returns their String key, or maybe have another dictionary that maps Enum values to the String counterparts.